64744: Acronis Cyber Protect Cloud: 'version 12' backup format (archive3)

use Google Translate

Last update: Thu, 2020-07-09 12:57

'Version 12' backup format (archive3) is the main archive type for Acronis Cyber Protect Cloud and Acronis Backup 12.5. It is used to back up any data, including mobile data, applications, application-aware, Mac OS, Oracle DB, Office365 mailboxes, etc.

Design of 'version 12' backup format

An archive of 'version 12' format can use one of these schemes:

  • Always incremental
    Available for both cloud (all protected data types) and local (entire machine and disk-level backups) backup destinations.
    The initial full and subsequent incremental backups are saved to a single .tibx file instead of a chain of files.
  • Multi-full
    Available for both cloud and local backup destinations (all protected data types).
    Chains of a full backup and subsequent differential and incremental backups are saved to a single .tibx file each (local backups; see more details in Archive structure of multi-full backup) and to a single .tibx file (cloud backups).

An archive of 'version 12' format has two modes: append-only and re-write:

  • Append-only mode means the new data will always be added to the end of the file. Thus, logical size of the file always grows. Append-only mode is used when backing up to Cloud or to tapes.
  • Re-write mode is used in all other cases. In re-write mode archive3 automatically uses unused blocks to write data to them.


Limitations of 'version 12' backup format


  • No conversion from legacy to new archive format.
  • Impossible to export backup from old archive format to archive3 and vice versa
  • Recovery option "recover mount points' targets" is not supported
  • Backup option “backup splitting” is not supported for ASN and Cloud destinations:
    • During backup to FAT32 and ASZ backup will be automatically split by 4GB
    • Full and differential chains will be put in separate files automatically
  • Archive shrink is not supported - archive logical size cannot be shrunk without exporting backups
    • Blocks marked as deleted will be reused
    • Blocks marked as deleted will be sparsed if file system supports sparses
  • No user interactions for non-tape locations (e.g. disk is full)
  • No user interactions for destination during file recovery (e.g. file is locked on the destination or destination is full)

Acronis Bootable Media:

  • File backup will be in old formats (non-archive 3)
  • On Linux media, cannot perform recovery from file backups to NTFS volume


  • Archive3 cannot be backed up or replicated to vault with deduplication

Archive size in 'version 12' backup format

The size greatly depends on the type of data and the amount of unique data being backed up. The more duplicate data is present, the better compression will be achieved (due to in-built Archive3 deduplication mechanism). Also, compression of different data type may strongly vary. Thus, even rough calculations of archive’s size before backup are impossible.

To better understand this section, find out what a sparse file is.

An archive of 'version 12' format consists of:

  • protected data:
    • data (actual protected data at a certain point in time)
    • unused space (is "free" but has not yet been sparsed; is currently included into space used by protected data but will be reused for next backups)
    • de-allocated (sparsed data)
  • metadata (service information about archive structure)

In always incremental archives

Whenever a backup (a.k.a recovery point or slice) is deleted, all data that was accessible only through this recovery point is marked as “unused”. Sparse operation is initiated when the archive is not opened for reading/browsing by some other Cyber Protection agent at the time of the check AND any of the following cases occur:

  • "unused" size is more than 1 Gb
  • "unused" size is more that 5% of the archive's physical (on disk) size:  "data" + "unused" + "metadata"

After sparse all "unused" space is “punched”. Therefore, empty blocks fragments are created. As a result, the physical size of the archive file is reduced, and free space on the storage increases.

In multi-full archives

Methods to free up space at target destination:

  • Using sparse mechanism
  • Deleting old chains while writing in multi-full mode

As soon as a new backup chain is started, the previous one becomes immutable, which means that data can be read from it, but cannot be modified (no sparse, no data re-write etc.). Therefore, deletion of a single backup slice from old chain does not free space.

Even deletion of the entire backup chain including the full backup does not result in freeing some space if the full backup has dependencies. For example, Chain 2 and Chain 3 depend from full backup from Chain 1, therefore if we delete Chain 1, space won’t get free until we also remove Chain 2 and Chain 3.

How to decrease archive size of 'version 12' format

Decrease cloud archive size

The size of deleted data should be >= 5% of the archive’s physical size (size on disk).
To better predict the outcome of this method, see how retention rules work for a cloud archive:
  1. Delete recovery point(s) that contain unique data (files/ folders that are not present under other recovery points).
  2. Delete some backup source(s) from the backup plan’s “Items to back up” section:
    • For disk backup: uncheck one of the disks
    • For file backup: uncheck some files/folders

    Once done, wait until longest retention period passes.

Decrease local archive size

The size of deleted data should be >= 5% of the archives’ physical size (size on disk).

Method 1
For the last chain in the archive only: if slices D7, I8 or I9 contain any unique (not present under other slices) data, deletion of D7, I8 or I9 will free some space.

Method 2
Delete all chains starting from full backup and including all differentials after it, but leaving next full backup: if slices F1- I9 (all of them) are deleted, all the space previously occupied by them will be freed*.
Note: removal of slices  F1 - I3  only will not free space (until dependent slices D4 – I9 are also deleted).

Method 3
Delete the whole chain that does not have dependencies (the latest one, or the one starting from differential backup).
Example #1:  if slices D4–I6 or   D7–I9 (exactly all 3 of them) all disk space occupied by them will be freed.

Method 4
Delete the whole chain that does not have dependencies (the latest one, or the one starting from differential backup).
Example #2:  if slices F7–I9 or   F10–I12 (exactly all 3 of them) all disk space occupied by them will be freed (since they do not have dependent differential chains.