Debian upgrade rollback

[Lennart Sorensen]

On Tue, Dec 08, 2009 at 12:20:18PM -0500, Darryl Moore wrote:
> 
> 
> Lennart Sorensen wrote:
> > On Tue, Dec 08, 2009 at 11:37:24AM -0500, Darryl Moore wrote:
> >> Has anybody done this before?
> > 
> > No, but I have heard of someone doing something for the same purpose
> > but in a much better way.
> > 
> > At the linux symposium someone showed a system using a ramdisk unionfs
> > to test upgrades before doing them for real.
> > 
> 
> That is certainly an interesting idea, and shouldn't be very hard to
> implement.
> 
> 
> 
> >> I have configured rsnapshot.conf with the following backup directories:
> >>
> >>
> >> #####################
> >> #
> >> #  System backups
> >> #
> >> backup  /boot   localhost/
> >> backup  /usr    localhost/
> >> backup  /etc    localhost/
> >> backup  /lib    localhost/
> >> backup  /bin    localhost/
> >> backup  /sbin   localhost/
> >> backup  /opt    localhost/
> >> backup  /var/lib/apt    localhost/
> >> backup  /var/lib/aptitude       localhost/
> >>
> >> Does anyone see anything wrong with this setup?
> >>
> >> There is very little information on restoring from a backup. Ideally, I
> >> would run the backup immediately prior to the upgrade. If I need to
> >> rewind it, I would like to simply copy back the files that were
> >> changed,and remove any additional files that were added. Is there an
> >> easy way to do this or do I need to write my own script to compare the
> >> original files with the backups? rsnapshot-diff is great for comparing
> >> between different backups, but I have seen nothing that checks any of
> >> the backups against the originals.
> > 
> > You would have to restore everything to be sure you had rolled back
> > everything.  Sounds very likely to go wrong.
> > 
> 
> Backing up so that I can restore everything is the general idea. It
> should be sufficient to look at the file timestamps and sizes to
> determine what needs to be restored. No? The only files I don't have in
> here are other subdirectories below /var/ I don't want to include them
> because they probably contain dynamic data from live databases and such.
> Backing them up with rsync while live may well break them, and I already
> have suitable backup mechanisms for this data. Are upgrades likely to
> affect files in these subdirectories? I though apt did not mess with
> files in /etc/ and /var that already exist at the time of installation
> so that they do not damage custom configurations.

The apt/dpkg status database is under /var.  If you don't restore that,
you kill the system.  This is why I really wouldn't try what you are
suggesting.  You have to understand the packaging system way too well
to do it.

What if you upgraded a database and it converted to a new format?
That's in /var/lib as well.  Have to restore that if you revert the
database version.  Have to revert it even if going back to an older
version of an application using the database in many cases.  The data
will need to be rolled back in many cases, not just the executables
and settings.

> That is certainly an interesting idea as well, however I'm not sure I
> want every server to running raid on the root filesystem. That seems a
> little more complicated then should be necessary.

I wouldn't want to run anything without at least raid1.  Rebuilding a
system and downtime is just too expensive compared to another disk.

-- 
Len Sorensen
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists