Backing Up and Recovering Data
About Backing Up Data
To minimize possible data loss, System Administrators must back up the following data:
- Rosetta software
- Producer Agent content
- Oracle database
Each of these data components must be backed up separately on the Deposit Server, Staging Server, and Permanent Repository. The table below describes the location of each component:
| Sub-folder | Contents |
|---|---|
| bytestream_work | Bytestream temporary working folder |
| cc_export_dir | Exported copy configuration files |
| digital_certificate | email-signing certificate |
| format_library_downloads | Downloaded Format Library files |
| logs | Application server logs |
| operational_delivery_shared | Delivery temporary working folder |
| operational_export_directory | Import and export representations during preservation test/action |
| plugins | Plugins packaged with Rosetta are under bundled and custom plugins under custom |
| preserve_pp_docs | Signed-off preservation plans (see the Test Sign-Off section of the Rosetta Preservation Guide) |
| sipTmpDir | SIP temporary working folder |
| software | (legacy - can be removed) |
| sp_bck | Service Pack backup files |
| staff_work_area | Staff users' export/import files |
| ui | Customized logo files |
Rosetta Scripts
System Administrators can use scripts to extract the names of the directories in which Producer Agent content is stored, as described in the following sections:
Deposit Application Role
The following script extracts the name of the directory in which Producer Agent content is stored by the Deposit application role:
|
#!/bin/csh -f rm -f /tmp/deposit_directories sqlplus -s > /tmp/deposit_directories << ! ${ORA_USER_PREFIX}shr00/${ORA_USER_PREFIX}shr00 set pagesize 0 linesize 2048 heading off feedback off trimspool on column tablespace_name format a20 select value from hfrgeneralparameter where name='logic_deposit_area'; exit ! |
Repository Application Role
The following script extracts the name of the directory in which Producer Agent content is stored by the Repository application role:
|
rm -f /tmp/staging_directories sqlplus -s > /tmp/staging_directories << ! ${ORA_USER_PREFIX}shr00/${ORA_USER_PREFIX}shr00 set pagesize 0 linesize 2048 heading off feedback off trimspool on column tablespace_name format a20 select value from storage_parameter,storage,storage_group where key='DIR_ROOT' and module_type='REPOSITORY' and storage_id = storage.id and group_id=storage_group.id; exit ! |
Permanent Repository
The following script extracts the name of the directory in which Producer Agent content is stored in the Permanent Repository:
|
rm -f /tmp/permanent_directories sqlplus -s > /tmp/permanent_directories << ! ${ORA_USER_PREFIX}shr00/${ORA_USER_PREFIX}shr00 set pagesize 0 linesize 2048 heading off feedback off trimspool on column tablespace_name format a20 select value from storage_parameter,storage,storage_group where key='DIR_ROOT' and module_type='PERMANENT' and storage_id = storage.id and group_id=storage_group.id; exit ! |
Backup Strategies
System Administrators can perform backups, as described in the following sections:
About Backup Methods
System Administrators can back up database data using the methods described in the table below:
| Method | Description | When to use |
|---|---|---|
| Cold backup | Performs a full backup on a closed database. Recovery of data that was backed up using this method does not require any additional files. The database can be restored to the same state it was in at the time the backup copy was created. |
Each time the database is closed |
| Hot backup | Performs a full backup on an open database that runs in the archive log mode. Data that was backed up using this method must be recovered together with the archived redo logs, in order to synchronize the database. |
Any time the cold backup method cannot be used due to down time |
| Archive redo logs | Contains only those changes that occurred since the last full backup (either cold or hot). Using archive redo logs allows System Administrators to minimize loss of new data that is stored between the creation of full backup copies. |
Regularly, especially when the hot backup method is used |
Implementing Backup Strategies
The best backup strategy is to perform, nightly, a cold backup, followed by the archiving of redo logs. When a cold backup cannot be performed each night due to down time, it is recommended to perform a hot backup each night instead.
In this case, a System Administrator can always recover data using the backup copies created on a previous night.
When a System Administrator cannot run a full backup every night, it is recommended to minimize the time interval between full backups. In this case, the role of archived redo logs becomes critical because they enable the System Administrator to restore the latest full backup, reapply transactions, and bring the database up to date.
In addition, backup tapes must be read regularly to check their validity. It is recommended to run a full backup tape listing at least once a week. Aside from verifying that the tape can be read properly, System Administrators must check the listing and make sure all expected directories and files were backed up.
The ability to restore an up-to-date site configuration file depends on the frequency at which backups are performed.
Backup Scenarios
System Administrators can use the following combinations of backup methods:
- C.A.S.E. - Cold + Archived redo logs + Site configuration + Export
- H.A.S.E. - Hot + Archived redo logs + Site configuration + Export
- A.S.E. - Archived redo logs + Site configuration + Export
- T.V. - Tape validity check
- B.I. - Backup integrity check
The table below lists possible scenarios for creating backup copies:
| Day | Scenario 1 | Scenario 2 | Scenario 3 |
|---|---|---|---|
| Monday | C.A.S.E. | C.A.S.E. | A.S.E. |
| Tuesday | C.A.S.E. | H.A.S.E. | H.A.S.E. |
| Wednesday | C.A.S.E. | C.A.S.E. | A.S.E. |
| Thursday | C.A.S.E. | H.A.S.E. | A.S.E. |
| Friday | C.A.S.E. | C.A.S.E. | C.A.S.E. |
| Saturday | no backup | no backup | no backup |
| Sunday | no backup | no backup | no backup |
| Weekly | T.V. + B.I. | T.V. + B.I. | T.V. + B.I. |
Recovering Data
After multiple backup copies have been created, System Administrators must recover data using the following rules:
- A database backup must always be followed by file backup.
- If, after creating a backup copy of the database, multiple backup copies of files were created, a System Administrator must recover data using the latest database backup, and the file backup closest to the latest database backup, as shown in the figure below:
Recovering Data From Multiple Backup Copies - If, after creating a backup copy of the database — but before creating a backup copy of files — new files were stored in the system, these files are lost because there are no appropriate records for them in the database, as shown in the figure below:
Loosing Files Added Between Backups