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.

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

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 weekend

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.