It was fairly easy. I used rustic to back up my entire home directory to a USB flash drive.
The trick is to ensure that all applications (except KDE) are closed. Firefox, for example, really hates if you try to actively sync or copy over it's profile directories while it is running.
And then I also nuked my podman user data. (podman system reset). Podman sometimes makes the ownership of it's files weird, but also the container images take up a lot of space that I don't really care about actually backing up. It's okay if those aren't on the new laptop.
Then I backed up to the usb flash drive:
rustic init -r /path/to/repo — this will prompt you for a password
rustic backup -r /path/to/repo /home/moonpie
One cool thing about the backups is that they are deduplicated and compressed. So I backed up 120 gb of data, but it was compressed to 80 gb.
restic snapshots -r /path/to/repo
The snapshots are deduplicated as well. Data that doesn't change between snapshot versions, doesn't take up any extra space.
rustic restore -r /path/to/repo snapshotid /
The / is needed because rustic restores to paths underneath the thing. It gave me a bunch of permission errors about not being able to read stuff not in my home directory, but eventually it restored all of my data.
And then yeah. All my data. Except Wifi passwords, which I had stored as unencrypted for all users, because I didn't like having to unlock the KDE wallet to get to Wifi passwords when connecting. I had (and have) LUKS encryption so I didn't worry about that too much. But it means that data not in my home directory was not copied over.
It was surprisingly smooth, and now I have all my data and firefox profiles and stuff on the new machine.
The original person you replied was commenting that nix was less vulnerable to supply chain attacks. Your reply is essentially completely off topic, talking about CVE's. They are not the same type of issue. Having an actively running piece of malware on your system is vastly more concerning than a vulnerability someone has yet to exploit, and the supply chain security techniques needed to protect against the former are different as well.
Immutability is an extremely poor defense against any form of attack. Immutability is literally a filesystem feature where a flag,
chatttr -iis set on files or folders. Any program with root can adjust this flag, and any program running as a user could download additional binaries to or modify the users home directory. This is how the nix daemon works.Now, if nixos followed (or you configured it to follow) a model where only binaries in the nix store could be executed, and nothing else could be executed (in addition to maybe say, using selinux to enforce that only the nix daemon is editing the nix store), that would be much more secure and very interesting. But it's not doing that.
Edit: correction, the nix store is not actually immutable on the filesystem level. It merely holds immutable "outputs", the packages and functions it generates. You're not supposed to edit them... but nothing stops you (if you're root or the nix daemon user). You can verify the nix store pretty easily, but it's not an ongoing process, that is to say it wouldn't catch malicious changes.
What I said above about a theoretical applocker enabled like system based on Nix still applies, however.