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
(sybase's cron on dali):
15 19 * * * /export/datatools/scripts/prod11_full.sh
15 19 * * * /export/datatools/scripts/new_crimson_full.sh
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
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 weekendPop: 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
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.