Hi TLUGers,

I know a few of you are fairly familiar with rsnapshot. I've received
some good answers from you before.

I am wanting to use rsnapshot to manage package upgrades under Ubuntu.
With Debian packages there is no easy way to roll back an upgrade if it
somehow breaks the system.

If I can use rsnapshot to backup all the system files and the apt
database, then if an upgrade goes bad I should be able to easily restore
the system and fix it.

Has anybody done this before?

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.

Thanks,
Darryl

--
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

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.

You would have to restore everything to be sure you had rolled back
everything.  Sounds very likely to go wrong.

Some people do it by breaking a raid1 before doing an upgrade.  If the
upgrade is bad, they switch to the other disk and resync the raid from
that.  If it works fine, they simply add the other disk back into the
raid and resync.

--
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

Of course in the 10 years of running Debian I have never had a need to
do any of this.  It has always been fixable.

--
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

That is certainly an interesting idea, and shouldn't be very hard to
implement.

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.

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.

cheers,
darryl
--
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

Debian keeps its package lists under /var/ .  If you restore the rest
of the system but not /var/ then apt will still believe it's done an
upgrade even after you reverted the system.  That kind of
inconsistency won't be any fun at all.

--
Giles http://www.gilesorr.com/
gilesorr*******
--
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

Exactly why I was specifically including:

backup  /var/lib/apt    localhost/
backup  /var/lib/aptitude       localhost/

As well I should (but neglected to) have added:

backup  /var/lib/dpkg   localhost/
backup  /var/backups    localhost/

but none of the other /var/ subdirectories which are for other packages.

Of course if install scripts for other packages change these
subdirectories when they are updated (I don't think they are suppose
too) then this whole idea wont work.
--
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

Hmmm, while reading the debian policy manual http://www.debian.org/doc/debian-policy/  it appears that only the /etc/
subdirectory must be left alone after any manual changes.

This leaves a bit of a dilemma with regard to the /var subdirectories.

Within /var the only directories that may need to be restored (other
than for dpkg and apt-get) would be in /var/lib. I still don't think
these would change very often with upgrades. Perhaps the thing to do is
to record what files are changed here then if a rewind is needed and
there have been changes (which can't be undone), we can list the changes
before committing to doing the rewind.

Let me know if you guys still think this is a goofy idea or not.

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

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.

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

They are supposed to if say mysql has a new format, then /var/lib/mysql
stuff needs converting so the package takes care of that.

The only thing a package should not touch is /home and /usr/local.
Everything else is fair game.

--
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

Hmm, yup, I agree. It's a bad idea. I guess a raid is about the only way
to go.

cheers,
darryl

--
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

I am usually using an rpm/yum based system, but does dpkg/apt not
provide a way to roll back a package to an older version?  (Possibly
requiring that the appropriate .deb files be available).

jon

--
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

No system supports that in all cases.

You can install an older version, but if any config changes or database
or other files were converted to a new format, there is nothing that
can roll that back.

So sure 98%(random estimate) of packages can be downgraded, but the rest
will break.

--
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