Chris's Wiki :: blog/linux/InstallerRestore Commentshttps://utcc.utoronto.ca/~cks/space/blog/linux/InstallerRestore?atomcommentsDWiki2012-06-06T16:13:01ZRecent comments in Chris's Wiki :: blog/linux/InstallerRestore.By Chris Siebenmann on /blog/linux/InstallerRestoretag:CSpace:blog/linux/InstallerRestore:71df54a422f48f192ebac70c00b19849a9fc8d6bChris Siebenmann<div class="wikitext"><p>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.</p>
<p>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.</p>
<p>(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.)</p>
</div>2012-06-06T16:13:01ZFrom 68.111.14.178 on /blog/linux/InstallerRestoretag:CSpace:blog/linux/InstallerRestore:43e99a3a66d6bbeebb3fb9b855e868970e599621From 68.111.14.178<div class="wikitext"><p>I tend to think of this as a packaging issue. </p>
<p>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.</p>
</div>2012-06-06T14:46:55Z