Carnegie Mellon
Computing Services
Backup
Implementation Proposal
Document Revision: 0.2 05/03/2006 (wcw)
2006 Carnegie Mellon University. All Rights Reserved
Carnegie Mellon
Computing Services
Ideal Multi-tier backup architecture
Tier 1
Tier 2
Backup Server
For server machines
Backup Server
for client machines
Client backups
Client Restores
Tier 3
Offsite
Server backup
Restore of the client
backup server
Backups and restores are isolated per tier
For example, a client restore only goes to the backup server
for client machines; it never crosses to the backup
server for server machines
The best backup software is used at each tier (rather
than relying on a package that does everything
poorly)
This optimizes for the common operations but makes
the less common longer: if everything blew up,
youd start by restoring from off-site, then youd
restore the client backup servers before you could
start restoring the clients.
Restore from off-site of the
server backup
Tier 1: Desktop/Client Backup
Optimized for user self-service restores; assumes
variable bandwidth networking; assumes mostly file
restores
Tier 2: Server restores
Optimized for entire disk restores (generally will only do
a restore if a RAID set fails)
Can assume fast networking
Tier 3: Off-site
Encryption likely required
Much higher latency to access the data
Carnegie Mellon
Computing Services
Software
Tier 1: LiveBackup
Continuous Data Protection
As changes are made, backups are saved to the cache and then sent to the server
Network friendly
Wont send duplicate data to the server
Data is compressed and encrypted before sent
Only sends changes incrementally so there isnt a big network burst when backups
happen
Uses https as a transport so backups can happen anywhere there is network
connectivity to the server
Bare metal restore
Boot CD/DVD can be made to restore a system from a blank hard drive
Users restore their own files using a native Windows interface
Unfortunately
Currently available under Windows only (though a mac port rumored)
Server doesnt scale horizontally
Reports of slowness on client machines
Software assumes strong central IT control and doesnt empower users
Carnegie Mellon
Computing Services
Software
Tier 1: Stage
Stage is the existing system to back up AFS
This allows us to keep running stage
without having to either pick a package
that supports AFS or write custom code to
merge it in with another package.
Carnegie Mellon
Computing Services
Software
Tier 1/2/3: TiNA
so much for the ideal model
Crosses multiple tiers as follows:
Tier 1: for Mac client backups
Tier 2: Backs up Storactive/Stage (AFS); replaces Amanda; Database plug-ins
Tier 3: Manages off-site data
Features include:
Synthentic Full
After the first backup, only the changes need to be sent over the network.
Less storage is required as you dont need to keep multiple full dumps around
Tape encryption
Good admin interface for doing restores
Unfortunately
Current version (v4.0) doesnt support mutual authn and so cant deploy until the
beta (v4.1) mutual auth is released.
Doesnt scale well horizontally yet (though rumors are things are getting better on
this front in 4.1).
Carnegie Mellon
Computing Services
Implementation:
LiveBackup
Single Dell 2850 with local ACNC RAID
Initial pilot of 200 machines Plan back up all Computing Services Windows
desktops
Hardware should grow to at least 500 machines
Current desktop/laptops being backed up via ArcServ will be migrated to
LiveBackup
Single Gigabit ethernet network connection to campus network. Expected to
be on VLAN14.
6
Carnegie Mellon
Computing Services
Implementation:
TiNA
PowerVault
132T
PowerVault
132T
Single Dell 2850 with locally attached tape drives as the primary TiNA server
Disk backup is added via NFS mount of RAID from the Storage nodes (dont want to put too many
SCSI devices on a single box)
Off-site backup is done via tape to the tape library (for now)
Network interface to campus/clients is a single Gigabit ethernet connection on VLAN10.
Network interface to storage is a single Gigabit ethernet connection to the high speed A100
internal network VLAN. This needs to be created by NG.
Each storage node will have one service connection (VLAN10) and one connection to the high
speed A100 internal network VLAN. NFS traffic will not go over the service connection.
Carnegie Mellon
Computing Services
Rack Layout
Space reserved for
two additional RAID
arrays for the
storage node
PowerVault
132T
Tape drives
attached to the
servers PCI SCSI
card
PowerVault
132T
Tina Backup
Server
storage node
ACNC RAID arrays
atached to the PCI
SCSI card
Exact ordering to the diagram is not required
Machines may share the same rack
Diagram is not to scale
The main thing that matters here is that space is that 6U of space for
two RAID arrays is reserved for each storage node being installed
8
Carnegie Mellon
Computing Services
Hardware Summary
Service
Machine
LiveBackup Server
RU
Gigabit ports
Notes
Dell 2850
ACNC RAID
Dell 2850
Tina tape Drive
Dell 132T
SCSI connection to Tina Server
Tina tape Drive
Dell 132T
SCSI connection to Tina Server
Dell 2850
Storage Node disks
ACNC RAID
SCSI connection to storage node
Storage Node disks
ACNC RAID
SCSI connection to storage node
Storage node expansion
filler
filler panel for future RAID unit
Storage node expansion
filler
filler panel for future RAID unit
Dell 2850
Storage Node disks
ACNC RAID
SCSI connection to storage node
Storage Node disks
ACNC RAID
SCSI connection to storage node
Storage node expansion
filler
filler panel for future RAID unit
Storage node expansion
filler
filler panel for future RAID unit
Dell 2850
Storage Node disks
ACNC RAID
SCSI connection to storage node
Storage Node disks
ACNC RAID
SCSI connection to storage node
Storage node expansion
filler
filler panel for future RAID unit
Storage node expansion
filler
filler panel for future RAID unit
57
LiveBackup
Tina Server
Tina Storage Node
Tina Storage Node
Tina Storage Node
Totals
SCSI connection to LiveBackup Server
