Understanding chain-free backup

Axcient x360Recover

Written By Tami Sutcliffe (Super Administrator)

Updated at April 10th, 2023

Overview: What is "chain-free" backup?

Axcient x360Recover chain-free backup starts off the same way as traditional chain-based backups. You still do your first full backup, and you still do incremental backups -  but that’s where things change. 

x360Recover captures snapshots of a server every few minutes and replicates those images to the Axcient Cloud. Those snapshots include data, operating system, applications, and configurations.

With Axcient chain-free backup, data is stored in a native virtualizable state with a pointer array algorithm. 

With Axcient chain-free backup, each recovery point is independent:

  • Every backup is independent and equal
  • No rollups are required to consolidate snapshots
  • There are no chain dependencies between snapshots
  • Corrupted or bad snapshots can simply be deleted
  • Backup jobs are fast and efficient because there is never a danger of a corrupted backup interfering with any other recovery point
  • No time is wasted performing potentially dangerous rollups of old backup recovery points

Related article:


How does traditional chain-based backup work?

Each full backup image (and its subsequent incremental backups) constitutes a “chain” of dependent recovery points. 

  • During a chain-based recovery, all of the backups must be consolidated -  in the order in which they were created.
  •  Damaged data anywhere within the chain will cause all dependent recovery points to contain that corrupted data.
  • All chain-based backup strategies require individual recovery points be merged together in a “rollup” process. This is needed to limit the total backup data size and to establish limits for the total retention period. 

Processing the rollup of recovery points is inherently fragile and time consuming.  Any errors during this process can cause a broken chain.


How failures happen in chain-based backup

The following steps typically occur in failed traditional chain-based backups:

  1. Full backup is taken
  2. Incremental backup is taken
  3. Rollup of backups is performed. Snapshots are consolidated. Rollup fails: Broken chain occurs
  4. Incremental backup is taken with corrupted data
  5. All new backups  (though "successful") are corrupted, due to the broken chain
Delete

Backup vocabulary


Encryption:  Backup data should always be encrypted end-to-end during network transmission, whether limited to the local LAN, or replicated to an off-site location. Data should also be encrypted at rest, on whatever storage media will ultimately contain the backup. 


Compression: This reversible process delivers a set of data which can be processed into a new form, occupying a smaller amount of storage space than the original. All backup solutions offer some form of data compression when capturing backup images. This is necessary in order to maximize the capacity of the underlying backup storage system.


  • Deduplication is a specialized type of compression. The underlying storage system is designed to store unique blocks of data only once. Subsequent, duplicate copies of each data block are stored as a simple reference to the first instance. Deduplication can dramatically reduce the total storage size of backup data on disk. 
    • Operating system files are a good illustration of deduplication: many servers are running the same version of the software.
Delete

Types of chain-based backups


Full (base) backup is a complete copy. Everything on the system is captured. Full backups are large and take a long time to capture and process, making them ideal when recovering data, since all files exist within one backup image.


Synthetic full backup: Most modern backup solutions offer the ability to present a "synthetic full backup" when restoring files. This involves internally combining the most recent full backup along with all subsequent incremental backups, then presenting the compilation as if it was a single full backup for recovery purposes.


Copy backup captures a full backup, but does not mark the file archive bits. A copy backup may be taken after a full backup and will not interfere with the integrity of differential or incremental backup jobs


Differential backup contains everything that changed since the previous full backup was completed.  Each differential backup will contain everything that has changed, including files already stored within previously taken differential backups. Differential backups are a compromise between full and incremental: you only need the most recent full and the most recent differential together in order to recover your data. Each successive differential backup is larger than the previous backup, because it contains all of the data captured in each previous differential plus any new changes. Image-based backup solutions generally do not offer the option of performing differential backups.


Incremental backups contain only files that have changed since the last Incremental or full backup was completed. Incremental backups are small and allow for fast backup job processing. However, to fully reconstruct your data during recovery, the most recent full backup must be processed, in addition to every single incremental  taken afterwards.


Incremental forever backups occur when (a) a single full backup is initially taken and (b) all subsequent backup operations are performed as incremental backups. Individual incremental backup jobs may be collapsed, or “rolled up” into the previous backup in order to reduce retention and total number of recovery points.


Forward incremental backups use the first full backup and the set of incremental backup files which then follow.  The forward incremental backup includes any synthetic full and/or active full backup files that “split” the backup chain into shorter series.


Reverse (inverse) incremental backups occur when new Incremental backups are first committed to the base image, and a “rollback” file is then created defining the changes just made to the base image.  Reverse Incremental chains maintain the base image as the most recent backup, and produce a chain of progressively older Incremental recovery points. Reverse incremental backups are essentially similar to incremental backups, but can take longer to complete,  because the new backup data first needs to be committed to the backup set and then the rollback file must be created. 

Delete

Forward incremental-forever backups versus reverse incremental-forever backups


Steps in traditional forward-chain incremental-forever backups: 

1. First full backup is taken

2. Forward incremental backup is taken

3. Next forward incremental backup is taken

4. Rollup is performed and snapshots are consolidated. Rollup fails; Broken chain occurs

5. Forward incremental backup is taken

6. All new backups (though "successful") are corrupt due to the broken chain


What is happening with forward-chain incremental-forever backups?

  • The NEWEST backup is the latest incremental snapshot
  • The OLDEST backup is the original full snapshot
  • Backups appear to complete normally- even when broken chains exist
  • Backup points require consolidated data from all OLDER snapshots to be valid
  • Backups NEWER than any corrupt snapshot contain corrupted data
  • All OLDER backups cannot be rolled up and consolidated

Steps in traditional reverse-chain incremental-forever backups:

1. First full backup is taken

2. Reverse incremental backup is taken

4. Rollup of backups is performed and snapshots are consolidated. Rollup fails; Broken chain occurs

5. Reverse Incremental backup is taken

5. All backups OLDER than the broken chain contain corrupted data; Only the OLDER data is now corrupted- not the more recent backups.


What is happening with reverse-chain incremental-forever backups?


    The NEWEST backup is the full snapshot

    The OLDEST backup is the OLDEST Incremental snapshot

    New backups are unaffected by existing broken backup chains

    Backup points require consolidated data from all NEWER snapshots to be valid

    Backups OLDER than any corrupt snapshot contain corrupted data.

    All OLDER backups cannot be rolled up and consolidated

Delete

So, how is chain-free backup different?

With chain-free backups, each subsequent backup performs a copy-on-write (for changed data only) to a consolidated storage pool. 


Copy-on-write means that changed blocks are written to a new storage location and the original block data is not overwritten. Performing a new full backup only writes new / changed blocks to the image and does not consume the data of the entire full system (which is what chain-based backup systems do.)

  • Each chain-free snapshot consists of only the block allocation map detailing the file contents at this point in time.  
  • All unique block data referenced by any remaining snapshots is stored in a single chunk on disk, managed by the underlying ZFS filesystem.
  • Deleting a snapshot consists of simply discarding the block allocation map, freeing only the blocks that were uniquely used by the specified snapshot.  

Data is never moved once it is written, so there is never any possibility of corrupting the underlying image.

Delete



Pros and cons of chain-based backup

   Disadvantages of chain-based backup

   Advantages of chain-based backup
  • Each full image backup creates a large amount of data to be transported off-site 
  • Performing rollups is time consuming, with potentially corrupted, broken chain links
  • Chain-based backup data is only useable if it is touching the first backup
  • Sometimes backups appear normal -  even after a break in the chain.

  • Traditional chain-based backup can seem efficient because those subsequent incremental backups run fast.
  • If you routinely perform full image backups, you can improve the odds of having a good set of data to recover from, in the event of a disaster.

How do your choices in backup compare?

Traditional forward chains are fragile

Traditional chain backups are fragile. Over time,  it is almost certain that a broken chain will eventually cause the backup set to become corrupted. To resolve a broken recovery point in a traditional chain, you'll need a completely new backup chain.

Delete

Reverse (inverse) chains are a little better

Reverse (inverse) chain backups are a little better than traditional forward chain backups. Why? Because broken chains in a reverse backup only result in the loss of historical recovery points. The base image and recent backups are still accessible. 

Unfortunately, however, a broken chain in a reverse backup still means you cannot completely roll up all of your historical backups - and, of course, a new backup chain is still required to recover.

Delete

+Chain-free is best

Chain-free backups are your best choice, because corrupted recovery points have no effect on the quality and reliability of your backups. Plus, you'll only need to create a new backup chain if the entire original backup set is lost.  No time is wasted performing recovery point rollups.

Delete

Reminder: Review these backup best practices (no matter which method you choose)

  • Use incremental-forever whenever possible

By using an incremental-forever strategy, you eliminate the need to deliver large base images to your off-site data center on a regular basis. Also, creating backups with multiple base images is very data intensive.


  • Use a new base image

Always perform a new full (base) image whenever a protected system is recovered from backup. This ensures that the data image on the backup server matches the live protected system.


  • Test

Perform periodic recovery testing on all of your protected systems to ensure they are fully recoverable. This is especially true for chain-based solutions where it may not be obvious that you have a broken backup chain.


  • Frequent incremental backups are key to recovery
Take frequent incremental backups (i.e. every hour) to ensure you have the ability to provide a granular Recovery Time Objective (RTO).

Delete



Additional reading:

 


 SUPPORT      | 720-204-4500 | 800-352-0248

1272