Reasons why backing up or copying backup to disk data files is NOT recommended.

Reasons why backing up or copying backup to disk data files is NOT recommended.

Article: 100038808
Last Published: 2017-03-16
Ratings: 0 4
Product(s): Backup Exec


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 our recommendation is 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:

User-added image

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. For BE 2012 and newer versions, set retention and Simplified Disaster Recovery (SDR) information is also part of the catalog content

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.

Note: Backup Exec 2012 and later versions still use the same relationships between BEDB, Media Content and Catalogs, and as such may experience some of the scenarios provided below, however, due to disk backup retention processes changing to Data Lifecycle Management (DLM) and other changes, some of the scenarios may no longer be such a problem. Please see the "Comments for Backup Exec 2012 or newer versions" section of this article for details of the differences.

Scenario 1

  • 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 identifier (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 identifier (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

User-added image

  • 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).

User-added image
This can cause the following problems:

  1. 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.
  2. The restore selections will still show the data for Jobs 3 and 4
  3. 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.
  4. 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).

Scenario 2

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 unique identifiers) may be created, resulting in issues similar to those in Scenario 1.


Scenario 3

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 comparatively complicated recovery process just to get the backup files inventoried and cataloged, even without including the restore job itself.
  • A complete move of the disk based media 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 the media are returned to a live B2D folder.


Comments for Backup Exec 2012 or newer versions

  • Append within a BKF file is no longer allowed, each Backup Set now creates a new BKF file, which avoids extended media families and therefore reduces any likelihood of using an older piece of BKF media within a newer family using manual file copies.
  • As resources being backed up (C: D: System state etc) are classified as different Backup Sets even when in the same job, the media families are further reduced in size and complexity although there will be more overall media families in total.
  • Backup Exec no longer overwrites BKF media, instead a deletion (known as a reclaim) followed by creating a new piece of media, using the next available name in the overall sequence and not re-using the original name takes place. Note: with the exception of against Removable/RDX media the reclaim occurs based on DLM timings and not backup job operations as was seen in previous versions.
  • Because of the above points some of the scenarios may therefore not affect the newer versions of Backup Exec. However, care should still be taken if moving disk based media (Either BKF or IMG) between separate servers that run their own independent backup operations as there could still be naming conflicts causing inconsistencies between Catalog or Inventory content and media content.
  • Due to DLM retention timings being contained within the Catalog information, moving BKF and IMG folders to another media server may result in different expiration times and then reclaims can occur (Either earlier than expected so possible data loss, or later than expected so possible disk space issues)



  • 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, we suggest 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.
  • If using Backup Exec 2012 or newer, and moving disk based backup sets to another server, either take the catalog files across as well, or be prepared to manually adjust expiration times against the backup sets once catalog jobs have been run in the new location. Which ever method is used check the expiration of the sets carefully after the move.

Was this content helpful?