Veeam Backup & Replication 10
User Guide for Microsoft Hyper-V
Related documents

Block Generation

Block Generation is an additional period of 10 days that is automatically added to the immutability expiration date. This period is designed to reduce the number of the requests to the object storage in cases when the immutability period of some blocks must be extended: for instance, when the blocks are being reused.

Generations may grow, which happens after you offload data starting from the 11th day and up until the end of the immutability period, thereby creating new consecutive generations the period of which is also 10 days.

Forward Incremental Backup Chain

The following figure shows an example consisting of three generations; each generation has immutable blocks of data, two of which have been reused during copy.

Understanding Immutability

As per example:

  • [Generation 1] On 01/01/2020, a Full Backup 1 consisting of blocks A, B, C and D has been offloaded to object storage. On 01/04/2020, the Full Backup 1 was succeeded by an Incremental Backup 1 consisting of blocks E and F.

After both files have been offloaded, a backup (or backup copy) job went idle for the next 7 days.

In such a scenario, blocks of these files (i.e. A, B, C, D, E and F) become part of the Generation 1.

  • [Generation 2] On 01/11/2020 (11th day), a Full Backup 2 consisting of blocks A, B, G and H has been offloaded to object storage. On 01/12/2020, the Full Backup 2 was succeeded by an Incremental Backup 2 consisting of blocks I and J.

Because all of these blocks (i.e. G, H, I and J) have been offloaded no sooner than on the 11th day, these blocks become part of the Generation 2.

Blocks A and B of the Full Backup 2, however, have not been actually offloaded. Instead, these blocks have been taken from the Full Backup 1 and, therefore, have been reused.

Such a scenario means that the Generation 1 now has blocks C, D, E and F only (i.e., excluding reused blocks A and B), all of which become mutable on 02/09/2020.

After the Incremental Backup 2 has been offloaded on 01/12/2020, the backup (or backup copy) job went idle for the next 10 days.

  • [Generation 3] On 01/22/2020 (11th day), an Incremental Backup 3 consisting of blocks K and B has been offloaded to object storage. Blocks of this file become part of the Generation 3 and block B has been reused from the Full Backup 2.

Since all of the blocks that have been offloaded starting from 01/11/2020 (G, H, I, J and K) are of the same backup chain, these blocks now belong to the Generation 3 altogether and can only become mutable on 03/02/2020.

For instance, if the Incremental Backup 3 had not been offloaded on 01/20/2020, the immutability expiration window of blocks A, B, G, H, I and J would have been met on 02/21/2020, which is the date when the Full Backup 2 was offloaded plus 40 days.

According to this example, Veeam Backup & Replication continues to keep reused/dependent blocks of data locked by continuously assigning them to new generations, thereby extending the immutability expiration period.

Reverse Incremental Backup Chain

The following figure shows an example of a reverse incremental backup chain where:

  • Immutability period is set to 30 days.
  • Generation period is 10 days.
  • Total immutability period is 40 days.

As per example, blocks A, B, E and F (see Figure A) belong to the Generation 1 and stay immutable until 02/10/2020 (the date when Full Backup 1 has been offloaded plus 40 days). Then, on 01/04/2020 new blocks (C and D) have been offloaded (see Figure B) replacing older blocks (E and F in Full Backup 1). Blocks E and F now become part of the Reverse incremental Backup 1.

In such a scenario, blocks A, B, C, D, E and F belong to the Generation 1 and become mutable on 02/10/2020, which is the date when blocks C and D have been offloaded.

Understanding Immutability

In the Figure C, another Full Backup 2 has been offloaded on the 11th day and consists of blocks A, B, G and H. Blocks A and B have been reused from the Full Backup 1, whereas blocks G and H have actually been offloaded to object storage.

In such a scenario, blocks A, B, G and H of the Full Backup 2 belong to the Generation 2 and become mutable on 02/20/2020, which is the date when blocks G and H have been offloaded.

Understanding Immutability

Related Topics

This Document Help Center
User Guide for VMware vSphereUser Guide for Microsoft Hyper-VVeeam Backup Enterprise Manager GuideVeeam Agent Management GuideVeeam Cloud Connect GuideVeeam Explorers User GuideVeeam Plug-ins for Enterprise Applications GuideVeeam PowerShell ReferenceVeeam Explorers PowerShell ReferenceVeeam RESTful API ReferenceRequired Permissions for VMware vSphereQuick Start Guide for VMware vSphereQuick Start Guide for Microsoft Hyper-VVeeam ONE DocumentationVeeam Agent for Windows DocumentationVeeam Agent for Linux DocumentationVeeam Backup for AWS DocumentationVeeam Backup for Microsoft Azure DocumentationVeeam Backup for Nutanix AHV User GuideVeeam Backup for Microsoft Office 365 DocumentationVeeam Management Pack Documentation
I want to report a typo

There is a misspelling right here:

 

I want to let the Veeam Documentation Team know about that.