backup
r
What do you use to make a complete system backup ( 1 pc only )
and eventually a complete system restore ?
Jean-David Beyer
> What do you use to make a complete system backup ( 1 pc only )
> and eventually a complete system restore ?
>
>
First of all, I use cron to do it about 1AM local time when I am usually not
using the computer at all. If you use an old version of cron, you might be
better off doing it at 3 AM to avoid the switch to and from daylight saving
time.
Second, my backup medium, VXA tapes, will take a full backup of my machine
on a single tape (up to 320 GBytes). If it did not, I would do a Full backup
on Sunday, using as many tapes as necessary, and a differential back up the
other six days of the week. If I could not use tape, I would have to use
some other device that could be ejected after the backup was complete, or a
write once medium, so that it could not be harmed once it had been written.
Possibly hot swappable hard drive. One consideration on the backup medium,
since it is desirable to store at least some of these backups off site, the
medium should be small enough to do that. For me, I keep one tape a month in
my safe deposit box. I know I could not keep more than two or three hard
drives in there.
As far as backup software is concerned, what I did at first costs nothing. I
used a little shell script that the cron daemon ran at the proper time. This
script basically did a _find_ over the file systems I wanted to back up (I
did them all except for /proc and /sys . You might wish to omit /tmp as
well, but mine is small mostly, so I include it. I pipe the output of the
_find_ into _cpio_ to write the tape.
What I do now is use BRU to replace the _find_ and _cpio_ but it is pretty
much the same. There may be some advantages to BRU, but for me they are slight.
To do a full system restore, you reinstall enough of the OS to get your
system to run, and then restore everything from the most recent full backup.
If you are doing differential backups as well, you then restore the most
recent differential backup as well. When doing this, some files (programs)
will not restore because the associated file is busy. That usually does not
matter because your update system (up2date, etc.) will catch those up pretty
soon. You can probably avoid that by doing a restore from a disk-only
version of Linux (ubuntu?) to do the restore, but I have never tried that.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 07:40:01 up 43 days, 13:46, 3 users, load average: 4.02, 4.16, 4.10
Douglas Mayne
>
> What do you use to make a complete system backup ( 1 pc only )
> and eventually a complete system restore ?
>
One size does not fit all when making backups. What may work for me may
not work for you for a variety of reasons.
That said, one of the simplest backup techniques is to use a live CD and
an external hard drive. The external hard drive needs to have adequate
size to hold your backup images. The dramatic increase increase in storage
capacity over the past few years make them suitable to use to backup a
single pc, or even a small network. Your criteria calls for local storage,
but backing up one pc to another using a network is easy to setup, too.
A dedicated backup server is one of the first things to consider with
any netwrok, IMO. But external drives are a simple, mostly equivalent
option.
When making a backup this way, I use the tools listed below. Pick those
appropriate to meet your needs.
backup media: (hard drives, optical discs)
tools to obtain partition images: (tar, xfsdump, dd, ntfsclone)
tools for compressing the images: (gzip, bzip2)
tools for encrypting the backup: (device mapper containers, gpg messages)
Other information should be saved, also. I save the partition table
using something like ths:
# fdisk -l >fdisk.out
Then, I make a few notes which explain what was backed up and give some
simple hints to aid in any future restore operations. I usually make
a note of the current root-level password(s) for the system here. (This
is ok because my backups are saved in encrypted form.)
The live CD method is also a good platform to perform a restore. The
partition table recreated, the partition images restored, and the
bootloader fixed up. I use the the grub bootloader, BTW.
The "hard disk upgrade mini howto" is also a good place to learn about
what must be saved when making backups (or when moving to a new hard
drive). Practicing on a non-critical system is also a worthwhile exercise,
IMO.
--
Douglas Mayne
r
>
You gave me a good tip about doing disks images and restore them via
live cd.
But, just one question. My root ( / ) is 60 GB, just 6/7 GB are used.
If I make a disk image
( for example 'dd if=/dev/sda2 of=/mnt/disco_d/backup_image' )
how much it will be the size ? ( 60 GB or 6/7 GB )
r
>
>
I don't know a lot about cpio ( I don't have tape, but dvd/r or a backup
hd ).
I took a look to BRU, it is a lot expensive for a home pc.
Anyway I'm considering everything ; infact a good backup save time and a
lot of stress.
Douglas Mayne
All things being equal, an image made that way will consume 60G. There is
one trick* which can make the image as compressible as possible, though.
You could create a large file filled with zeroes which uses almost all of
the space in advance. Then when it is backed up, that zeroed space will
be easily compressible:
# dd if=/dev/sda2 | gzip >/mnt/disco_d/sda2.img.gz
Other tools are required to avoid zeroing space to minimize the backup to
the space in use. That is one of the reasons that "one size does not fit
all," and that other tools exist which have more finesse than dd. As tools
go, dd is a sledgehammer; tar is a framing hammer. The other tools I
previously mentioned work better to capture the disk space actually in
use. Extra care must be taken with the tools you choose because the image
may not be complete, for whatever reason. For example, tar doesn't
capture extended file attributes and file acls. These can be backed
up separately, though, and saved along with the backup. (getfacl,
getfattr). Depending on which filesystem you are using, there can be
specialized backup tools; for example, xfs has xfsdump. But for
simplicity, I often stick with simple tar/gzip backups. The other
thing which is not captured with this method is the bootloader specifics.
That must be fixed up separately at restore.
* May not work in advanced filesystems which see you are writing zero and
create it "sparsely."
--
Douglas Mayne
r
> On Fri, 19 Sep 2008 13:50:39 +0000, r wrote:
This is probably why on my first/last complete system backup with tar
( tar czf )
at restore I had an unusable system ( I had to reinstall ). So I would
avoid using tar.
My filesystem is reiserfs, I found reiserfsdump now looking around.
What about rsync, Do you know it ? can it create backup files
compressed
to be restored correctly ?
Is the way of create partition image a safe way ?
Douglas Mayne
Or, you could practice using it. If you are not using EAs and ACLs, then
the only thing to be fixed up is the bootloader. That is easily fixed,
BTW.
>
> My filesystem is reiserfs, I found reiserfsdump now looking around.
>
I haven't used reiserfs, and don't plan to, now that the chief developer
is in prison. xfs is the best journalled filesystem for Linux, IMO. YMMV.
>
> What about rsync, Do you know it ? can it create backup files compressed
> to be restored correctly ? Is the way of create partition image a safe
> way ?
>
I use rsync- it's definitely a good tool which serves a good purpose. I
use it as one part of my backup strategy. However, I don't think it is the
best tool for making complete backups, though. As the command name
implies, rsync creates two things which match; it copies files in the
source to destination, efficiently copying only the differences, etc.
rsync has a lot of options and modes of operation which make
it a flexible tool. But the myriad of possible uses and switches
definitely require practice to get right. Also, as far as I know it
doesn't do compression. The biggest problem with using it as a generalized
backup tool (i.e. making images) is that the last good backup is updated
to match the present state. That does not provide a rollback
mechanism beyond that single state (at least with the simplest mode of
operation.)
I would stick with simple tools first. As I said, it does take some
practice, but practice pays dividends in the long run. Knowing how to
make and restore backups is an essential task for anyone given the job of
"local" or network administrator, IMO. Practice with tar, getfacl,
getfattr, fdisk, grub, etc.
--
Douglas Mayne
Jean-David Beyer
> On 2008-09-19, Jean-David Beyer <jeand...@verizon.net> wrote:
>>
>
> I don't know a lot about cpio ( I don't have tape, but dvd/r or a backup
> hd ).
The man page will tell you all about it. The advantage of writing a cpio
tape (or whatever device you store the stuff on) is that you can recover
either the whole thing, or whatever subset (even a single file), if you need to.
> I took a look to BRU, it is a lot expensive for a home pc.
I agree. That is why I suggest find and cpio.
> Anyway I'm considering everything ; infact a good backup save time and a
> lot of stress.
>
True. Trying to get back where you were without a recent backup is more
stress than I can stand.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 11:30:01 up 43 days, 17:36, 3 users, load average: 4.26, 4.44, 4.52
r
>
does BRU uses tar ?
Jean-David Beyer
cpio, but it checksums each block it writes and reads it back after it does
the backup to ensure that everything got written correctly, and it comes
with CRU by which you can do a "bare metal" restore if you have the proper
tape drive (I do not). Basically, it boots itself from the tape drive (if
your BIOS permits that) or from a floppy.
My present tape drive (VXA-2) reads each packet on the tape after it writes
it, so it would catch errors without rewinding the tape and reading it back.
But I allow both for an extra check. You cannot be too careful to be sure
your backup is good.
I cannot really use CRU for my setup, and the advantages of BRU are small
compared with using find and cpio. If I did not already have BRU, I would go
with find and cpio.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 13:10:01 up 44 days, 19:16, 3 users, load average: 4.00, 4.04, 4.16
r
> r wrote:
>> On 2008-09-19, Jean-David Beyer <jeand...@verizon.net> wrote:
>>> What I do now is use BRU to replace the _find_ and _cpio_ but it is pretty
>>>
>>
>> does BRU uses tar ?
>>
> No. It uses itself. Superficially, it looks like a combination of find and
> cpio, but it checksums each block it writes and reads it back after it does
> the backup to ensure that everything got written correctly, and it comes
> with CRU by which you can do a "bare metal" restore if you have the proper
> tape drive (I do not). Basically, it boots itself from the tape drive (if
> your BIOS permits that) or from a floppy.
>
> My present tape drive (VXA-2) reads each packet on the tape after it writes
> it, so it would catch errors without rewinding the tape and reading it back.
> But I allow both for an extra check. You cannot be too careful to be sure
> your backup is good.
>
> I cannot really use CRU for my setup, and the advantages of BRU are small
> compared with using find and cpio. If I did not already have BRU, I would go
> with find and cpio.
>
ok, I think I'm going to evalutate both two, find_cpio and BRU
ok
Douglas Mayne
I found this discussion thread from this group from 2004. A question is
asked about tar vs. cpio:
http://groups.google.com/group/comp.os.linux.misc/msg/202d798bc647427f
This is good information overall. AKAICT, there are minimal differences
between tar and cpio. I do like the point that Jean-David Beyer in the
earlier discussion where he states that cpio is more modular and its use
as a pipeline stage with find is more in the unix philosophy of
/* doing one thing, and doing it well. */ He makes the point here also
that find and cpio are sufficient tools to make backups.
I looked at the manual for cpio and I am guessing that new achives should
be created with the "-H newc" format.
One thing I cannot tell from the manual is whether cpio keeps a master
index of the files in the archive. That would be a nice feature to have.
An index allows the archive to be used in a random access fashion. "Seeks"
to specific offsets within the archive are then possible. AFAIK, tar is a
simple sequential format which was designed based on a simple streaming
format, created without an index. I see that cpio can test the crc values
computed for each file within the archive- that hints that there may be a
master index. (Aside: The old "zip" format builds an index which includes
the crc values, also. However, zip loses all unix ownership information
and the older versions are limited to 2G max achive size which makes it
unsuitable for all but the most simple uses. I see a new format, 7Zip,
addresses some of these issues.)
Whatever you choose, keep in mind that neither* tar or cpio will capture
EAs and ACLs. If you are using them, then your backup should be
supplemented with extra information (getfattr, getfacl).
* Reference: Is from this article by Andreas Grünbacher, (see the section
labeled "Backup and Restore"):
http://www.suse.de/~agruen/acl/linux-acls/online/
-- Douglas Mayne
Kevin the Drummer
> What do you use to make a complete system backup ( 1 pc only )
> and eventually a complete system restore ?
The best I've used in Linux-land is Mondorescue http://www.mondorescue.org/
It's "bare metal" recovery is something that very, very few Linux backup
programs have even thought about, and it's saved me once.
G'luck..
--
PLEASE post a SUMMARY of the answer(s) to your question(s)!
Unless otherwise noted, the statements herein reflect my personal
opinions and not those of any organization with which I may be affiliated.