Version 2
Copyright © 2006-2012 Delaware Environmental Observing System
Published: January 13th 2006
| Revision History | ||
|---|---|---|
| Revision 1.1 | 2006/01/13 | GEQ |
| Initial version | ||
| Revision 1.2 | 2006/01/26 | GEQ |
| Added /usr/data1 to the backup list for deosoracleserver. | ||
| Revision 1.3 | 2006/01/27 | GEQ |
| Changed the burn command to growisofs and made the dvdrecord one a footnote. | ||
| Revision 1.4 | 2006/07/31 | GEQ |
| Changed the size calculation to multiply by 2048, the size of the blocks returned my the mkisofs print size command. Corrected size of final field on volume label to 9 or fewer characters. | ||
| Revision 2.1 | 2006/09/26 | GEQ |
| Incremented version number of this document to 2. | ||
| Revision 2.2 | 2006/10/31 | GEQ |
| Added machine naming scheme. | ||
| Revision 2.3 | 2006/11/09 | GEQ |
| Completed backup setup and documented final alterations. | ||
| Revision 2.1.7 | 2008/09/08 | GEQ |
| Updated with information correct as of this date. | ||
Table of Contents
This document outlines the backup regime for the systems making up the DEOS install at the University of Delaware.
In the discussions below a level 0 backup is defined such that all data is stored. A level N backup stores everything changed since the last backup with a smaller number and N > 0 and N ≤ 9.
The systems and database backups described here are implemented to a pair of external 200 Gbyte USB devices. The device
is mounted at /media/usbdisk/ for the system backups and /media/usbdisk1/
for the database backups. The host npfbs00 is used for the destination of all backups.
This section describes the computer naming convention in use at Delaware following the system upgrade to DEOS version 2.1.1.
All names shall be constructed using numerals and lower case letters only.
The first component in the name shall indicate the location of the machine.
The second component in the name shall consist of a single character indicating the usage type of the machine.
The third component in the name shall consist of either two or three characters and indicate the function of the machine.
Table 3. Function Components
| Function Code | Description |
|---|---|
| dbs | Database server |
| fbs | File backup server |
| gs | GIS server |
| ms | Modem server |
| ws | Web (http) server |
In the case of a machine doing double, or triple duty, the function the user sees directly would take precedence, i.e.. a machine acting as a web server and a database server would be called a ws as that's what the user sees.
The fourth and final component of the name shall be a double-digit number intended to differentiate machines with identical names resulting from application of the first three components. The disambiguation field shall be 00 (zero) for the first machine receiving this name and incremented as new machines of the same name are installed. The numbers once used shall not be re-used and the name will thus be retired once the hardware using that name is retired.
In the case of a machine changing function, it will be renamed according to this scheme utilizing the next available disambiguator value.
Some names under this system might be.
Table 4. Examples of Names
| Old Name | New Name | Description |
|---|---|---|
| deosoracleserver | npdbs00 | The production database server in Newark, New Castle County, DE.. |
| deosserver | npws00 | The production web server in Newark, New Castle County, DE.. |
| deosmodemsserver | npms00 | The production modemserver in Newark, New Castle County, DE.. |
| deostest | ntws00 | The test web server in Newark, New Castle County, DE (quite possibly doing database server work also.) |
| N/A | lpms00 | The production modem server in Lewes. Sussex County, DE. |
This section describes the backup details for the machines making up the core DEOS systems.
The backups described here are for the systems at the University of Delaware and so will need to be adapted, changed or even replaced for other installations. The backups here assume that a removable device is the destination of the backup files; in this case one of a pair of 200 Gbyte USB external drives.
The scripts used to backup systems are based on the templates deos/bin/deos_dump_local.sh
and deos/bin/deos_dump_remote.sh. They take one argument,
the numerical dump level needed (a number between 0 and 9). The DEST parameter inside the script specifies the
the directory or remote connection plus path to be used to store the file.
This section does not cover backup of the databases which is dealt separately, below.
The schedule for backups, since it is to disk and thus not as restricted as a tape-based system, is based on a weekly full (level 0) backup, performed on Monday night. Level 9 backups are performed on Tuesday, Wednesday, Friday and Saturday. A level 5 backup is performed on Thursday, and a level 1 on Sunday. This scheme results in only two restore operations ever being required to fully recover a system to a specific date.
The other main advantage is that it allows one week of backups to be off-site, while the second week is written, so in the event of a catastrophic failure, destroying the computer system and the currently active backup device, at most seven days of data are lost.
The web server backup files are stored in /mnt/usbdisk/backups/deosserver/.
The table below describes the details of all the file-systems that are backed-up, as well as what they contain, for this machine.
Table 5. File-systems Backed-Up on this Machine [1]
| File-system | Backup File | TOC File | Description |
|---|---|---|---|
/ | root_N | root_toc_N | System files. |
/boot | boot_N | boot_toc_N | Files required to boot the system. |
The database server backup files are stored in /mnt/usbdisk/backups/npws01/.
The table below describes the details of all the file-systems that are backed-up, as well as what they contain, for this machine.
Table 6. File-systems Backed-Up on this Machine [2]
| File-system | Backup File | TOC File | Description |
|---|---|---|---|
/ | root_N | root_toc_N | System files. |
/usr/data | usr_data_0_N | usr_data_0_toc_N | Raw station data files, both pre- and post-ingest. |
/usr/local | usr-local_N | usr-local_toc_N | Locally installed files |
/boot | boot_N | boot_toc_N | Files required to boot the system. |
/home | home_N | home_toc_N | User files and part of the Oracle install. |
/oracle | oracle_N | oracle_toc_N | Contains the Oracle software installation. |
The database backup files are stored in /media/usbdisk1/oracle/DBNAME/
where DBNAME is the name of the database (the Oracle SID) currently this is NPDB01.
The database backup is performed from within the Oracle Enterprise manager (OEM) to the
/usr/data/oracle/backups directory on the database host.
A cron job synchronizes these files, deleting old ones as necessary, to
the npfbs00 machine.
The backups described here are for the systems at the University of Delaware and so will need to be adapted, changed or even replaced for other installations. The backups here assume that a removable device is the destination of the backup files; in this case one of a pair of 200 Gbyte USB external drives.
The schedule for backups of the production database, since it is to disk and thus not as restricted as a tape-based system, is based on a weekly full (level 0) backup, performed on Monday night and level 1 backups on all other days. This scheme results in only two restore operations ever being required to fully recover a system to a specific date.
The following section describes how to backup a database which is in noarchivelog mode, or to create a full backup of a cold database.
The following table describes the template files stored in deos/database/backup/
and what each one does.
Table 7. Files Utilized in Setting Up Noarchivelog Mode or Cold Database Backups
| File | Description |
|---|---|
catalog_backup.rcv | Contains the rman commands to create a level 0 backup of the database. This file needs to have mode 600 set to hide it's contents from other users as it contains passwords. To use it, the operator must run the command rman and then type "@catalog_backup.rcv". |
The data from networks consisting of point measurements (essentially everything except the NIDS network) are fully recorded in the database during the ingest process. As such, there will already exist a backup of that data as part of the database backup. In order to prevent the file-system containing the already-ingested raw data files filling up, a long-term storage procedure will be performed as needed. It is anticipated that this will be performed annually.
The procedures and policies described here are for the systems at the University of Delaware and so will need to be adapted, changed or even replaced for other installations. The backups here assume that a writable DVD device is the destination of the long-term backup files.
The following procedure outlines how to create an ISO-9660 compatible file-system on a DVD. The procedure as written requires enough space to store the directory hierarchy and the ISO image of the hierarchy simultaneously. The procedure is adapted from this link.
The following procedure must be run as the root user.
Procedure 1. Create a DVD of Raw Data Files
Create and change to a directory in a file-system with enough space ~5Gbytes, to store the data that will make up the DVD.
Copy all files to this directory. (This directory will form the root of the file-system on the DVD.)
Create a file called README in this directory and describe the contents of the DVD in the file.
Check the size of the copied files by running the command mkisofs -print-size ./.
The number the command returns is the number of 2048 byte blocks needed for the ISO image.
Multiply the number of blocks by 2048. If the result is less than 4.3 x 109, the data will fit on a DVD.
To create the ISO image file, run the command mkisofs -o file-name.iso -J -l -R -V volume-label ./.
[3]
Make sure that the destination file-system where file-name.iso will be written is large enough and isn't in the source directory.
To test how the DVD will look to a user before burning, run the following command mount -o loop -t iso9660 file-name.iso /mnt/dvdro.
Run the following command umount /mnt/dvdro.
If the directory hierarchy looks OK, insert a DVD into the DVD writer.
To burn the DVD, run the command growisofs -Z /dev/scd0=file-name.iso -speed=4 (the device name is correct for deosoracleserver as of writing.) [4]
Eject the disk and re-insert the disk. (This step is necessary to complete the burn operation, the next step will fail if it isn't done.)
To verify the disk, run the command mount /mnt/dvdro (this assumes that there is an appropriate entry in the /etc/fstab file.)
Label the media and media case as described below.
It is highly recommended that two copies of each disk are burnt, one stored on site, the other off-site. If so repeat the DVD burn step.
The following sections describe the steps recommended for labeling the DVD. Labeling consists of three items, a volume label, a media label and a media case label.
During the creation of the on-disk ISO file the -V option allows a volume label to be written to
the image. This label appears when the DVD itself is mounted, for example, in Windows Explorer.
For the long-term data backup application it is recommended that the volume label be created utilizing the fields in the following table. The fields make up a single record of 32 or fewer characters.
Table 8. Volume Label Field Descriptions
| No. | Field Name | Width[a] | Description |
|---|---|---|---|
| 1 | Data Type | 12 | What type of data is stored. Possible entries could be, 'Station Data', 'Radar Data'. |
| 2 | Separator | 1 | A single space character. |
| 3 | Time | 9 | This is the year or year range the data covers, including partial years. An example might be 2004-2005. |
| 4 | Separator | 1 | A single space character. |
| 5 | Unassigned | ≤ 9 | The remaining space (of nine or fewer characters) may be used for anything pertinent. |
[a] This indicates the maximum suggested width. | |||
The media itself should have a label, such that the media and the case storing the media can be re-united if separated. As such, the media label is a minimal requirement.
If possible, the media label should be added in permanent marker and legibly written.
For the long-term data backup application it is recommended that the media label be created utilizing the record in the following table.
The media case itself should have a label, such that the media and the case storing the media can be re-united if separated. The media label is the primary external information provider for the contents of the disk.
If possible, the media case label should be typed. A possibility would to print a page using a word processor, cut the paper to size and place the label in the media. If the text is hand-written, make sure it is legible.
For the long-term data backup application it is recommended that the media case label be created utilizing the records in the following table. The data below should be considered a minimum, the person generating the media is encouraged to add any additional pertinent data. After the 6 suggested items.
Table 10. Media Case Label Record Descriptions
| No. | Name | Fixed Text | Variable Text Description |
|---|---|---|---|
| 1 | Archive ID | Archive Data: | See above, this item must be present, and match the description on the media as described above. |
| 2 | Number in Set | Disk | It is recommended that at least two DVDs are burnt for each ISO file image created. This field indicates which DVD in the set this is, and the total number in the set. |
| 3 | Data Type | Data Stored: | What type of data is stored. Possible entries could be, 'Station Data' or 'Radar Data'. A list of which stations, or networks are included, or excluded might be also be appropriate. |
| 4 | Data Time | Data Time Range: | This is the year, or year range, the data covers, including partial years. An example might be 2004-2005. Additional text may be appropriate, for example providing more details of what range, or excluded items are not available. |
| 5 | Disk Generation Time | Generated on: | This would be the date that the disk was burnt pre-pended with "Generated on:". An example might be "Generated on: 2005/01/12". It is recommended that the date string be YYYY/MM/DD to avoid confusion. |
| 6 | Responsible Party | Generated by: | This would be the name and email address (in parentheses) of the person generating the disk. An example might be "John Doe (jdoe@udel.edu)". |
[1] TOC is a table-of-contents file, readable by the restore program.
N is the backup level.
[2] TOC is a table-of-contents file, readable by the restore program.
N is the backup level.
[3] The command line options are:
-J: Generate Joliet directory records in addition to the iso9660 filenames |
-l: Use full 31 character filenames |
-R: Generate RockRidge protocol records |
-V: Use a volume label. |
volume-label: See the next section for recommendations on the text for the
volume-label option. |
[4] If the main command fails, try this command dvdrecord -dao -dev=1,0,0 file-name.iso (the device number is correct for deosoracleserver as of writing.)