Ryan Krause Ryan Radschlag Hartford Jt. #1 School District

 Prior to 2006  Tape Drives  Commercial Backup Software  Multiple Buildings  Multiple Tape Drives  Multiple People doing Rotations  Very little disaster protection  Result: Very Inconsistent Backups

 2006  Still Slow WAN Links  Purchased One Server ▪ Single-core Xeon ▪ 1G Memory ▪ 6 x 250GB Drives (in RAID 5) ▪ SUSE Linux Enterprise Server 9  Stopped Using Tape Drives  Located as far away from MDF as possible  Used RSYNC to mirror files from source to backup

 Open-source Cross-platform Synchronization  Minimizes Data Transfer  Only send changed files  Only send changed blocks  Client or Daemon Modes  Simple, Efficient, and Effective  MANY different uses  Enhanced By Running a “Rotation” Script on our Backup Pool

 Difficult to Manage  No GUI  No Reporting/Alerting  Configuration Changes at Each Client  Pool “Rotations” Took HOURS  No Compression  Lacked flexibility

 A “New” and More Streamlined Way  Extracts Backup Data Using:  RSYNC  Samba  TAR  Compression, Pooling, Deduplication  Web-based GUI  Features  Flexibility

 December 2010  Using Same Old Backup Server  Added Secondary Backup Server ▪ Single-core P4 ▪ 2GB Memory ▪ 3 x 250GB Drives (RAID 5)  Both Located Across Town  Added a Third Backup Server ▪ VM Hosted at our MDF ▪ Temporary Until Remote Servers are Decommissioned

 Backup of:  Locked Databases  File Trustee Data  eDirectory/AD  Servers  Deduplication  ZFS for Block-Level Deduplication  Storage Appliances  Securing your Backups (Physical, SSH, Auth, etc)

 Questions, Thoughts, Etc??