Difference between revisions of "Backup with dar"
(Typical scenario) |
|||
Line 88: | Line 88: | ||
===Backup disk size limits workaround=== | ===Backup disk size limits workaround=== | ||
+ | |||
+ | {{Warning box|The method described here permits to get daily backup work on a support with not enough space to do a new daily full backup without, before, deleting the current backup. So it must be considered with caution : if the backup fails, you'll be whithout any backup available. As explained, use this method only if security of your data is not essential, or buy a larger disk for storage.}} | ||
If having issues with the size of removable backup disks (eg 120Gb IDE on a workstation) versus the resultant backup data size (eg 120Gb of data compressing to approx 50Gb), then you can manually setup a cron job to delete the old backup file(s) before saving the new backup file(s). | If having issues with the size of removable backup disks (eg 120Gb IDE on a workstation) versus the resultant backup data size (eg 120Gb of data compressing to approx 50Gb), then you can manually setup a cron job to delete the old backup file(s) before saving the new backup file(s). | ||
Line 94: | Line 96: | ||
To workaround this, create a cron job and put it in /etc/cron.d with a script in /opt/scripts/XXX, which mounts the drive and deletes the old backup just before the new full backup commences. | To workaround this, create a cron job and put it in /etc/cron.d with a script in /opt/scripts/XXX, which mounts the drive and deletes the old backup just before the new full backup commences. | ||
− | This will delete the old backup before the new backup commences, which is different to how the backup is designed to work by default. It is necessary to | + | This will delete the old backup before the new backup commences, which is different to how the backup is designed to work by default. It is necessary to forgot the security of retaining the old backup until the new one has completed, in order to use the available hardware (smaller disk). |
Revision as of 22:45, 24 July 2009
Backup with dar using e-smith-backup
http://wiki.contribs.org/SME_Server:Documentation:Administration_Manual:Chapter10#Backup_or_restore
Typical scenarios
Select Configure Workstation Backup and click perform
With Windows workstations backing up to a removable or shared drive in a workstation, with a weekly full backup on Friday and subsequent daily incremental backups & you wish to retain 2 backup sets on each disk, with backup to start at 8pm and finish at 8am.
Backup is enabled. Backup is made on LAN workstation netshare via cifs Destination backup share folder is backup Login is backupuser Password is ******** Number of rotating backup sets is 2 Number of daily backups contained in each set is 7 Compression level (0-9) of backup is 4 Daily backup occurs at 20:00 Each daily backup session is cleanly timed out after 12h except full backups which are cleanly timed out after 24 hours Full backup session (new backup sets) is allowed only on Friday
USB Disk attached to Server
For help with USB Disk preparation see USBDisks
Backup is Enabled. Backup is made on local USB disk Destination backup share folder is media/Diskname Number of rotating backup sets is 2 Number of daily backups contained in each set is 14 Compression level (0-9) of backup is 4 Daily backup occurs at 18:30 Each daily backup session is cleanly timed out after 8 hours. Full backup sessions (new backup set) are allowed everyday
Backup Sets
The number of increments in a set is only equal to the "Daily backups in each set" if a multiple of 7. For instance choose 27, and you only get 21 increments, whereas 28 gives 28 increments. Or choose 3, and it gives 7 increments. (This assumes that "Full backup is allowed on" is not set to everyday).
If you want the rotation, and full backup, to occur on a specified day, then choose that day in the panel, and choose a multiple of 7 for "Daily backups in each set".
if you want a fixed number of increments in each set, then choose "Full backup is allowed on" = Anyday.
Backup timeouts explained
Even if you choose not to timeout your full backups, a full backup cannot exceed 24h (or the cron will launch a conflicting backup job).
So when you choose "Don't timeout full backup sessions", there is a default timeout just before 24h. Then the full backup can stop cleanly, and the new (incremental) backup will continue the backup.
The real goal of setting a timeout+"Don't timeout full backup sessions" is for big user files systems, when we want that the backup session occurs only the night on the week days (we need the cpu and the bandwith for something else than backuping, and if we backup on the time there is too much activity, the risk of a failing backup with dar grows up, because a file can be modified during his backup), and all the days on saturday and sunday (for most common case).
We can set :
Backup time : 10:00 PM DaysInSet : 7 FullDay on friday or saturday IncOnlyTimeOut : yes Timeout : 8 (backup stops at 6:00 AM on week days)
On monday morning we can have fully backuped our server, even if the time to do it is about 32 hours (24+8). On the week days the server and the lan are are not busy with backups between 6:00 AM and 10:00 PM
For servers that have large amounts of data, 200 GB+, you may see the following error with incremental backups
Aborting program. User refused to continue while asking: /mnt/smb/server.2activepr.ro/set0/full-20090404.1.dar is required for further operation, please provide the file.
To workaround set timeout to 23 hrs, this allows the backup to timeout cleanly, it will restart and attempt to complete the first full backup on the next run.
Backup disk size limits workaround
If having issues with the size of removable backup disks (eg 120Gb IDE on a workstation) versus the resultant backup data size (eg 120Gb of data compressing to approx 50Gb), then you can manually setup a cron job to delete the old backup file(s) before saving the new backup file(s).
The specific issue experienced was being able to get one full backup onto a disk, and a weeks worth of daily incrementals, but the next weekly full backup failed, due to the need to save the new backup in the tmp folder on the removable disk, before deleting the old backup files. There was not enough space on the disk (size) being used.
To workaround this, create a cron job and put it in /etc/cron.d with a script in /opt/scripts/XXX, which mounts the drive and deletes the old backup just before the new full backup commences. This will delete the old backup before the new backup commences, which is different to how the backup is designed to work by default. It is necessary to forgot the security of retaining the old backup until the new one has completed, in order to use the available hardware (smaller disk).
Create the deletion script
pico -w /opt/scripts/deletebkp1
Enter the following (using your share name, user, pasword & domain)
umount /mnt/smb /bin/mount -t cifs //stationXX/bkp1 /mnt/smb -o username=XXXXXX,password=XXXXXXXXXXXXX rm -f -R /mnt/smb/servername.yourdomain.com/ rm -f -R /mnt/smb/tmp_dir/
Then save & exit
Ctrl o Ctrl x
Create the cron job
pico -w /etc/cron.d/deletebkp1
Enter the following (setting the time & day to be just before your scheduled backup time), see below. The following values suit a scheduled full backup for 2.00am on Saturday morning (ie Friday evening), where the old backup gets deleted at 1:50am
50 1 * * 6 root . /opt/scripts/deletebkp1
Then save & exit
Ctrl o Ctrl x
Cron entries format is as follows:
+-----------------------Minute (0-59) | +-------------------Hour of Day (0-23) | | +---------------Day of Month (1-31) | | | +-----------Month of Year (1-12) | | | | +-------Day of Week (0=Sun,6=Sat) 50 1 * * 6 root . /opt/scripts/deletebkp1
Howto set the backup file slice size
The default slice or part setting is 700Mb (to suit CD's). The slice size can be changed for example to suit 4.7Gb DVD's, by making 3 parts fit on to a DVD, so the required slice size is 1529Mb (allowing for overheads & real data size).
Create the custom template fragment
mkdir -p /etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf cp /etc/e-smith/templates/etc/dar/DailyBackup.dcf/90slice /etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf
(the above cp command is all on one line)
Modify the file size & save
pico -w /etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf/90slice
Edit it to read like this
{ ($backupwk{Slice} || '1529M') eq '1529M' ? "--slice 1529M\n" : "--slice $backup }
Then save & exit
Ctrl o Ctrl x
Then expand the template with
expand-template /etc/dar/DailyBackup.dcf
The next time the backup runs, the resultant backup file will be split into 1.529Gb part sizes.
Adding Directories and Files to the list of backup inclusions
The default backup does not include /opt
To add /opt to the backup inclusion list, create a custom template fragment and add opt to the list.
Create custom template fragment to add needed files and directories
mkdir -p /etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf pico -w /etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf/41go-into --go-into opt
Then expand the template
expand-template /etc/dar/DailyBackup.dcf
Check your backup (eg using the mc dar plugin) to see that /opt is now included.
It is also prudent to do a test full restore and verify that /opt (& all other backed up directories & files) are restored, as anticipated.
If something is wrong with your backup or restore procedures, then required files may not be backed up and restored, so it is wise to do a test full backup & restore to fully prove your procedures are working correctly.
Some notes
Some things to keep in mind when using SME-Server backup:
Backup file slices are NOT autonomous
The catalogue of the contents of the backup is put in the last slice. If for some reason the last slice can not be written (e.g. backup medium is full or network failure), is lost or corrupt, the slices already saved are useless.