Backup3G/User Guide/Media
This page was last modified 10:38, 6 March 2008.From Documentation
Revision as of 05:56, 18 April 2006 Daniels (Talk | contribs) ← Previous diff |
Current revision Moff (Talk | contribs) (Backup3G 5.1/User Guide/Media moved to Backup3G/User Guide/Media) |
||
Line 1: | Line 1: | ||
- | An essential element of the backup and recovery mechanism is effective media management. | + | An essential element of the backup and recovery mechanism is effective media management. This section explains some media concepts and provides examples of good practice. Managing Removable Media on page 115 describes how to manage and use media through backup3G. |
- | This chapter explains some media concepts and provides examples of | + | |
- | good practice. Managing Removable Media on page 115 describes how to manage and | + | Backup3G’s facilities include: |
- | use media through backup3G. | + | *a comprehensive media database with support for any media type |
- | backup3G’s facilities include: | + | *flexible retention periods and balancing of media usage |
- | • a comprehensive media database with support for any media type | + | *tracking of media movement on- and offsite |
- | • flexible retention periods and balancing of media usage | + | *advanced search facilities |
- | • tracking of media movement on- and offsite | + | *media usage reports and volume labeling. |
- | • advanced search facilities | + | |
- | • media usage reports and volume labeling. | + | |
- | Note References to tapes and tape drives in backup3G and in this manual | + | ---- |
- | generally apply to any type of removable media. | + | ;Note: References to tapes and tape drives in backup3G and in this manual generally apply to any type of removable media. |
- | 54 Information on Media | + | ---- |
- | Media Database | + | |
- | The media database is kept on your backup3G master host, and stores information | + | <br> |
- | about all your removable media – both used and unused – and the data they contain. | + | == Media Database == |
- | The main components of the database are: | + | |
- | media details information about all the media which can be used for backup and | + | The media database is kept on your backup3G master host, and stores information about all your removable media – both used and unused – and the data they contain. The main components of the database are: |
- | recovery—e.g. media type, usage, location | + | ;''media details'': information about all the media which can be used for backup and recovery—e.g. media type, usage, location |
- | media contents information about data stored on the media, such as online indexes | + | ;''media contents'': information about data stored on the media, such as online indexes and lists of base directories that have been backed up |
- | and lists of base directories that have been backed up | + | ;''media support tables'': information that describes how media are used in your organization—e.g. media types, locations, label types. |
- | media support tables | + | |
- | information that describes how media are used in your | + | Figure 9 — Media contents listing |
- | organization—e.g. media types, locations, label types. | + | |
- | Figure 9 — Media contents listing | + | The database is set up when you first configure the backup3G master host (see Add Media to the Media Library on page 148). These details are automatically updated as each backup is run and when you use the options in the Media Management module. |
- | The database is set up when you first configure the backup3G master host (see Add | + | |
- | Media to the Media Library on page 148). These details are automatically updated as | + | |
- | each backup is run and when you use the options in the Media Management module. | + | <br> |
- | Information on Media 55 | + | == Media Management Concepts == |
- | Media Management Concepts | + | |
- | Removable media are used in backup3G to store data for backups and other purposes. | + | Removable media are used in backup3G to store data for backups and other purposes. Typically, high-capacity tapes are used (e.g. SDLT, LTO, DLT), but low capacity legacy tapes (e.g. Exabyte, DAT), diskettes, and optical media can equally well be used. |
- | Typically, high-capacity tapes are used (e.g. Exabyte, DAT, DLT), but lowcapacity | + | |
- | legacy tapes, diskettes, and optical media can equally well be used. | + | |
- | Electronic labels | + | '''Electronic labels''' |
- | Media are identified by a unique number. Tapes can be electronically labeled with | + | |
- | their media number to prevent live data being accidentally overwritten. | + | Media are identified by a unique number. Tapes can be electronically labeled with their media number to prevent live data being accidentally overwritten. |
- | Media tracking | + | |
- | You can use the media management module to track details of your media over their | + | |
- | whole life-cycle. For example, you can enter details of a new batch of tapes, display | + | '''Media tracking''' |
- | media contents, search through online indexes for backed-up files, and record when | + | |
+ | You can use the media management module to track details of your media over their whole life-cycle. For example, you can enter details of a new batch of tapes, display media contents, search through online indexes for backed-up files, and record when | ||
media are moved between locations. | media are moved between locations. | ||
- | Media can be stored in several locations, for example different tape libraries and offsite | + | |
- | storage areas. Jukeboxes and silos are also types of media location. | + | Media can be stored in several locations, for example different tape libraries and offsite storage areas. Jukeboxes and silos are also types of media location. |
- | Media usage | + | |
- | Backup tapes have a retention period which is defined in the backup job. Once the | + | |
- | expiry date has passed, the data is not deleted, but the tape becomes available again. | + | '''Media usage''' |
- | Unused and expired tapes are called scratch tapes, and the set of media available to | + | |
- | be used is called the scratch pool. | + | Backup tapes have a retention period which is defined in the backup job. Once the expiry date has passed, the data is not deleted, but the tape becomes available again. Unused and expired tapes are called scratch tapes, and the set of media available to be used is called the scratch pool. |
- | backup3G tries to balance media usage, by selecting the least-recently used scratch | + | |
- | volume. | + | Backup3G tries to balance media usage, by selecting the least-recently used scratch volume. |
- | 56 Information on Media | + | |
- | How backup3G Tapes are Structured | + | <br> |
- | Figure 10 shows the layout of a backup tape created by backup3G. The first file is a | + | === How backup3G Tapes are Structured === |
- | short (1 KB) file containing the electronic label. Subsequent files contain the backup | + | |
- | data, followed by an end-of-data marker. | + | Figure 10 shows the layout of a backup tape created by backup3G. The first file is a short (1 KB) file containing the electronic label. Subsequent files contain the backup data, followed by an end-of-data marker. |
- | Figure 10 — Sample layout of a backup3G tape | + | |
- | Media Set | + | |
- | A multi-volume backup is written to a set of media. A media set is identified by a ‘Set | + | {| border="1" cellpadding="6" cellspacing="0" |
- | ID’, which is the media number of the first volume in the set. Each volume also has | + | !File # !! Backup of !! Method/Format |
- | a ‘Sequence Number’, which shows its position in the set. | + | |- |
- | Example: a backup job writes to three tapes, whose media numbers are 2012, 2038 | + | |align="center"|2 || <tt>/ (root)</tt> || Full cpio |
- | and 2001. The media set is identified as follows: | + | |- |
- | Table 5 — Media set ID and sequence number | + | |align="center"|3 || <tt>/opt</tt> || Full cpio |
- | Media No. Set ID Sequence No. | + | |- |
- | 2012 2012 1 | + | |align="center"|4 || <tt>/var</tt> || Full cpio |
- | 2038 2012 2 | + | |- |
- | 2001 2012 3 | + | |align="center"|5 || <tt>$APPL_HOME/db</tt> || Full cpio |
- | File # Backup of Method/Format | + | |}[[Image:backup3G file backup tape.png|alt text]] |
- | 2 / (root) Full cpio | + | ::Figure 10 — Sample layout of a backup3G tape |
- | BOT | + | |
- | File 2 – data File 3 – data File 4 – data | + | <br> |
- | File 1 (label) | + | |
- | File 5 – data | + | === Media Set === |
- | 3 /opt Full cpio | + | |
- | 4 /var Full cpio | + | A multi-volume backup is written to a set of media. A media set is identified by a ‘Set ID’, which is the media number of the first volume in the set. Each volume also has a ‘Sequence Number’, which shows its position in the set. |
- | 5 $APPL_HOME/db Full cpio | + | |
- | marker | + | Example: a backup job writes to three tapes, whose media numbers are 2012, 2038 and 2001. The media set is identified as follows: |
- | End-of-data | + | |
- | Information on Media 57 | + | |
- | Scratch Media | + | {| border="1" cellpadding="6" cellspacing="0" |
- | Scratch media are tapes and disks that are available to be written by backup jobs. A | + | |+'''Table 5 — Media set ID and sequence number''' |
- | tape may be included in the scratch pool for two reasons. | + | !Media No. !! Set ID !! Sequence No. |
- | • It has a usage type of ‘scratch’ in the media database. | + | |- |
- | • The data it contains has passed its expiry date. | + | |align="center"|2012 || 2012 || align="center"|1 |
- | A volume is determined to be scratch according to information held about it in the | + | |- |
- | media database, not by any mark or record on the tape or diskette itself. Until they | + | |align="center"|2038 || 2012 || align="center"|2 |
- | are overwritten, scratch or expired tapes still contain the last files written to them. | + | |- |
- | A media set can also be manually scratched via the Maintain > Scratch | + | |align="center"|2001 || 2012 || align="center"|3 |
- | option in the Media module. When you do this, each volume in the set is marked as | + | |} |
- | ‘scratch’ and the link between them (the Set ID) is removed. Note that backup3G’s | + | |
- | record of the contents of that volume is also lost. If you might need to search for or | + | <br> |
- | recover files from old backups, it’s best to leave them as expired and not to mark | + | |
- | them as scratch. | + | === Scratch Media === |
- | A volume with a null expiry date never expires; this equates to a retention period of | + | |
- | ‘forever’. To reuse a volume like this you must manually mark it as ‘scratch’ as | + | Scratch media are tapes and disks that are available to be written by backup jobs. A tape may be included in the scratch pool for two reasons. |
- | described above. | + | *It has a usage type of ‘scratch’ in the media database. |
- | Caution Don’t try to force a volume to expire by editing its expiry date. This is not a safe | + | *The data it contains has passed its expiry date. |
- | method of scratching media, because the volume may be part of a media set containing | + | |
- | active data, and if there is an online index it will not be removed. | + | A volume is determined to be scratch according to information held about it in the media database, not by any mark or record on the tape or diskette itself. Until they are overwritten, scratch or expired tapes still contain the last files written to them. |
- | Media Balancing and Backup Cycling | + | |
- | Some sites use a few tapes to do all their regular backups. For example, each week | + | A media set can also be manually scratched via the Maintain > Scratch option in the Media module. When you do this, each volume in the set is marked as ‘scratch’ and the link between them (the Set ID) is removed. Note that backup3G’s record of the contents of that volume is also lost. If you might need to search for or recover files from old backups, it’s best to leave them as expired and not to mark them as scratch. |
- | they may cycle through a set of tapes physically labeled ‘Monday’, ‘Tuesday’ and so | + | |
- | on. The disadvantage of this scheme is that media containing vital backup data are | + | A volume with a null expiry date never expires; this equates to a retention period of ‘forever’. To reuse a volume like this you must manually mark it as ‘scratch’ as described above. |
- | used the most heavily and are subject to a higher risk of wear and damage. Exabyte | + | |
- | tapes, for instance, carry a manufacturers recommended maximum of 40 uses. | + | |
- | Instead, backup3G balances tape usage by prompting the operator to load from the | + | ---- |
- | scratch pool the tape with the earliest ‘date last written’. | + | ;Caution: Don’t try to force a volume to expire by editing its expiry date. This is not a safe method of scratching media, because the volume may be part of a media set containing active data, and if there is an online index it will not be removed. |
- | 58 Information on Media | + | ---- |
+ | |||
+ | <br> | ||
+ | |||
+ | === Media Balancing and Backup Cycling === | ||
+ | |||
+ | Some sites use a few tapes to do all their regular backups. For example, each week they may cycle through a set of tapes physically labeled ‘Monday’, ‘Tuesday’ and so on. The disadvantage of this scheme is that media containing vital backup data are | ||
+ | used the most heavily and are subject to a higher risk of wear and damage. Exabyte tapes, for instance, carry a manufacturers recommended maximum of 40 uses. | ||
+ | |||
+ | Instead, backup3G balances tape usage by prompting the operator to load from the scratch pool the tape with the earliest ‘date last written’. | ||
+ | |||
The scratch pool method has other advantages over tape cycling. | The scratch pool method has other advantages over tape cycling. | ||
- | • Designing your backup strategy is much simpler – you don’t have to worry | + | *Designing your backup strategy is much simpler – you don’t have to worry about allocating certain tapes to certain backups |
- | about allocating certain tapes to certain backups | + | *You can support any number of tapes in your library, whereas cycling forces you to use a set number of tapes |
- | • You can support any number of tapes in your library, whereas cycling forces | + | *You can use the same system for doing irregular or one-off archives as for scheduled backups |
- | you to use a set number of tapes | + | *Flexibility – it’s much easier to change your backup strategy after implementation. |
- | • You can use the same system for doing irregular or one-off archives as for | + | |
- | scheduled backups | + | However, should you wish to, you can still implement cycling of backup media within backup3G as follows. |
- | • Flexibility – it’s much easier to change your backup strategy after implementation. | + | #Define a special media type, with the same details as the media normally used for this backup job. Name it (for example) exabyte-dly |
- | However, should you wish to, you can still implement cycling of backup media | + | #Add enough media to complete exactly one cycle—e.g. for a twelve-month cycle add twelve tapes of type exabyte-yrly.<br>Label each tape electronically with the media number, and physically with a sticky label showing the media number and month—for example: |
- | within backup3G as follows. | + | #:501 January |
- | 1. Define a special media type, with the same details as the media normally | + | #:502 February |
- | used for this backup job. Name it (for example) exabyte-dly | + | #:503 March |
- | 2. Add enough media to complete exactly one cycle—e.g. for a twelve-month | + | #:… |
- | cycle add twelve tapes of type exabyte-yrly. | + | #In the backup job, select this media type. Choose a retention period so that each volume expires the day before it is due to be reused. |
- | Label each tape electronically with the media number, and physically with a | + | |
- | sticky label showing the media number and month—for example: | + | Each time the backup job runs, only one tape of the correct type will ever be available—the one from the same point in the previous cycle that has just expired. |
- | 3. In the backup job, select this media type. Choose a retention period so that | + | |
- | each volume expires the day before it is due to be reused. | + | <br> |
- | Each time the backup job runs, only one tape of the correct type will ever be available— | + | |
- | the one from the same point in the previous cycle that has just expired. | + | === Media Life Cycle === |
- | 501 January | + | |
- | 502 February | + | |
- | 503 March | + | |
- | … | + | |
- | Information on Media 59 | + | |
- | Media Life Cycle | + | |
A typical backup tape might go through the following stages. | A typical backup tape might go through the following stages. | ||
- | Recording media on the system | + | |
- | • A batch of 10 tapes is bought and registered to backup3G via the Media | + | |
- | > Maintain > Add batch option. The next ten available media numbers | + | '''Recording media on the system''' |
- | are assigned to these tapes and recorded in the media database. | + | |
- | • The tapes are electronically labeled with the media number, either when the | + | *A batch of 10 tapes is bought and registered to backup3G via the Media > Maintain > Add batch option. The next ten available media numbers are assigned to these tapes and recorded in the media database. |
- | batch is entered or at the time when each tape is used for the first time. | + | *The tapes are electronically labeled with the media number, either when the batch is entered or at the time when each tape is used for the first time. |
- | • The new tapes are marked in the database as scratch, that is, available to be | + | *The new tapes are marked in the database as scratch, that is, available to be used. tapes available for use make up the scratch pool. |
- | used. tapes available for use make up the scratch pool. | + | |
- | Using media for backup or archive | + | |
- | • When a backup job requests a tape, backup3G selects from the scratch pool | + | '''Using media for backup or archive''' |
- | a tape of the required type which has the oldest ‘date last written’, and | + | |
- | prompts the user to load it. | + | *When a backup job requests a tape, backup3G selects from the scratch pool a tape of the required type which has the oldest ‘date last written’, and prompts the user to load it. |
- | • When the backup job finishes successfully the usage type for each tape in | + | *When the backup job finishes successfully the usage type for each tape in the media set is changed to ‘backup’, and the ‘Description’ field is set to the backup job description. backup3G calculates an expiry date and stores it in the media table. The name of the base directory for each backup step is stored in the media contents table. |
- | the media set is changed to ‘backup’, and the ‘Description’ field is set to the | + | *The user is prompted to unload the tape, usually as part of a daily scheduled duty to acknowledge completion of all overnight jobs. |
- | backup job description. backup3G calculates an expiry date and stores it in | + | |
- | the media table. The name of the base directory for each backup step is | + | |
- | stored in the media contents table. | + | '''Tracking tape location''' |
- | • The user is prompted to unload the tape, usually as part of a daily scheduled | + | *If the backup job specifies that the tape is to be stored offsite, the user is automatically prompted to do so when acknowledging that the job has completed. If auto-acknowledge is set to ‘always’ or ‘on success’, successful jobs will be acknowledged, the tape will be unloaded and marked as stored offsite. |
- | duty to acknowledge completion of all overnight jobs. | + | *If the tape is moved some time after the job has completed, its new location can be recorded via the Move > Offsite option. |
- | Tracking tape location | + | |
- | • If the backup job specifies that the tape is to be stored offsite, the user is | + | |
- | automatically prompted to do so when acknowledging that the job has completed. | + | '''Recovery or expiry''' |
- | If auto-acknowledge is set to ‘always’ or ‘on success’, successful jobs will be | + | |
- | acknowledged, the tape will be unloaded and marked as stored offsite. | + | *The user may browse the media contents table and online indexes prior to recovering files from the backup. |
- | • If the tape is moved some time after the job has completed, its new location | + | *The tape becomes usable again when its expiry date passes, or when it is marked as scratch on the system. The data on the tape isn’t actually overwritten until the next time it is used. |
- | 60 Information on Media | + | *A record can be kept when maintenance procedures (such as tape cleaning or a low-level format) are carried out, either as part of a regular maintenance schedule, or after a fault is detected. |
- | can be recorded via the Move > Offsite option. | + | *Eventually the tape will fail or be ‘retired’, and its media number reused or removed from the media database. |
- | Recovery or expiry | + | |
- | • The user may browse the media contents table and online indexes prior to | + | <br> |
- | recovering files from the backup. | + | |
- | • The tape becomes usable again when its expiry date passes, or when it is | + | == Media Support Tables == |
- | marked as scratch on the system. The data on the tape isn’t actually overwritten | + | |
- | until the next time it is used. | + | The media database comprises the media table plus several support tables, which contain information about the way media are used at your site. These tables are updated whenever backup and recovery jobs run. You can customize the media support tables through backup3G configuration > Maintain tables. |
- | • A record can be kept when maintenance procedures (such as tape cleaning | + | |
- | or a low-level format) are carried out, either as part of a regular maintenance | + | |
- | schedule, or after a fault is detected. | + | '''Site/Media Location''' |
- | • Eventually the tape will fail or be ‘retired’, and its media number reused or | + | |
- | removed from the media database. | + | A media location is a place where media can be stored. There are several different types of location: |
- | Information on Media 61 | + | ;''onsite'': the main media library or tape vault |
- | Media Support Tables | + | ;''offsite'': another branch or office, or a long-term archive facility |
- | The media database comprises the media table plus several support tables, which | + | ;''load_device'': a silo or jukebox, from where tapes are loaded automatically into a drive |
- | contain information about the way media are used at your site. These tables are | + | ;''load_area'': a place where media are stored temporarily before being loaded manually into a drive—for example a trolley. |
- | updated whenever backup and recovery jobs run. You can customize the media support | + | |
- | tables through backup3G configuration > Maintain tables. | + | You should add to the location table any places where media may be kept, including temporary locations and auto-loading devices such as jukeboxes. Any location that will not be used for media storage should be defined as location type ‘other’. |
- | Site/Media Location | + | |
- | A media location is a place where media can be stored. There are several different | + | A tape stacker or trolley is in effect a temporary staging area from which tapes can be loaded. However a load device can also be a semi-permanent storage location, for example a jukebox containing up to several hundred tapes, where most tapes are just left in the unit. |
- | types of location: | + | |
- | onsite the main media library or tape vault | + | Tapes allocated to an auto-loading location are assigned slot numbers. If backup3G detects that a tape has been loaded in the wrong slot, it corrects the slot number in the media table. |
- | offsite another branch or office, or a long-term archive facility | + | |
- | load_device a silo or jukebox, from where tapes are loaded automatically into a | + | Backup3G has facilities to track media movements between locations, for example to register that archive tapes have been sent offsite, and to list which tapes are due to be returned onsite. Under the Media module, you can View media by location and Move selected media sets on- or off-site. |
- | drive | + | |
- | load_area a place where media are stored temporarily before being loaded | + | An offsite location is a place away from the main onsite location where media can be stored indefinitely, for example in a vault on another floor or in another building. |
- | manually into a drive—for example a trolley. | + | |
- | You should add to the location table any places where media may be kept, including | + | Offsite media must be returned onsite before they can be used in a backup or recovery job or allocated to a load device. |
- | temporary locations and auto-loading devices such as jukeboxes. Any location that | + | |
- | will not be used for media storage should be defined as location type ‘other’. | + | |
- | A tape stacker or trolley is in effect a temporary staging area from which tapes can | + | '''Usage type''' |
- | be loaded. However a load device can also be a semi-permanent storage location, | + | |
- | for example a jukebox containing up to several hundred tapes, where most tapes are | + | Describes what a volume is currently used for. For example, tapes containing backup data have type ‘backup’, and tapes containing archive data have type ‘archive’. Unused media are set to type ‘scratch’. |
- | just left in the unit. | + | |
- | Tapes allocated to an auto-loading location are assigned slot numbers. If backup3G | + | |
- | detects that a tape has been loaded in the wrong slot, it corrects the slot number in | + | '''Maintenance Procedures''' |
- | the media table. | + | |
- | backup3G has facilities to track media movements between locations, for example | + | You can keep a history of corrective or preventive maintenance done to media, such as tape cleaning and low-level formatting. You can add your own site’s procedures to the ‘Media Maint Procedure’ table. |
- | to register that archive tapes have been sent offsite, and to list which tapes are due to | + | |
- | be returned onsite. Under the Media module, you can View media by location and | + | |
- | Move selected media sets on- or off-site. | + | '''Media type''' |
- | An offsite location is a place away from the main onsite location where media can be | + | |
- | stored indefinitely, for example in a vault on another floor or in another building. | + | Each size and/or density of storage medium is stored as a unique media type. You can specify which media type a backup should request. For example, you could use the same drive to back up a large filesystem to a 5-gigabyte Exabyte tape, and smaller backups to 2-gigabyte tapes. You can add new formats to the ‘Media Type’ table. |
- | 62 Information on Media | + | |
- | Offsite media must be returned onsite before they can be used in a backup or recovery | + | The media type table also includes the part size and capacity, which are used when writing multi-part backups. |
- | job or allocated to a load device. | + | |
- | Usage type | + | |
- | Describes what a volume is currently used for. For example, tapes containing | + | '''Media label type''' |
- | backup data have type ‘backup’, and tapes containing archive data have type | + | |
- | ‘archive’. Unused media are set to type ‘scratch’. | + | Media should be electronically labeled with the media number. This helps to avoid volumes containing live data from being accidentally overwritten. Backup3G supports several label formats: |
- | Maintenance Procedures | + | |
- | You can keep a history of corrective or preventive maintenance done to media, such | + | {| border="1" cellpadding="8" cellspacing="0" |
- | as tape cleaning and low-level formatting. You can add your own site’s procedures to | + | |COSstdtape |
- | the ‘Media Maint Procedure’ table. | + | |writes a short file containing the media number and ‘date last written’ to the start of a tape, and an end-of-data marker after the last file on the tape. This is recommended for tapes that will be used for appending backups. |
- | Media type | + | |- |
- | Each size and/or density of storage medium is stored as a unique media type. You | + | |COSstdBOT |
- | can specify which media type a backup should request. For example, you could use | + | |writes the media number and ‘date last written’ to the start of a tape, but doesn’t write an end-of-data marker. |
- | the same drive to back up a large filesystem to a 5-gigabyte Exabyte tape, and | + | |- |
- | smaller backups to 2-gigabyte tapes. You can add new formats to the ‘Media Type’ | + | |end_label |
- | table. | + | |writes the label to the end of a diskette. This prevents the label being overwritten when a new backup is done. |
- | The media type table also includes the part size and capacity, which are used when | + | |- |
- | writing multi-part backups. | + | |sV_filesys |
- | Information on Media 63 | + | |System V filesystem labels |
- | Media label type | + | |} |
- | Media should be electronically labeled with the media number. This helps to avoid | + | |
- | volumes containing live data from being accidentally overwritten. backup3G supports | + | <br> |
- | several label formats: | + | === Media Table Locking === |
- | Media Table Locking | + | |
- | Processes that update media details (such as backup and recovery jobs, labelling a | + | Processes that update media details (such as backup and recovery jobs, labelling a volume, and adding a media batch) lock the media table briefly while the new details are written to the database. |
- | volume, and adding a media batch) lock the media table briefly while the new details | + | |
- | are written to the database. | + | If the media table is temporarily locked when a second process tries to update it, the lock will usually have been released by the time the second process tries again. Interactive users are prompted to press a button to try again; unattended processes such |
- | If the media table is temporarily locked when a second process tries to update it, the | + | |
- | lock will usually have been released by the time the second process tries again. Interactive | + | |
- | users are prompted to press a button to try again; unattended processes such | + | |
as backup jobs retry automatically. | as backup jobs retry automatically. | ||
- | If a process locks out a backup for an excessive length of time, backup3G will kill | + | |
- | that process rather than hold up a backup. For example, if a user has left open the | + | If a process locks out a backup for an excessive length of time, backup3G will kill that process rather than hold up a backup. For example, if a user has left open the ‘Change media details’ prompt form, backup3G will cancel the user’s process to release the lock and allow backups to continue. |
- | ‘Change media details’ prompt form, backup3G will cancel the user’s process to | + | |
- | release the lock and allow backups to continue. | + | |
- | COSstdtape writes a short file containing the media number and ‘date last written’ | + | |
- | to the start of a tape, and an end-of-data marker after the last | + | |
- | file on the tape. This is recommended for tapes that will be used | + | |
- | for appending backups. | + | |
- | COSstdBOT writes the media number and ‘date last written’ to the start of a | + | |
- | tape, but doesn’t write an end-of-data marker. | + | |
- | end_label writes the label to the end of a diskette. This prevents the label | + | |
- | being overwritten when a new backup is done. | + | |
- | sV_filesys System V filesystem labels | + |
Current revision
An essential element of the backup and recovery mechanism is effective media management. This section explains some media concepts and provides examples of good practice. Managing Removable Media on page 115 describes how to manage and use media through backup3G.
Backup3G’s facilities include:
- a comprehensive media database with support for any media type
- flexible retention periods and balancing of media usage
- tracking of media movement on- and offsite
- advanced search facilities
- media usage reports and volume labeling.
- Note
- References to tapes and tape drives in backup3G and in this manual generally apply to any type of removable media.
Contents |
Media Database
The media database is kept on your backup3G master host, and stores information about all your removable media – both used and unused – and the data they contain. The main components of the database are:
- media details
- information about all the media which can be used for backup and recovery—e.g. media type, usage, location
- media contents
- information about data stored on the media, such as online indexes and lists of base directories that have been backed up
- media support tables
- information that describes how media are used in your organization—e.g. media types, locations, label types.
Figure 9 — Media contents listing
The database is set up when you first configure the backup3G master host (see Add Media to the Media Library on page 148). These details are automatically updated as each backup is run and when you use the options in the Media Management module.
Media Management Concepts
Removable media are used in backup3G to store data for backups and other purposes. Typically, high-capacity tapes are used (e.g. SDLT, LTO, DLT), but low capacity legacy tapes (e.g. Exabyte, DAT), diskettes, and optical media can equally well be used.
Electronic labels
Media are identified by a unique number. Tapes can be electronically labeled with their media number to prevent live data being accidentally overwritten.
Media tracking
You can use the media management module to track details of your media over their whole life-cycle. For example, you can enter details of a new batch of tapes, display media contents, search through online indexes for backed-up files, and record when media are moved between locations.
Media can be stored in several locations, for example different tape libraries and offsite storage areas. Jukeboxes and silos are also types of media location.
Media usage
Backup tapes have a retention period which is defined in the backup job. Once the expiry date has passed, the data is not deleted, but the tape becomes available again. Unused and expired tapes are called scratch tapes, and the set of media available to be used is called the scratch pool.
Backup3G tries to balance media usage, by selecting the least-recently used scratch volume.
How backup3G Tapes are Structured
Figure 10 shows the layout of a backup tape created by backup3G. The first file is a short (1 KB) file containing the electronic label. Subsequent files contain the backup data, followed by an end-of-data marker.
File # | Backup of | Method/Format |
---|---|---|
2 | / (root) | Full cpio |
3 | /opt | Full cpio |
4 | /var | Full cpio |
5 | $APPL_HOME/db | Full cpio |
- Figure 10 — Sample layout of a backup3G tape
Media Set
A multi-volume backup is written to a set of media. A media set is identified by a ‘Set ID’, which is the media number of the first volume in the set. Each volume also has a ‘Sequence Number’, which shows its position in the set.
Example: a backup job writes to three tapes, whose media numbers are 2012, 2038 and 2001. The media set is identified as follows:
Media No. | Set ID | Sequence No. |
---|---|---|
2012 | 2012 | 1 |
2038 | 2012 | 2 |
2001 | 2012 | 3 |
Scratch Media
Scratch media are tapes and disks that are available to be written by backup jobs. A tape may be included in the scratch pool for two reasons.
- It has a usage type of ‘scratch’ in the media database.
- The data it contains has passed its expiry date.
A volume is determined to be scratch according to information held about it in the media database, not by any mark or record on the tape or diskette itself. Until they are overwritten, scratch or expired tapes still contain the last files written to them.
A media set can also be manually scratched via the Maintain > Scratch option in the Media module. When you do this, each volume in the set is marked as ‘scratch’ and the link between them (the Set ID) is removed. Note that backup3G’s record of the contents of that volume is also lost. If you might need to search for or recover files from old backups, it’s best to leave them as expired and not to mark them as scratch.
A volume with a null expiry date never expires; this equates to a retention period of ‘forever’. To reuse a volume like this you must manually mark it as ‘scratch’ as described above.
- Caution
- Don’t try to force a volume to expire by editing its expiry date. This is not a safe method of scratching media, because the volume may be part of a media set containing active data, and if there is an online index it will not be removed.
Media Balancing and Backup Cycling
Some sites use a few tapes to do all their regular backups. For example, each week they may cycle through a set of tapes physically labeled ‘Monday’, ‘Tuesday’ and so on. The disadvantage of this scheme is that media containing vital backup data are used the most heavily and are subject to a higher risk of wear and damage. Exabyte tapes, for instance, carry a manufacturers recommended maximum of 40 uses.
Instead, backup3G balances tape usage by prompting the operator to load from the scratch pool the tape with the earliest ‘date last written’.
The scratch pool method has other advantages over tape cycling.
- Designing your backup strategy is much simpler – you don’t have to worry about allocating certain tapes to certain backups
- You can support any number of tapes in your library, whereas cycling forces you to use a set number of tapes
- You can use the same system for doing irregular or one-off archives as for scheduled backups
- Flexibility – it’s much easier to change your backup strategy after implementation.
However, should you wish to, you can still implement cycling of backup media within backup3G as follows.
- Define a special media type, with the same details as the media normally used for this backup job. Name it (for example) exabyte-dly
- Add enough media to complete exactly one cycle—e.g. for a twelve-month cycle add twelve tapes of type exabyte-yrly.
Label each tape electronically with the media number, and physically with a sticky label showing the media number and month—for example:- 501 January
- 502 February
- 503 March
- …
- In the backup job, select this media type. Choose a retention period so that each volume expires the day before it is due to be reused.
Each time the backup job runs, only one tape of the correct type will ever be available—the one from the same point in the previous cycle that has just expired.
Media Life Cycle
A typical backup tape might go through the following stages.
Recording media on the system
- A batch of 10 tapes is bought and registered to backup3G via the Media > Maintain > Add batch option. The next ten available media numbers are assigned to these tapes and recorded in the media database.
- The tapes are electronically labeled with the media number, either when the batch is entered or at the time when each tape is used for the first time.
- The new tapes are marked in the database as scratch, that is, available to be used. tapes available for use make up the scratch pool.
Using media for backup or archive
- When a backup job requests a tape, backup3G selects from the scratch pool a tape of the required type which has the oldest ‘date last written’, and prompts the user to load it.
- When the backup job finishes successfully the usage type for each tape in the media set is changed to ‘backup’, and the ‘Description’ field is set to the backup job description. backup3G calculates an expiry date and stores it in the media table. The name of the base directory for each backup step is stored in the media contents table.
- The user is prompted to unload the tape, usually as part of a daily scheduled duty to acknowledge completion of all overnight jobs.
Tracking tape location
- If the backup job specifies that the tape is to be stored offsite, the user is automatically prompted to do so when acknowledging that the job has completed. If auto-acknowledge is set to ‘always’ or ‘on success’, successful jobs will be acknowledged, the tape will be unloaded and marked as stored offsite.
- If the tape is moved some time after the job has completed, its new location can be recorded via the Move > Offsite option.
Recovery or expiry
- The user may browse the media contents table and online indexes prior to recovering files from the backup.
- The tape becomes usable again when its expiry date passes, or when it is marked as scratch on the system. The data on the tape isn’t actually overwritten until the next time it is used.
- A record can be kept when maintenance procedures (such as tape cleaning or a low-level format) are carried out, either as part of a regular maintenance schedule, or after a fault is detected.
- Eventually the tape will fail or be ‘retired’, and its media number reused or removed from the media database.
Media Support Tables
The media database comprises the media table plus several support tables, which contain information about the way media are used at your site. These tables are updated whenever backup and recovery jobs run. You can customize the media support tables through backup3G configuration > Maintain tables.
Site/Media Location
A media location is a place where media can be stored. There are several different types of location:
- onsite
- the main media library or tape vault
- offsite
- another branch or office, or a long-term archive facility
- load_device
- a silo or jukebox, from where tapes are loaded automatically into a drive
- load_area
- a place where media are stored temporarily before being loaded manually into a drive—for example a trolley.
You should add to the location table any places where media may be kept, including temporary locations and auto-loading devices such as jukeboxes. Any location that will not be used for media storage should be defined as location type ‘other’.
A tape stacker or trolley is in effect a temporary staging area from which tapes can be loaded. However a load device can also be a semi-permanent storage location, for example a jukebox containing up to several hundred tapes, where most tapes are just left in the unit.
Tapes allocated to an auto-loading location are assigned slot numbers. If backup3G detects that a tape has been loaded in the wrong slot, it corrects the slot number in the media table.
Backup3G has facilities to track media movements between locations, for example to register that archive tapes have been sent offsite, and to list which tapes are due to be returned onsite. Under the Media module, you can View media by location and Move selected media sets on- or off-site.
An offsite location is a place away from the main onsite location where media can be stored indefinitely, for example in a vault on another floor or in another building.
Offsite media must be returned onsite before they can be used in a backup or recovery job or allocated to a load device.
Usage type
Describes what a volume is currently used for. For example, tapes containing backup data have type ‘backup’, and tapes containing archive data have type ‘archive’. Unused media are set to type ‘scratch’.
Maintenance Procedures
You can keep a history of corrective or preventive maintenance done to media, such as tape cleaning and low-level formatting. You can add your own site’s procedures to the ‘Media Maint Procedure’ table.
Media type
Each size and/or density of storage medium is stored as a unique media type. You can specify which media type a backup should request. For example, you could use the same drive to back up a large filesystem to a 5-gigabyte Exabyte tape, and smaller backups to 2-gigabyte tapes. You can add new formats to the ‘Media Type’ table.
The media type table also includes the part size and capacity, which are used when writing multi-part backups.
Media label type
Media should be electronically labeled with the media number. This helps to avoid volumes containing live data from being accidentally overwritten. Backup3G supports several label formats:
COSstdtape | writes a short file containing the media number and ‘date last written’ to the start of a tape, and an end-of-data marker after the last file on the tape. This is recommended for tapes that will be used for appending backups. |
COSstdBOT | writes the media number and ‘date last written’ to the start of a tape, but doesn’t write an end-of-data marker. |
end_label | writes the label to the end of a diskette. This prevents the label being overwritten when a new backup is done. |
sV_filesys | System V filesystem labels |
Media Table Locking
Processes that update media details (such as backup and recovery jobs, labelling a volume, and adding a media batch) lock the media table briefly while the new details are written to the database.
If the media table is temporarily locked when a second process tries to update it, the lock will usually have been released by the time the second process tries again. Interactive users are prompted to press a button to try again; unattended processes such as backup jobs retry automatically.
If a process locks out a backup for an excessive length of time, backup3G will kill that process rather than hold up a backup. For example, if a user has left open the ‘Change media details’ prompt form, backup3G will cancel the user’s process to release the lock and allow backups to continue.