Block Generation is an additional period of 10 days that is automatically added to the immutability expiration date. This period helps you alleviate removal of data and decrease frequent requests to object storage that may be required to preserve the lock of backup chains.
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.
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.
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.