Provided by: fsvs_1.1.17-1_i386 bug

NAME

       FSVS - Backup HOWTO

Preparation

       If you’re going to back up your system, you have to decide what you
       want to have stored in your backup, and what should be left out.

       Depending on your system usage and environment you first have to
       decide:

       · Do you only want to backup your data in /home?

         · Less storage requirements
         · In case of hardware crash the OS must be set up again

       · Do you want to keep track of your configuration in etc?

         · Very small storage overhead
         · Not much use for backup/restore, but shows what has been changed

       · Or do you want to backup your whole installation, from / on?

         · Whole system versioned, restore is only a few commands
         · Much more storage space needed - typically you’d need at least a
           few GB free space.

       The next few moments should be spent thinking about the storage space
       for the repository - will it be on the system harddisk, a secondary or
       an external harddisk, or even off-site?
       Note:
           If you just created a fresh repository, you probably should create
           the ’default’ directory structure for subversion - trunk, branches,
           tags; this layout might be useful for your backups.
            The URL you’d use in fsvs would go to trunk.
       Possibly you’ll have to take the available bandwidth into your
       considerations; a single home directory may be backed up on a 56k
       modem, but a complete system installation would likely need at least
       some kind of DSL or LAN.
       Note:
           If this is a production box with sparse, small changes, you could
           take the initial backup on a local harddisk, transfer the directory
           with some media to the target machine, and switch the URLs.
       A fair bit of time should go to a small investigation which file
       patterns and paths you not want to back-up.

       · Backup files like *.bak, *~, *.tmp, and similar
       · History files: .sh-history and similar in the home-directories
       · Cache directories: your favourite browser might store many MB of
         cached data in you home-directories
       · Virtual system directories, like /proc and /sys, /dev/shmfs.

Telling FSVS what to do

       Given $WC as the working directory - the base of the data you’d like
       backup’ed (/, /home), and $URL as a valid subversion URL to your
       (already created) repository path.
       Independent of all these details the first steps look like these:
                cd $WC
                fsvs urls $URL

        Now you have to say what should be ignored - that’ll differ depending
       on your needs/wishes.
                fsvs ignore ’./**~’ ’./**.tmp’ ’./**.bak’
                fsvs ignore ./proc/ ./sys/ ./tmp/
                fsvs ignore ./var/tmp/ ./var/spool/lpd/
                fsvs ignore ’./var/log/*.gz’
                fsvs ignore ./var/run/ /dev/pts/
                fsvs ignore ’./etc/*.dpkg-dist’ ’./etc/*.dpkg-new’
                fsvs ignore ’./etc/*.dpkg-old’ ’./etc/*.dpkg-bak’

       Note:
           /var/run is for transient files; I’ve heard reports that reverting
           files there can cause problems with running programs.
            Similar for /dev/pts - if that’s a devpts filesystem, you’ll run
           into problems on update or revert - as FSVS won’t be allowed to
           create entries in this directory.
       Now you may find that you’d like to have some files encrypted in your
       backup - like /etc/shadow, or your .ssh/id_* files. So you tell fsvs to
       en/decrypt these files:
                fsvs propset fsvs:commit-pipe ’gpg -er {your backup key}’ /etc/shadow /etc/gshadow
                fsvs propset fsvs:update-pipe ’gpg -d’ /etc/shadow /etc/gshadow

       Note:
           This are just examples. You’ll probably have to exclude some other
           paths and patterns from your backup, and mark some others as to-be-
           filtered.

The first backup

               fsvs commit -m ’First commit!’
        That’s all there is to it!

Further use and maintenance

       The further usage is more or less the commit command from the last
       section.
        When do you have to do some manual work?

       · When ignore patterns change.

         · New filesystems that should be ignored, or would be ignored but
           shouldn’t
         · You find that your favorite word-processor leaves many *.segv files
           behind, and similar things

       · If you get an error message from fsvs, check the arguments and retry.
         In desperate cases (or just because it’s quicker than debugging
         yourself) ask on dev [at] fsvs.tigris.org.

Restoration in a working system

       Depending on the circumstances you can take different ways to restore
       data from your repository.

       ·  ’fsvs export’ allows you to just dump some repository data into your
         filesystem - eg. into a temporary directory to sort things out.
       · Using ’fsvs revert’ you can get older revisions of a given file,
         directory or directory tree inplace.

       · Or you can do a fresh checkout - set an URL in an (empty) directory,
         and update to the needed revision.
       · If everything else fails (no backup media with fsvs on it), you can
         use subversion commands (eg. export) to restore needed parts, and
         update the rest with fsvs.

Recovery for a non-booting system

       In case of a real emergency, when your harddisks crashed or your
       filesystem was eaten and you have to re-partition or re-format, you
       should get your system working again by

       · booting from a knoppix or some other Live-CD (with fsvs on it),
       · partition/format as needed,
       · mount your harddisk partitions below eg. /mnt,
       · and then recovering by
             $ cd /mnt
               $ export FSVS_CONF=/etc/fsvs                    # if non-standard
               $ export FSVS_WAA=/var/spool/fsvs           # if non-standard
               $ fsvs checkout -o softroot=/mnt
       If somebody asks really nice I’d possibly even create a recovery
       command that deduces the softroot parameter from the current working
       directory.
       For more information please take a look at Using an alternate root
       directory.

Feedback

       If you’ve got any questions, ideas, wishes or other feedback, please
       tell us in the mailing list users [at] fsvs.tigris.org.
       Thank you!