Backup Central

I have been using rdiff-backup to back up my web server for a while. Now I have had my first restore attempt and it wasn't pretty.

I was hoping someone could help me see where I went wrong including if the way I am trying to use rdiff-backup in the first place was not the best solution to my problem.

I have a web server in a remote facility. I have SSH access to it. It runs Red Hat 9.

I have another remote server in the same facility that I have been using as a backup server.

I installed rdiff-backup on both machines and set up a key so I could do unattended backups each night to the backup server.

My intent was to basically be able to use my backup data to effectively restore the web server to its running state before it crashed so I was backing up everything except the following directories:

- /dev
- /mant
- /tmp
- /proc
- /var/qmail/queue

The reason I was not backing up those is from a recomendation I got about those directories.

Since I don't have physical access to the machines, in the event of a major malfunction, the facility techs have to re-image the hard drive as it was originally. Then it is up to me to get it back to the state it was in prior to the crash.

Well it finally happened. My hard drive started to go. At first the problem was just a few directories that had input/output errors when accessing them. It quickly progressed though.

I am running MySQL, Apache, Qmail, Plesk and a few other software packages.

When the techs left me the re-imaged drive the operating system was the same version as I had in my backups but MySQL was not. I thought I could just restore everything I had backed up, overwriting the older versions of software, and end up with the system back where I started from.

I am realizing that may have been my first mistake, assuming it could be that easy.

But things really went wrong when it became clear that the ID's for the accounts on the two machines didn't match up and as a result the permissions and ownership of the restored files was a complete mess. It was then that I actually read the part in the manual about mapping the UID's. I was completely unaware that would even be an issue.

Unfortunately, because Red Hat 9 is officially dead, the server facility no longer keeps drive images available to restore from. They had to install from rpm's which took them 12 hours to complete vs. the two hours they guarantee to restore from a drive image. And since my restore attempt corrupted some operating system files, I get to do it all over again.

So I am looking for some guindance and feedback please.

1. Was my original intent of being able to just restore files over a freshly provisioned hard drive realistic? vs. just installing the correct software and then restoring the data only instead of the apps?

2. Is anyone else doing anything like this and can you share your method and setup?

3. In the future, I assume I can just set up a UID map by looking at the /etc/passwd file on each machine? Or do I need to look elsewhere for that?

Perhaps I know just enough about Linux to really get myself into trouble like this.

Thanks.

Do you Yahoo!?
vote.yahoo.com - Register online to vote today!

begin quotation of chris young on 2004-09-17 12:52:01 -0700:

Unfortunately, because Red Hat 9 is officially dead, the server
facility no longer keeps drive images available to restore
from. They had to install from rpm's which took them 12 hours to
complete vs. the two hours they guarantee to restore from a drive
image. And since my restore attempt corrupted some operating system
files, I get to do it all over again.

If Red Hat 9 is officially dead, you should look at this as an
opportunity to switch to a supported version of a Linux distribution.
You'll be worse off than you are now if you keep Red Hat 9 on there
and don't have security updates - *when* your machine is compromised,
you won't know what data to trust without quite a bit of work. Which
distribution is not a discussion for this list, but I'd be happy to
talk to you off-list about it.

1. Was my original intent of being able to just restore files over a
freshly provisioned hard drive realistic? vs. just installing the
correct software and then restoring the data only instead of the
apps?

No, you should not have expected to restore application files over
ones from an existing install. Package management can be a
complicated beast, and blindly overwriting random files will land you
in a lot of trouble.

One option would have been to send the techs a copy of your last good
backup and have them repartition the hard drive and copy the files
directly there without "installing" anything. You kept very complete
backups, and a competent tech should be able to perform that operation
in much less than the twelve hours it took them to reinstall -
probably a little longer than the two hours they guaranteed for a disk
image because that's basically what you have. You'd be up and running
with the same system as before, but with a good hard drive this time.

A second and equally valid option would have been to, as you
suggested, reinstall the applications and then restore your *data*.

Alec

On Fri, 17 Sep 2004 chris young <synergypoint2001 < at > yahoo.com> wrote:
When the techs left me the re-imaged drive the operating system was the
same version as I had in my backups but MySQL was not. I thought I could
just restore everything I had backed up, overwriting the older versions
of software, and end up with the system back where I started from.

I've been using rdiff-backup for a couple of years at many sites and it
works great. I do not and probably would not use it as a "system file"
backup system. I do/would use it only for data.

There are a number of problems with using it for system file backup. The
first is the UID issue you describe. Even with mapping, that's adding a
layer of complexity to the issue I'm not sure I'd feel comfortable with.

The second problem is directories you are excluding (dev, proc, etc). If
your tech restores you to an old image of the drive, and you restore from
a rdiff-backup backup, then those directories might not be up to date.
What I mean is you may have (I hope!) updated/patched/removed/installed
packages between the original image date and the restore date. Those
package changes may affect (add, remove, alter) files in those excluded
directories. So if you restore from an image and then restore from
rdiff-backup, you'll have a confused and messed up system where some files
in those directories are out of synch (ie: older) with the versions the
system thinks are installed. Unpredictable results will follow.

A Linux install is so easy to rebuild from scratch (compared to Windows
Server!!) that all you really need to do is backup /etc, /var and anything
in /usr/local. When you have to restore, just put back in the rpm's you
need and copy back in the appropriate config files.

In fact, I use a script to automatically build linux boxes to my spec
after a minimum (no-package selected) install.

For better "system" backups, I'd look at RAID (like cheap IDE RAID 1
devices like ARAID, Duplidisk or Stardom). The ARAID and Stardom are neat
in that they clone to a disk on the fly (hotswap!) and you can then take
that extra disk offsite and put the mirror disk back in. All this without
ever taking the system offline!

If you're off-site, I'm not sure what the best way to do a full "system"
backup would be. It's a tough problem.