Re: [Dump-users] Imcremental Backups

[Keith G. Robertson-T. <dum...@sl...>]

Verily I say unto thee, that Bruce Hyatt spake thusly:
> I have read the dump man-page and searched the mailing-list archives
> but I'm still not quite certain about doing incremental backups.
> 
> Assume I do a level 0 backup on Jan 10 and then do a level 1 backup 
> every day after.

You can do that, but that is not an incremental backup, it's what's
called a differential backup.

Put simply:

Full Backup = All files.
Differential = All files that have changed since the last /full/ backup.
Incremental = All files that have changed since the last differential or
incremental backup.

Level 0 is always a full backup.
Level 1 is always a differential backup.
Level <n> is an incremental backup /if/ there are any other backups
between 0 and <n>, or a differential backup otherwise.

Advantages and disadvantages:

A backup policy which utilises only differentials takes longer (overall)
to create, but less time to restore.

A backup policy which utilises incrementals takes less time (overall) to
create, but more time to restore.

Here's what you should be doing (IMHO):

Day	| Level	| Set
-------------------------
1 	| 0 	| 1
2 	| 1 	| 1
3 	| 2 	| 1
4 	| 3	| 1
5 	| 4	| 1
6 	| 5	| 1
7	| 6	| 1
8	| 0	| 2
9	| 1	| 2
10	| 2	| 2
11	| 3	| 2
12	| 4	| 2
13	| 5	| 2
14 	| 6	| 2

Repeat.

E.g. have your backup directories as follows:
(In this example, a system with the hostname "venus")

/mnt/backup/venus/sets/1/dumps/0
/mnt/backup/venus/sets/1/dumps/1
/mnt/backup/venus/sets/1/dumps/2
/mnt/backup/venus/sets/1/dumps/3
/mnt/backup/venus/sets/1/dumps/4
/mnt/backup/venus/sets/1/dumps/5
/mnt/backup/venus/sets/1/dumps/6

/mnt/backup/venus/sets/2/dumps/0
/mnt/backup/venus/sets/2/dumps/1
/mnt/backup/venus/sets/2/dumps/2
/mnt/backup/venus/sets/2/dumps/3
/mnt/backup/venus/sets/2/dumps/4
/mnt/backup/venus/sets/2/dumps/5
/mnt/backup/venus/sets/2/dumps/6

Then backup using the following:

#!/bin/bash

# /mnt/backup must be available and defined in /etc/fstab
mount /mnt/backup

mypc=$(hostname)
backup_path="/mnt/backup/${mypc}/sets"

mkdir -p "${backup_path}"/{1,2}/dumps/{0,1,2,3,4,5,6}

if [ ! -e "${backup_path}/current" ]
   then
      echo 1 > "${backup_path}/current"
fi

level=$(expr $(date +%u) - 1)

read current_set < "${backup_path}/current"
if [ $level -eq 6 ]
   then
      if [ $current_set -eq 1 ]
         then
            next_set=2
         else
            next_set=1
      fi
fi

uid=$(date +%Y%m%d)

dump -${level}u -z \
 -f "${backup_path}/${current_set}/dumps/${level}/${mypc}-${uid}.dump" /

rm -f "${backup_path}/current"
echo $next_set > "${backup_path}/current"

umount /mnt/backup

exit 0
###

I recommend using LVM snapshots to ensure your dumps are consistent.

Save the above as "/usr/local/bin/backup", then chown root:root
"/usr/local/bin/backup", then chmod 700 "/usr/local/bin/backup".
Add a crontab entry to run e.g. at 3AM every morning.

The reason you want two weeks worth of backups is - if you were to
continually overwrite the level 0 backup, then it failed, and the
filesystem subsequently became corrupted, then you'd have no usable
backups to restore from.

> Then assume I add filea on Jan 11 and fileb on Jan 12. The way I read
> the man page, the Jan 12 dump will include filea even though it is 
> included in the Jan 11 dump. Is that correct?

Yes, because you'd be doing a differential backup.

If instead of doing 0, 1, 1, 1, etc.; you do 0, 1, 2, 3, etc.; then that
won't happen (unless filea somehow changes between one incremental and
the next).

> Also, the way I read the man page, I cannot dump fat32 files

Correct. Dump is for ext2/3 filesystems only.

> but I can dump to a fat32 partition

You can dump /to/ any filesystem that is writable under Linux, since you
are essentially just creating a file. However, take care that you don't
exceed any given filesystem's file size limit (e.g. FAT32 = 4GB).

> and restore ext3 files from it. Is THAT correct?

Yes.

-- 
Regards,
Keith G. Robertson-Turner