Could you elaborate on this? If I have state that works on v1 and after upgrade to v2 the state is now non backward compatible to v1, how nix (or guix) can help? As far as I can tell, in such case a fs rollback is better solution.
If it's something like the content of a SQL database, which lives outside the Nix store and which Nix did not generate, you need some other tool (like a filesystem snapshot, maybe) to perform the rollback. I think CoW filesystems sometimes have performance issues with DBs, though, so I'm not sure that's always the approach you'd take.
The Nix ecosystem does have a fairly mature tool for managing stateful components that live outside the Nix store, though: https://github.com/svanderburg/dysnomia
It's been around for a long time. Idk who all is using it
Of course if you have in the meanwhile used the new system and your home folder contains some backwards incompatible changes, both solutions will fail. Rolling back your home folder may not be a good thing as you may have backwards compatible changes you prefer.
Also, nix can also manage installed application’s configs, so those could also be rolled back, on either a per-app basis or however you prefer.
What I mean is that a fs snapshot is ”dumb” in and of it self.
If you couple zfs with the nixos rebuild command, then… sure, I guess - but the previous generations are already more or less directly available, unless GC’d.
This is what the fine manual has to say:
Since Nix is good at being Nix, most users will want their server's data backed up, and don't mind reinstalling NixOS and then restoring data.