Live backup of Linux server
christian_sava
There is a question I would like to ask, maybe some more experienced
Linux users could be able to help us with some useful advice. I am
trying to back-up the Linux server that supports our Web site, but in
such a way that it won't be necessary to stop the server, even for a
few hours. We need to have an exact copy of the hard drive, so that, if
disaster happens, we could simply replace the hard disk with the backup
one, and the system will be restored. For this, we have identified two
possibilites, but unfortunately both require bringing the system down
at least for a few hours:
i) Use the dd command:
dd if=/dev/hda1 of=/dev/hdb1
(this for each one of the two partitions currently defined). This will
make an exact copy of the partitions, but unfortunately, it works on a
byte-by-byte basis, and does not take into account the file system
structure. This means, the system has to be stopped and partitions
unmounted in order to guarantee the integrity of the data being
transferred.
ii) Use the Ghost for Linux program, that will make an exact image of
one partition to a different drive. This program works from a bootable
CD, and therefore requires halting the system during this operation
(about 4 hours for copying a 160GB partition).
We have experimented also with dump / restore, for the entire
filesystem (/). It seems that this utility works at the file level, and
therefore cannot make an exact copy of the partition. More
specifically, it is not quaranteed that kernel image will be placed at
the same physical location on the disk, such that the partition will
remain bootable. We have tried to repair the Linux installation, after
performing the file dump, by using the Linux installation CD, but the
resulting system was only partially functional: the network interface
eth0 was not working, and there seemed to be no way of solving this
problem.
It is not possible to use the e2image in order to make an image of
the hard drive partition, because our system, based upon Fedora Core 5,
makes use of the LVM file system.
We have been struggling with this problem for some time, until now
unsuccessfully. The solution might require to use some commercial
package, but we would like to avoid that, and use only free open-source
tools. We would be greatful if somebody could give us some hint as to
how this problem might be solved.
Thank you in advance,
Christian Sava
Unruh
> Hello,
> There is a question I would like to ask, maybe some more experienced
>Linux users could be able to help us with some useful advice. I am
>trying to back-up the Linux server that supports our Web site, but in
>such a way that it won't be necessary to stop the server, even for a
>few hours. We need to have an exact copy of the hard drive, so that, if
>disaster happens, we could simply replace the hard disk with the backup
Use rsync.
Note that there is of course a battle between "exact copy" and " not stop
the server" Ie, files can change in the middle of copying them. Those files
will of course be corrupted on the backup. But that may well be better than
no backup or bringing everything down for and hour or six.
>one, and the system will be restored. For this, we have identified two
>possibilites, but unfortunately both require bringing the system down
>at least for a few hours:
>i) Use the dd command:
>dd if=/dev/hda1 of=/dev/hdb1
>(this for each one of the two partitions currently defined). This will
>make an exact copy of the partitions, but unfortunately, it works on a
>byte-by-byte basis, and does not take into account the file system
>structure. This means, the system has to be stopped and partitions
>unmounted in order to guarantee the integrity of the data being
>transferred.
Bad idea
>ii) Use the Ghost for Linux program, that will make an exact image of
>one partition to a different drive. This program works from a bootable
>CD, and therefore requires halting the system during this operation
>(about 4 hours for copying a 160GB partition).
Again, not a great idea.
> We have experimented also with dump / restore, for the entire
>filesystem (/). It seems that this utility works at the file level, and
>therefore cannot make an exact copy of the partition. More
And you want an exact copy of the partitions why? Linux uses files. All
things are on the disk as files. There are no little hidden data pieces,
EXCEPT the MBR.
>specifically, it is not quaranteed that kernel image will be placed at
>the same physical location on the disk, such that the partition will
>remain bootable. We have tried to repair the Linux installation, after
So run lilo or whatever it is you use on that partition after the backup.
And does the kernel change that often?
>performing the file dump, by using the Linux installation CD, but the
>resulting system was only partially functional: the network interface
>eth0 was not working, and there seemed to be no way of solving this
>problem.
> It is not possible to use the e2image in order to make an image of
>the hard drive partition, because our system, based upon Fedora Core 5,
>makes use of the LVM file system.
> We have been struggling with this problem for some time, until now
>unsuccessfully. The solution might require to use some commercial
>package, but we would like to avoid that, and use only free open-source
>tools. We would be greatful if somebody could give us some hint as to
>how this problem might be solved.
Still sounds like rsync will do almost all that you want. The only othr
thing would be to make the thing bootable.
Sam
> We have been struggling with this problem for some time, until now
> unsuccessfully. The solution might require to use some commercial
> package, but we would like to avoid that, and use only free open-source
> tools. We would be greatful if somebody could give us some hint as to
> how this problem might be solved.
The only way I see to do this is to format your partitions as RAID-1. Your
hardware must support hot-plugging of drives. You cannot use your existing
partition. You must reformat and repartition as RAID-1, and use ext3
partitions. You add only one device to each RAID-1 set, it'll be marked as
a degraded partition, but will remain bootable and usable. To do a back up,
you'd have to plug in the backup drive, partition it identically to your
primary drive, and add it to the RAID-1 set. When the kernel finished
resyncing, you'll take the second drive out of the RAID-1 set, and you have
your backup right there. When booting it, you'll probably go through ext3
recovery, to replay the journal.
Douglas Mayne
Device mapper? I did some tests with this recently, by following the
example in this article:
http://linuxgazette.net/114/kapil.html
Perhaps, you could use LVMv2, which apparently does this
automatically. I only tested the manual allocation of snapshot devices
using device mapper. But either way, it may be worth switching your
filesystem to take advantage of this important live backup feature.
The big advantage of device mapper is that it is included in the
standard kernel source.
--
Douglas Mayne
Dances With Crows
Black Sun and said:
> On Sun, 14 Jan 2007 10:24:34 -0800, christian_sava wrote:
>> trying to back-up the Linux server that supports our Web site, but in
>> such a way that it won't be necessary to stop the server, even for a
>> few hours. We need to have an exact copy of the hard drive, so that,
>> if disaster happens, we could simply replace the hard disk
RAID-1. If this requirement was there in the beginning, you should've
used RAID-1 on the machine.
>> dd if=/dev/hda1 of=/dev/hdb1
dd is not a backup method. You also forgot to set bs= to something
sane instead of 512 bytes.
>> We have experimented also with dump / restore, [but] it is not
>> quaranteed that kernel image will be placed at the same physical
>> location on the disk, such that the partition will remain bootable.
Of course not. Reinstall the bootloader and it'll work.
>> We have tried to repair the Linux installation, but the resulting
>> system was only partially functional: the network interface eth0 was
>> not working, and there seemed to be no way of solving this problem.
Sounds like your guys need some more training/experience then. Fixing a
broken config file in the mess under /etc/sysconfig/ is an essential
skill if you're going to be using something Redhat-based.
>> It is not possible to use e2image in order to make an image of
>> the hard drive partition
That's not what e2image does. Check its man page again.
>> our system, based upon Fedora Core 5, makes use of the LVM file
>> system.
LVM is not a filesystem. It's a way to (sort of) separate Logical
Volumes (~="disk partitions") from the physical devices they reside on,
then manage them in various ways.
> http://linuxgazette.net/114/kapil.html
> Perhaps, you could use LVM2
That's what he's *probably* using. "lvm version" will say for sure.
> But either way, it may be worth switching your filesystem to take
> advantage of this important live backup feature.
Creating a new LV and using it to store writes/+deletes should allow the
snapshotted LV(s) to be backed up with perfect consistency. It won't do
anything for the OP's problem with the bootloader. You can't have /boot
or the bootloader on LVM.
OTOH, if the OP is using GRUB, GRUB is in the MBR, and the disk he's
using as a spare is an *exact match* to the disk already in there in
terms of geometry, he could try "dd if=/dev/hda of=/dev/hdb bs=512
count=62". That'll get the MBR, the partition table, and stage 1.5
copied to the new disk. If the new disk has a different geometry, that
semi-simple approach will fail miserably and he'll have to do a couple
of dd commands.
--
So, what do *you* do for a living?
I sit in a chair, pressing small plastic rectangles with my fingers
while peering at many tiny, colored dots. --Peter Manders
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
The Natural Philosopher
> On Sun, 14 Jan 2007 12:42:12 -0700, Douglas Mayne staggered into the
> Black Sun and said:
>> On Sun, 14 Jan 2007 10:24:34 -0800, christian_sava wrote:
>>> trying to back-up the Linux server that supports our Web site, but in
>>> such a way that it won't be necessary to stop the server, even for a
>>> few hours. We need to have an exact copy of the hard drive, so that,
>>> if disaster happens, we could simply replace the hard disk
>
> RAID-1. If this requirement was there in the beginning, you should've
> used RAID-1 on the machine.
>
>>> dd if=/dev/hda1 of=/dev/hdb1
>
> dd is not a backup method. You also forgot to set bs= to something
> sane instead of 512 bytes.
>
Agreed.
BUT the way we used to do all this sruff was
1/. Stop te machine once, and do a DD to make a fully bootable DISK.
This became our 'spare disk.
2/. Run a full tar backup excluding dynamic stuff (/dev/ amd /sys etc)
every night at the quietest period - generally around 4 a.m. This got
MOST of the data off cleanly, and all the programs.
3/. Mission critical database stuff had a transaction file separately
kept and backed up as well.
4/. Every night last night's tape was removed from the machine, tonights
tape was put in,. and last nights tape was taken home, and the night
before's tape put in a fireproof safe.
One copy was always 'off site' that way.
In practice a disk failure meant replacing eh disk with the bootable
dd'ed one, and running an untar on the last archive, and fast forwarding
the transaction files.
We used 7 tapes one a day cycled on a per week basis and thrown away
every 6 months.
For our news server and mail server we used hot pluggable RAID..the only
real way to get a near 100% uptime.