NixOS Atomic Upgrades: How Generations Enable Safe Rollbacks

In many Linux distributions a system update edits files in place. If the package manager crashes or a new configuration breaks a critical service, the machine can be left half‑updated and difficult to recover without manual rescue.

NixOS avoids this by treating the whole system as an immutable snapshot. Each configuration is built into a unique path in the Nix store, and activation is an atomic swap of symlinks. The system either fully switches to the new generation or stays exactly as it was.

How the Atomic Switch Works

When you run nixos-rebuild switch (as root or with sudo), NixOS performs these steps:

• Evaluation: It reads your configuration.nix and resolves all dependencies.
• Construction: It builds the complete system closure into content‑addressed paths under /nix/store.
• Activation: Once the build succeeds, it updates the symlink /run/current-system to point to the new store path.
• Service Management: It restarts only the services whose units or configurations changed.

Because the previous generation’s files remain untouched in the store, you can return to it instantly.

Worked Example: Testing a Rollback

To see the safety net in action, try a small, intentional misconfiguration and then roll it back.

1. Check the current generation:

   # sudo nixos-rebuild list-generations

   This shows a numbered list; note the current generation (the one marked current).
2. Introduce a harmless break: Edit /etc/nixos/configuration.nix and change a service setting to an invalid value, for example:

     services.nginx.enable = true;
       services.nginx.httpPort = 0;   # invalid port

   Save the file.
3. Apply the broken configuration:

   # sudo nixos-rebuild switch

   If the build succeeds, the command will proceed to activation; the nginx service will fail to start because port 0 is not allowed.
4. Verify the problem:

   # systemctl status nginx.service

   You should see an error about the port being out of range.
5. Rollback to the previous generation:

   # sudo nixos-rebuild switch --rollback

   This updates /run/current-system to point back to the earlier store path and restarts services according to that generation.
6. Confirm recovery:

   # systemctl status nginx.service

   The service should now be active (or at least not failing due to the port error). You can also check the generation list again to see that the former current generation is now active.

Throughout this process you never edited files in place; the old generation remained intact in the Nix store, making the rollback a simple symlink swap.

Trade‑offs and Limitations

• Stateful data: NixOS manages binaries and configuration, not your application databases or user‑generated files. If a new version migrates a schema, rolling back the NixOS configuration will not downgrade the data; you must handle data migrations separately.
• Disk usage: Old generations are retained to allow rollbacks, so the Nix store grows over time. Periodically run nix-collect-garbage -d (as root) to remove unreferenced store paths and free space.
• Boot‑loader fallback: If a new kernel prevents the machine from booting, the --rollback command cannot run because the system never reaches userspace. In that case you must select an earlier boot entry from the bootloader menu (GRUB, systemd‑boot, etc.) to start a known‑good generation.

Actionable Closing

The atomic model gives you a reliable safety net for experimenting with configuration changes. Before applying a potentially risky edit, run nixos-rebuild switch to build the new generation, then use --rollback if the result is unsatisfactory. Combine this with regular garbage collection to keep disk usage under control, and always keep a bootable generation available via your bootloader for kernel‑level failures.