introduction
Application data from all servers is moved to the backup server via a dedicated backup network.
We use script. to dump data from each host in the LIC. The data is copied to the backup host EMG02. This has a locally connected tape drive which is used to make a further copy of everything stored on EMG02. This way we have a level 0 backup of every server, at least once a week, bearing in mind that most servers have at least one other doing the same job.
A cronjob is started every day on the backup server host. This kicks off a script.which uses ssh to run ufsdump on other hosts.
The Database servers (dLB01 and 02) are backed up every night.
The backups will in the first instance be written to a disk array, attached via a A1000 raid drive to EMG02, then when the backups have finished the data will be archived off to a DLT7000 (70gb) tape drive. We currently have 25 tapes.
At present all unix backups are running from EMG02.
A script./usr/local/bin/fullbackup.amp will make a ssh connection to each server and then ufsdump the root, and owww.filesystem into a mounted filesystem /d1 on EMG02.
Each server is scheduled from a config file :- /usr/local/etc/fullbackup.cfg
This increases the backup speed as it utilises the backup network, and as we are writing to disk gives us and online backup.
When this has finished a level 0 dump of each filesystem on EMG02 writes these backups to a locally attached tape drive.
Advantages:-
Filesystem backups are held on disk for a few days.
All backups are written to tape, and held offsite.
backup requirements for different types of host
Web Servers
The web server LAN comprises of at least a pair of identical servers, containing the same web content data for each service, therefore multiple servers sharing services and containing the same data will be called a cluster for the purpose of this documentation.
As the data is duplicated across servers therefore preventing any single point of failure, each cluster can be backed up on a weekly schedule, as opposed to the current backup schedule whereby
All web clusters will be identical excewww.operating system specific configuration, ie ipaddress etc.
(A cluster being defined as a server having at least one other containing the same data)
Therefore each web server in a cluster will hold the same configuration, in each cluster there will be one master server, this server will run rdist enabling all content to be identically replicated to all other servers in the web cluster.
Cluster1 ics01, IWE02 and IWE03
Cluster2 ics01, IWE02 and IWE03
Cluster3 EWE01 and EWE02
Cluster4 EWE03 and EWE04
Application Servers
The application layer will contain the same data across all servers, as all session dependant data is pulled and pushed to the oracle databases.
These servers will be treated as a cluster, (same as the web servers) and can be backed up on a weekly schedule as the data is duplicated.
Database Servers
The data contained in the oracle database's is volatile, this data is pushed onto the mainframe everynight to pickup all policies purchased each day.
Oracle backups will be via script.. each database will enter hot backup mode, backup each tablespace and copy the datafile into a backup filesystem.
Therefore filesystem backups will be used on a daily schedule.
Directory Servers
Directory server will be backed up using the script. supplied with the application, (db2bak and db2ldif) running from cron on a daily basis.
These script. will write out the database backups to a specified directory, which will then be picked up with a filesystem backup on a daliy schedule.
Management Servers
All management servers wil be contain unix script. as a central repository, these servers will therefore require a daily schedule.
Backup Policy
Backup window
The backup window is the time for all backups started to compete, due to the layered architecture there will be multiple backup windows, one for each layer.
Web Servers
Master web server in cluster, weekly level0 backup.
Other cluster servers, fortnightly level0 backup.
Application Servers
Master web server in cluster, weekly level0 backup.
Other cluster servers, fortnightly level0 backup.
Database Servers
Daily Incremental, weekly level0 backup.
Directory Servers
Daily Incremental, weekly level0 backup.
Backup Sizing
The current data requirements are show below:-
|
backup sizing |
||
|---|---|---|
|
System Name |
Total (MB) |
Used (MB) |
|
EWE01 |
12096 |
7860 |
|
... |
|
|
|
BAP05 |
12096 |
7091 |
|
... |
|
|
|
|
|
|
|
Total |
704395 |
201527 |
Backing up onto DLT 7000 tapes
To perform a full system backup the following assumwww.ons have been made:-
DLT 7000 Tape Drive = ~70GB
Maximum data per tape = ~50Gb due to compression working on a 1.4:1 compression ratio.
Total data = ~700GB
Total No Of Tapes = 16
Total Time = 16 hours
tape retention times
Daily = 7 days
Weekly = 4 weeks
Monthly = 52 weeks
Tape naming convention
| tape naming conventions | ||
|---|---|---|
| field | sample value | all values |
| Type | B | B backup, A archive not implemented yet |
| Period | D | D is daily, W is weekly, M is monthly |
| Day of week | MO | MO is Monday, SU is Sunday) |
| Week of month | 5 | 1 - 5 |
| Month | 12 | 1- 12. 1 is January, 12 is December. |
eg. Daily monday is BDMO, Weekly 1 is BW1, Monthly january is BM1
restore files from the LIC backup
If a file needs to be restored that is less than 5 days old, you don't need to bother with the tape archive: it can be copied from EMG02.
