Customer Backups

From JCWiki
Revision as of 17:10, 1 March 2013 by 70.230.212.110 (talk) (Created page with "___TOC___ Backups are performed for customers upon request. When someone does ask, they should really only be asking for real user data dirs to be backed up, though we won’...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

_

_

Backups are performed for customers upon request. When someone does ask, they should really only be asking for real user data dirs to be backed up, though we won’t refuse any reasonable request.

Our backup program does not follow symlinks so, for instance, if someone asks for backups on FreeBSD, and one of the directories they want backed up is /home, remember that that is just a symlink to /usr/home - so when you enter it into the backup file on their jail you need to enter it as /usr/home,

Backup entries are stored in /usr/local/jail/bin/backup.config (FreeBSD) /usr/local/sbin/backup.config (linux)

The first line in the file refers to where the backups go on the backup server, the second line is the backup server they go to. Each line beyond that is an actual directory to be backed up (vb is an alias to vi the backup file):

jail15# vb

#!/bin/sh
backupdir=/data/jail15
server=backup1

## ENTRY /mnt/backup
## ENTRY /etc
## ENTRY /usr/local/etc
## ENTRY /usr/local/jail
## ENTRY /root/logs
## ENTRY /mnt/data1/69.55.238.98-col00214-DIR/etc
## ENTRY /mnt/data1/69.55.238.98-col00214-DIR/root
## ENTRY /mnt/data1/69.55.238.98-col00214-DIR/usr/home

When adding new directories, make sure the dirs backing up really exist by ls’ing them

To search for existing backups:

jail15# gb col00214
## ENTRY /mnt/data1/69.55.238.98-col00214-DIR/etc
## ENTRY /mnt/data1/69.55.238.98-col00214-DIR/root
## ENTRY /mnt/data1/69.55.238.98-col00214-DIR/usr/home
## ENTRY /mnt/data1/69.55.238.98-col00214-DIR/usr/local
## ENTRY /mnt/data1/69.55.238.98-col00214-DIR/var/log
## ENTRY /mnt/data1/69.55.238.98-col00214-DIR/www
## ENTRY /mnt/data1/69.55.238.98-col00214-DIR/var/spool/postfix

The backup script runs nightly at various times, but generally between midnight at 3am. If the backup script tries to backup a dir that doesn’t exist, an email will be sent to the support queue.

The mechanism behind backups is thus:

When the backups are to be run, a script called backup is run. It does 2 things:

  • update all our scripts from the repository on backup2
  • start the actual backup script

The backup script reads the config file and rsync’s directories defined against a corresponding directory on the backup server specified. So, if the first line in the config file is backupdir=/data/jail15Then backups are made to backup1:/data/jail15/0 Because these backups are incremental and destructive, only changed files are updated and files which don’t exist locally are removed from backup1. This makes the backups very fast and efficient.

After backups are made from customer machines to the backup server, a housekeeping script fires off on the backup server which deletes the backups made 7 nights ago, rotates (renames) nights -1 thru -6 “down” in the count, and makes a snapshot of the previous night’s backup. Specifically, here’s what the script does:

rm -fr [dir]/6
          mv [dir]/5 [dir]/6
          mv [dir]/4 [dir]/5
          mv [dir]/3 [dir]/4
          mv [dir]/2 [dir]/3
          mv [dir]/1 [dir]/2
          gcp -al [dir]/0 [dir]/1

This means at any point during the day, there are 6-7 days worth of backups for any given machine.

Restoring backups

The backups are copied to their respecitve directories on the backup servers nightly, and the houseclean script continuously rotates (effectively deleting all backup files older than 2 days) so it s very important to respond to backup restore requests immediately - if they sit for too long, they could get automatically deleted.

We do not replace the backup files on their system - we simply make and copy the tarball that they require onto their system and put it in their / directory. When you respond to their email telling them that their backup has been copied onto their system, always tell them that they should place the tarball in a temp directory and explode it there, so they do not overwrite other things already on their system.

Also, it is a good idea to make a temp directory on the backup server and place the last few days of that persons backups in it, so they do not get deleted by the housecleaning script - this is helpful if the person deleted the tarball accidently, or something else goes wrong.