A feature that Linux installers should have: restoring your backups

June 6, 2012

For reasons beyond the scope of this entry, I've recently been poking around Windows 7; specifically I've been poking around the standard Windows 7 backup tool, which is actually pretty decent as these things go. It will pretty effortlessly back your data or your entire system up to either some sort of disk or to a network share, and then it has one really nice feature: you can restore your system right from the installer. This works basically painlessly; you boot the install CD on a bare metal machine, find the right option, point it at your backup on a network share, and then in a surprisingly short time your entire system is back just as it was.

(I believe that Mac OS X has a similar feature but I haven't experimented with it.)

Having experienced this with Windows, I can't help but think that Linux installers should be able to do this too. It's not technically challenging and it would be a significant help for users who wind up needing to do this sort of thing; if they had a properly prepared backup, restoring their machine after a disk failure or having to replace a laptop would be pretty much a snap.

(With the right setup, making a backup would be sufficiently easy that you might get people to actually do it. It's my guess that easy install time restores would help encourage backups since they make backups more clearly useful.)

Apart from the small matter of programming in the installer, the real issues with this idea are unfortunately political. It's completely infeasible for a Linux installer to support all of the many, many options that you have on Linux for backing up your system, so supporting install time restores would mean picking one single backup system to be the officially endorsed one (along with a handful of ways to configure and use it). Linux distributions generally hate to make choices like this unless they absolutely have to, partly because doing so generally starts huge debates and rows.

(On the other hand it's possible that I'm out of touch and some Linux distributions actually already support this. If so, I can only applaud them; sometimes making a decision is what you need for usability and being genuinely convenient.)

PS: if you're tempted to implement this, please support network filesystems as well as things like USB disks. Individual people are more likely to back up to external USB disks, but in an organization it's really useful to be able to provide easy network backup and restore for things like people's laptops. You can probably guess why we're interested in this whole field. Sadly this probably means supporting doing this over Samba/CIFS, not just NFS.


Comments on this page:

From 68.111.14.178 at 2012-06-06 10:46:55:

I tend to think of this as a packaging issue.

If package management were able to go both ways - for example a tripwire-esque "grab all the config file changes for packages where something has changed", then write those packages out in some way that the installer could grab from, that would easily fit most common restore workflows.

By cks at 2012-06-06 12:13:01:

System restores have two components: system configuration and user data. You can optimize system configuration in various ways (although it's somewhat dangerous to make assumptions; for example, some of the packages installed on the old system might not be available in package repos), but you can't do anything about user data; you really have to back it up and really have to restore it.

It's my personal opinion that an ideal implementation would basically have three layers: system packages, system configuration on top of those packages, and then user data. Part of the goal is to optimize repeated backups, because often the system packages (often a significant amount of data) won't change and user data will change only partly.

(Part of the challenge of any optimization of system configuration is making sure that your backup and restore really is complete, no matter what the person has done to their machine's system setup.)

Written on 06 June 2012.
« Why the TTY line discipline exists in the kernel
My experience doing a Fedora 17 upgrade with yum: it worked fine »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Jun 6 00:22:10 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.