[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Backing up a Debian system

Example backup scripts for Debian:

I wouldn't ignore files that I installed that are in special directories
and are not packages. The package "cruft" can be used to find files that
are not in packages. The above scripts may not be smart enough to backup
everything. "cruft" has some problems when being used to figure out what
files to backup, this is because it is designed to find files that can be
removed. Removing unessesary files and packages is a good first step
before a backup, but don't delete anything you're unsure about.

I forget all my difficulties in using "cruft" to assist in creating a
backup, but I'll try to recall. One problem was a feature that it ignored
directories that it knew would have files that weren't part of packages
like /home. An inconvenience was that I had to sort through all the files
that it said should be there, but weren't (perhaps files to delete after a
reinstall of packages, although some I should have had). Another problem
was that I had to force it to skip some of the other file systems I had
mounted like CD's and my dos partitions. "cruft" seems to keep a large
backup cache of it's database, this was sometimes helpful, sometimes I
needed to delete it (maybe I did to save disk space as I remember it being

Debian backup instructions, and backup information:

"dpkg --get-selections>list_of_selections.txt" can backup a Debian user's
list of currently selected packages. "dpkg
--set-selections<list_of_selections.txt" to start a system restore, iff
packages are available. Some packages get removed from the Debian archive
( http://ftp-master.debian.org/removals.txt has recent examples), if
following unstable or testing, then you may want to use dpkg-repack or
grab a copy of the packages you are worried about.
http://archive.debian.org may also be helpful.

A simple rsync, ssh, cron solution can do regular incremental backups, but
might ignore files that are easily available (like packages on cd or
packages available by a quick download).

Discussion on backing up a Debian system:

Matt Zimmerman <mdz@debian.org> said in regards to "Debian (would like) to
do list" on debian-user:
> I've been doing these kinds of backups in various custom ways for a
> while now, and would very much like to see a tool which understands FHS
> and a little bit of Debian which could be used by an average user.
> I have in mind something like the Backup/Restore applet on the Zaurus.
> With a few taps of the stylus, the user can back up all of their data
> that is not part of the stock system, wipe it, install a new one, and
> restore their data.  I think that this is achievable for Debian.

My Debian backup steps:
1. I remove files and packages that I'm sure I don't want or need
(deborphan can help me figure this out. So could a nice tree of
dependencies, but I can't remember what program shows this nicely. Anyone
know of such a program?)

2. I run "cruft" first on all directories, trying to avoid special devices
or removing checks on directories where it seems to stall (not the best
way, but the best way available right now). It would also be nice to use
the md5 signatures for files to see if I manually changed a file in the
file system, I'd of course want to back those up (watching for hacks of

3. I remove files that I'm sure I don't want or need that are indicated to
me by cruft. (possibly also removing them from cruft's report file or
files to save from doing step 7)

4. I fix the list of missing files indicated from cruft's report(s). I
also possibly install packages that have files installed, but the package
isn't listed as installed for some reason (not likely to be able to skip
step 7 if I do this second part).

5. I look for packages that are not available for download or available
in a reliable location (Usually all obsolete packages listed in dselect,
sometimes more, some obsolete packages have -src packages that they can be
built from). I then backup these packages using dpkg-repack, or if
available, I grab a copy of the proper package (dpkg-repack doesn't create
packages back to the way they were originally. http://archive.debian.org
may be useful to find packages that are not in the archive anymore.).

6. I run "dpkg --get-selections>/root/myselections.txt" (this file is
important to backup unless you want to go through the list of packages to
install again, step 7 should catch this, or you can add it manually if you
skip step 7).

7. I re-run "cruft" the same way I ran it for step 2.

8. Go through cruft's report and remove any information that I don't want
backup (maybe keep a copy of the missing files separate).

9. Create a list of files to backup using cruft's report as a good guide
(remembering to include myselections.txt and any important packages). /etc
and all the conf file information under /var/lib/dpkg/info may be good to
have (not including unessisary files would be nice).

The rest of the steps do not allow for incremental backups, and may be
modified to allow incremental backups.

10. Append "tar -af backupfile.tar " in a text file, at the beginning of
every line that lists a file to backup except the first one which I do
"tar -cf backupfile.tar" (tr may be helpful, but what's the proper
command? I'd prefer to avoid perl, but is it more common than tr? If so
what's the proper perl -e line?). I then make the text file executable and
execute it.

11. I run "bzip2 -9 backupfile.tar".

12. I use xcdroast or cdrecord or something else to burn backupfile.tar to
a cdrom drive.

I would appreciate help in generating a program/script to automate these
steps (and getting it made into an uploaded package). Also help in
figuring out a good way to make an incremental backup would be very

I don't like that unmaintained or any potentially installed packages are
removed from the Debian archive. I will bring this up with the qa group
when/if I get time.

I would like to see the Debian system administrator's guide's section on
backups get updated to reflect some of the information discussed in this

I worry that not all packages will have md5 signatures of their files. I
remember having a problem with many files not having md5 signatures, or
even some packages having incorrect md5 signatures. I think *every* file
that comes in a .deb should have an md5 signature that gets installed when
the corresponding package gets installed. I want this to be a policy must
as it's good for backups, and detecting system corruptions (hacks and
modifications that are intentional or malicious or accidental). md5
signatures should take little effort to create and maintain with an

I wrote this document mostly from memory, so there may be mistakes, I also
didn't bother checking for grammar, spelling which I usually do.

     Drew Daniels

Reply to: