GeminiSkin
powered by PmWiki

SWM backup strategy documentation

The desired sequence for the backup routine at SWM are as follows:

1. Dirvish performs historical backup for workstations before the main backup job starts as this can be done early and concurrent to the general rsyncs
2. SWMFS rsyncs latest mas90 data to Ponder (so that the data will be on SWMFS when SWMFS syncs to ponder)
3. Ponder rsyncs latest ponder data to SWMFS
4. SWMFS rsyncs latest SWMFS data to Ponder
5. Dirvish performs historical backup services for SWMFS and Ponder--by way of the rsync'd data that was placed on SWMFS
6. Dirvish performs historical backup services for the MAS90 data (check first, but this may be superceded by either the dirvish-workstation backup or via a standard dirvish-runall vault)
7. A log file containing list of items that were backed up is emailed to the backup admins

Things to consider concerning the SWM backup strategy

• Additional temporary space was added to the swmfs server. Verify that space is getting backed up. (check webserver path)
• do mounts first
• log failures & notify the admins in case attention to the backup process is needed. (consider a spreadsheet or html format)

• unmount and idle dirvish disks when not in use to prevent file system corruption.
• turn off forced automatic file system checks and schedule periodic ones
• Periodically(quarterly?) review the size of each vault and the settings of each vault's 'expire-rule' directive to verify that there the data retention time is set as desired.
• Workstation backups are performed via a scheduled task that reads data from a configuration file that is used to specify the workstation that will contain the shares that are to be backed up.
• Workstation data is made accessible to the server by creating a mount point for each host then mounting the specified shares for a host onto the created mountpoint.
• Workstation shares that are to be backed up must be created as an admin share by using a dollar-sign "$" in the share name. This ensures that only network domain administrators can access these shares while remaining invisible when browsing the network.
• A naming convention for the client admin$ shares is currently in use. With only one user per machine at this time there isn't a risk for the following standardized sharenames to be duplicated on the same machine. "mydocs$", "outlook$", and "desktop$"
• Because the workstation backups will occur outside the dirvish-runall command, no extra configuration of Dirvish's master.conf is needed except to include the path names where the BANKS will be mounted.
• Old backups images are automatically removed from the backup drives with the exception that there must always be at least one valid image in a vault. A machine's final backup image will remain on the system that is no longer set to backup will of of Document (for auditors) how the last copy doesn't expire if the client no longer backs up and all previous images have expired.

TODOs:

• create new backup user to replace the reliance on using the rtcg samba user+password
• create a notification system if share not reached
• Document reason WHY (why what??!?)
• After all of the workstation vaults are created, calculate how much space is required and evaluate whether other server vaults (or mvbase data)can be placed onto the [offline]hogwarts vaults.

ClientBackupScript - bash script that processes a control file to perform the backup of the clients.

• Edit
• History
• Source
• Attach File
• Backlinks
• List Group