Backup of LFS

Ken Moffat ken at
Thu Jan 29 04:14:47 PST 2009

On Thu, Jan 29, 2009 at 11:14:45AM +0100, Tomáš Skočdopole wrote:
> Hi,
 Please don't top post.

 (more comments below)

> If you have more space on your backup harddrive,
> the easiest way is use some liveCD and backup the whole harddrive.
> You should do with this command:
>     dd if=/dev/sda | gzip > /mnt/path/to/image.gz
> And command for restore
>     gzip -dc /mnt/path/to/image.gz | dd of=/dev/sda
> Or you can backup only MBR
> dd if=/dev/sda of=/mnt/path/to/mbr_image count=1 bs=512
> And restore:
> dd if=/mnt/path/to/mbr_image of=/dev/sda
> And copy files from /dev/sda* manually.
> Tomas
> 2009/1/29 Ryan Isaacs <ryanisaacs at>:
> > I have a fresh LFS 6.4 installation, all I've done is add 1 user. Is
> > there a preferred way to back it up (and restore)?
> >
> > Would it be sufficient to just use the liveCD, mount my paritition,
> > and 'cp -ar', or do I need to do something more arcane like 'dd'?
> >
> > Thanks
> >

 Using 'dd' for backups and restores scares me.  Also, I thought it
would copy the raw data, so that the restored version would have the
same filesystem and be exactly the same size ?  If you _do_ use dd
as either the root user or a member of the 'disk' group, backing up
the MBR is probably a good idea.  Personally, I haven't backed up the
MBR since I last used an AmigaOne (for that, I had to use dd to
write the new kernel to the disk - all too easy to make mistakes).

 For most of us, it's easier to use tar.  Among other things, that
will allow you to restore only a single file, or to 'restore' all of
the data to a different place, or a different underlying filesystem
type.  After tarring up the filesystem or data, you can then copy it
to CD or DVD.  You can also copy it to a usb stick if that suits you
(the files in the gzipped or bzip2'd tarball will maintain their
wnerships and permissions even though the tarball itself is on a FAT

 For general backups, I use a rough and ready system of scripts based
on rsync over nfs to a 'staging' area (with a flag to indicate if
the backup completed - they're run from fcrontab, but I might switch
the machine off while it is backing up), with a separate rsync to my
equivalent of Generation Data Groups [1] on RAID1. Some of the
underlying backups are then tarred up and written to tape (for data)
or DVD (for root filesystems).  Most people probably don't need this
much overhead and it doesn't solve all the problems (in my case, the
tape drive I chose is now obsolete).

 However you choose to do this, think about what sorts of problems
you want to address (deleted files, changes that turn out to be
undesirable, disk failure, ...) and how you will restore (for
reverting undesirable changes, you also need to consider how you
will identify which files to revert if you are not rolling back to a
previous version of the system or directory).

 The 'policies' for backing up user data and the system itself are
usually different, which is one reason why a separate filesystem for
/home can be helpful (it also simplifies building your next LFS when
the current system reaches its best-before date).


1. For an explanation of the real thing, see
My attempt is considerably sketchier, and doesn't use the '(0)'
'(+1)' or '(-1)' identifiers which make GDGs such a boon in JCL.
das eine Mal als Tragödie, das andere Mal als Farce

More information about the lfs-support mailing list