Reasons why backing up or copying backup to disk data files is NOT recommended.
|Article:TECH176061|||||Created: 2011-12-02|||||Updated: 2012-03-13|||||Article URL http://www.symantec.com/docs/TECH176061|
When Backup Exec is configured to use Backup-to-Disk (B2D) Folders as storage devices, a number of *.BKF files and IMG* folders containing various files can be created. In various customer environments, and in questions to technical support, it is often seen that a process of directly backing up or copying the files and folders outside of Backup Exec has been implemented or is being considered, even though Symantec recommends against this type of manipulation of the B2D data files. This article discusses why that practice is not recommended.
Media Handling Components and Processes
To explain why it is not recommended, a basic outline of some of the components and processes relating to media handling is needed.
Backup Exec consists of 3 core storage components, as can be seen in the following diagram:
These 3 components form sections of a large relational database:
- The Media contains the actual data that was backed up
- The BEDB (Backup Exec Database) contains inventory information for every piece of media, each of which has a unique GUID-style identifier, media set assignments and current location details
- The Catalogs contain the details of every protected object (individual files, emails etc), where that object came from, which media it is stored in, and the location within the media.
If any one of these sections is missing or is inconsistent with the other sections, then a restore process can experience problems until the inconsistencies are resolved. There are tools to solve some inconsistencies: For example, if an Inventory is missing, then an Inventory utility job will recreate it; if the catalog is missing then a Catalog utility job will recreate it. Obviously, if the media is missing then a restore will not be possible. However, there are also some scenarios that will cause problems requiring more than just running a utility job to solve.
- Backup Job 1 runs and uses files BKF25, BKF26, and BKF27. Next, Backup Job 2 runs and uses files BKF28, BKF29, and BKF30. These BKF files form part of backup sets relating to the two jobs and each BKF file has its own given unique identifer (GUID) as well as a filename.
- These files are then copied to secondary storage using any 3rd party copy or replication tools.
- A month later, those media become available for overwrite (that is, their Overwrite Protection Period, or OPP, ends) and JOB3 uses files BKF25, BKF26, BKF27, and BKF28, followed by Job 4 that uses BKF29, BKF30 and BKF31. The overwrite operation of a BKF file, however, maintains the name of the file while creating a new identifer (because, in the background, a delete and create operation takes place). This results in the following:
Backup Exec status prior to needing to restore older data
- Now suppose a restore from job 2 is needed, so the older versions of BKF28, 29 and 30 are recovered, replacing the newer ones. The status now changes to the following:
Backup Exec status after copying back older B2D data (with inconsistent data highlighted in red)
This can cause the following problems:
- The backup sets for JOB3 and JOB4 are broken. This will require a copy of the newer BKF28, 29 and 30 files to be taken before recovering the older versions.
- The restore selections will still show the data for Jobs 3 and 4
- An attempt to run a catalog job to correct the restore selections errors out, because the media identifiers for the older file versions in the bkf folder don't match the inventory contents. This requires retiring and deleting the new versions of the media from the Backup Exec console, then running new Inventory and Catalog utility jobs to correct the situation. Manual removal of the newer catalog data (after copying it to a safe location) may be required, as well.
- Because the inventory and catalog have been reset (to provide JOB2 data) after the completion of the JOB2-data restore, the process will need to be repeated (in order to get back the information for JOB3 and JOB4).
Another common scenario occurs when two stand-alone Media Servers copy the B2D data between them, for Disaster Recovery (DR) purposes. This could potentially be a good idea, but is flawed if both servers actively run backup jobs: BKF files with conflicting names (but distinct given unqiue identifiers) may be created, resulting in issues similar to those in Scenario 1.
Incremental GRT backups to disk (particularly VMware / AVVI backups) create a sequence of IMG folders, which sequence goes back to the preceding full backup. Each incremental folder contains references to both the path of the IMG folder for the incremental and the path of the IMG folder for the full backup that started the sequence. A flat-file copy of either some or all of the IMG folders to different paths does not modify the references, and can cause issues when running new catalog jobs (directly affecting ability to restore).
- The above scenarios are just a few simple descriptions outlining potential problems; other scenarios may have related issues.
- The length of time and complexity of the restore in any such scenario is increased; as the media server gets busier and the media handling becomes more involved, more complicated scenarios affect restores to a greater extent, and therefore increase the restore times and administrative steps considerably.
- There are situations where it is required to start with an empty database, in order to inventory and catalog the recovered media. In such cases, one must also takes steps to protect the existing database, and then to recover it later.
- Backup jobs to tape, or to another disk device, directly from the file system containing the B2D location, experience the same problems during restore operations of the B2D data as those experienced when copying with file system tools.
- A tape does not experience problems, because it is not possible to copy a tape and maintain the same name or identifier. Tapes maintain their unique identifiers during overwrites, however if the same bar codes or tape names are used in different media servers, then moving media between the servers can result in a related condition.
- Duplicate jobs have the ability to restore directly to original locations. File system copies have a comparitively complicated recovery process just to get the backup files inventoried and cataloged, even without including the restore job itself.
- A complete move of the data should not cause issues, because the media is marked as offline (so won't be re-used). An inventory job may still be needed once they (the data) are returned to a live B2D folder.
- Avoid performing file system copies. Use Duplicate Jobs within Backup Exec to maintain multiple copies of Backup Sets, instead.
- If data must be replicated between media servers, consider DeDuplication with Optimized Duplication (possibly with a Private Cloud configuration).
- File system copies of B2D data is valid for complete Media Server DR, in situations where the recovery plan does not introduce inconsistencies, as the inventory and catalog data is also unavailable (or is a consistent copy) in DR situations.
- In planning for a complete Media Server DR, Symantec suggests copying the catalog folder, and a dumped copy of the BEDB, when copying the B2D data. This provides a consistent set of data for a DR operation, minimizes the need to run catalog jobs, and maintains the media set relationships.
- File system copies of B2D data are valid when migrating a Media Server to new hardware (where the new server has not yet run any backup jobs, so has no conflicting media names).
- If hardware is available, then a second media server can be maintained to help with restore jobs from older versions of media that have been copied using file system tools. This setup assumes that the BEDB on the second server contains no conflicting media at the start of the restore process. To maintain such a server, keeping a copy of an empty BEDB is recommended, so that after any restore it can be reset for future restores.
Article URL http://www.symantec.com/docs/TECH176061