Child pages
  • Backup Schedules and Methods
Skip to end of metadata
Go to start of metadata

See IT Policy: Backups for further information about the backup policies of the school.

Server Backup Schedules

The information about backups being performed by the SoIC systems staff are available using the following reports:

PLEASE NOTE : Systems not listed in the All Servers report are NOT being backed up by the systems staff.

Footnotes From The Above Backup Reports:

  1. The SVN repository is dumped using 'svnadmin hotcopy' and the resulting dump is backed up
  2. The mysql database is dumped using 'mysqldump' and the resulting dump is backed up
  3. The postgres database is dumped using 'pg_dumpall' and the resulting dump is backed up

Backup Methods


Commvault-AllDisks -  Commvault is the standard backup system used for Virtual Machines (VMs) in the UITS Intelligent Infrastructure system.  VMs using this Commvault-ALLDisks backup method have all virtual disks associated with a VM backed up nightly.  Backups are kept for 14 days only.  These backups also allow rollback of the VM to the snapshot for any day during this 14 day window which provides disaster recovery should something go terribly wrong.


Commvault-OSDisk -  Commvault is the standard backup system used for Virtual Machines (VMs) in the UITS Intelligent Infrastructure system.  VMs using this Commvault-OSDisk backup method have only the OS/Boot disk backed up and these backups are only done weekly.  Backups are kept for 14 days only and no virtual disks other than the OS/Boot disk are backed up.  These backups are intended to be for Disaster Recovery only for the OS/Boot disk.  VMs needing nightly backups of all virtual disks will need to use the Commvault-ALLDisks backup method.


KVM-Snapshot -Virtual Machines (VMs) running on the SoIC KVM servers can be backed up to the IU Scholarly Data Archive (SDA) using a snapshot mechanism.  This involves 1) shutting the VM down, 2) pushing a copy of the VM disk image to the SDA, and 3) bringing the VM back up.  There will be significant downtime involved so this method is only suited for periodic disaster recovery backups.


SDA - The Scholarly Data Archive (SDA) (formerly MDSS) provides an effective way to archive important data. Backups utilizing SDA are performed using tar run via cron jobs with the data automatically pushed to the SDA. Data on the SDA is replicated between Bloomington and Indianapolis locations, providing automatic replication and offsite storage.  SDA backups can be periodic full backups or incrementals following an industry standard GFS (Grandfather, Father, Son) backup strategy.

ILS-SDA - ILS uses an industry standard GFS (Grandfather, Father, Son) backup strategy.  The primary NFS servers use UITS-HSI to backup to the Scholarly Data Archive (SDA) (formerly MDSS)   Backups are optimized to detect if the file structure has been updated since the last backup (date-time or size).  The SDA backup storage area is reviewed (programmatically) to maintain one yearly backup, three monthly backups, and one weekly backup.  Other systems do selective backups, based on there function, of the important configuration information needed to rebuild the server.  This selective backup is copied to the NFS server.

ILS-Amanda - ILS uses amanda (Advanced Maryland Automatic Network Disk Archiver) to create on-site backups for "data deemed not critical to the operation of the school".  Amanda schedules backups based on a seven day backup cycle and tape availability.  

Custom Backups

This table shows the systems with backups being performed in some unusual way. Please see the above reports for the standard backups being performed.

Server

OS

Primary Function

Data Backed Up

Method

Schedule

Retention Window

None at this time