Nightly Database Backups

Database backups are managed through SQL backtrack on Dali, degas and max, and via a sybperl script on pop. The databases on pop/prod are not as critical as they are on the other servers; thus we havn't implemented the more complex and robust SQL Backtrack product there.

Dali: prod11 and new_crimson

Database backups are managed via SQL backtrack on dali. All databases receive a full backup nightly. Files are written to dali:/u/backup/[server]/database.

(sybase's cron on dali):
15 19 * * * /export/datatools/scripts/prod11_full.sh
15 19 * * * /export/datatools/scripts/new_crimson_full.sh

Max: peter

Peter's databases are dumped once a night through sql backtrack. Its files are dumped to an nfs mount from pop:/news/peter/database.

(from sybase's cron on max)
15 19 * * * /export/datatools/scripts/peter_full.sh

Degas: crimson and crimson_dev

All of crimson's databases are dumped in full each night. The SQL backtrack process writes the files to degas:/usr/sybase.d/crimson/database.

(from sybase's crontab on degas)
5 19 * * * /usr/sybase.d/datatools/scripts/crimson_full.sh

the crimson_dev server has no backups being done, save for the disaster recovery scripts that run each weekend

Pop: prod

Database backups on prod are handled via a sybperl script in Don P.'s home directory. The files get dumped and then gzip'd in pop:/news/prod.

sybase's cron on pop:
0 23 * * * /u/donp/sybase/dumpall.pl | grep error

Dr. Levin's servers: mdb and syb_dicom_svr

As of current, no backup plan exists for these two servers, located on mfs1 and Sensor's internal box respectively. This is due to mdb crashing in July and syb_dicom_svr being moved external to NIH.


For a full discussion of how SQL backtrack works, click here.