Article ID: kb00083Last Modified: 22-Aug-2024

Block-Level Backup Explained (legacy backup format)

Block-level backup is a backup type that uploads only modified file parts against of incremental or full backups that upload whole files. Block-level backup occupies less bandwidth and reduces backup duration.

In this article, we discuss main differences between full and block-level backups. We also cover best practices and everything else you should take into account when scheduling a block-level backup plan.

Scheduling a Block-Level Backup Plan

To enable block-level backup, run the backup wizard and select the Use block-level backup checkbox at the Advanced Options step.

When you first run backup plan with block-level backup enabled, a full copy of each file will be uploaded to storage. Next time you run the plan, new files and only modified parts of previously uploaded files are going to be backed up.

Retention, Full and Block-Level Backup

To enable retention policy, it is required to schedule full backup in addition to regular block-level backup. And it can be specified at the Full Backup Options step of the wizard:

CloudBerry backup agent purges versions based on

  • Age – purges version in X days/weeks/months/years after backup
  • Number – purges the oldest version once X+1 versions are backed up

Once every backup plan completes, agent confirms retention policy and purges versions if any affected

Below we illustrate 14 rounds of 3 versions retention policy applied to an image-based backup plan of the following schedule:

  • Block-Level (regular) schedule: weekly, every M, Tu, Wd, Fr
  • Full-Backup schedule: weekly, every Th

INTRODUCTION: Each completed backup run (regardless of type) is always available for further restore – represents a restore point. However, not every backup run represents a version of retention policy. With block level backup enabled, first (oldest) version equals to a backup chain of the first (oldest) full, plus all further blocks backed up before the next (second) full which represents the second version. Uploaded afterwards block-level backup represents the third. Moreover, the golden rule of the first-in-first-out CloudBerry retention policy is that the (oldest) version is always being purged right after one additional version (X+1) is successfully backed up.

Day 1 - First Monday: First Full (F1)

  • Backup storage: (F)
  • Number of retention policy versions retained: 1
  • Number of restore points available: 1

  • No purge performed afterwards

Day 2 - First Tuesday: First Block-Level after First Full (F1B1)

  • Backup storage: (F) + (B)
  • Number of retention policy versions retained: 1
  • Number of restore points available: 2

  • No purge performed afterwards

Day 3 - First Wednesday: Second Block-Level after First Full (F1B2)

  • Backup storage: (F) + 2(B)
  • Number of retention policy versions retained: 1
  • Number of restore points available: 3

  • No purge performed afterwards

Day 4 - First Thursday: Second Full (F2)

  • Backup storage: (F) + 2(B) + (F)
  • Number of retention policy versions retained: 2
  • Number of restore points available: 4

  • No purge performed afterwards

Day 5 - First Friday: First Block-Level after Second Full (F2B1)

  • Backup storage: (F) + 2(B) + (F) + (B)
  • Number of retention policy versions retained: 3
  • Number of restore points available: 5

  • No purge performed afterwards

Day 6 - Second Monday: Second Block-Level after Second Full (F2B2)

  • Backup storage: (F) + 2(B) + (F) + 2(B)
  • Number of retention policy versions retained: 4
  • Number of restore points available: 6

  • The one oldest version is being purged afterwards
  • Backup storage: (F) + 2(B)
  • Number of retention policy versions retained: 1
  • Number of restore points available: 3

Day 7 - Second Tuesday: Third Block-Level after Second Full (F2B3)

  • Backup storage: (F) + 3(B)
  • Number of retention policy versions retained: 1
  • Number of restore points available: 4

  • No purge performed afterwards

Day 8 - Second Wednesday: Fourth Block-Level after Second Full (F2B3)

  • Backup storage: (F) + 4(B)
  • Number of retention policy versions retained: 1
  • Number of restore points available: 5

  • No purge performed afterwards

Day 9 - Second Thursday: Third Full (F3)

  • Backup storage: (F) + 4(B) + (F)
  • Number of retention policy versions retained: 2
  • Number of restore points available: 6

  • No purge performed afterwards

Day 10 - Second Friday: First Block-Level after Third Full (F3B1)

  • Backup storage: (F) + 4(B) + (F) + (B)
  • Number of retention policy versions retained: 3
  • Number of restore points available: 7

  • No purge performed afterwards

Day 11 - Third Monday: Second Block-Level after Third Full (F3B2)

  • Backup storage: (F) + 4(B) + (F) + (B) + (B)
  • Number of retention policy versions retained: 4
  • Number of restore points available: 8

  • The one oldest version is being purged afterwards
  • Backup storage: (F) + 2(B)
  • Number of retention policy versions retained: 1
  • Number of restore points available: 3

Day 12 - Third Tuesday: Third Block-Level after Third Full (F3B3)

  • Backup storage: (F) + 3(B)
  • Number of retention policy versions retained: 1
  • Number of restore points available: 4

  • No purge performed afterwards

Day 13 - Third Wednesday: Fourth Block-Level after Third Full (F3B4)

  • Backup storage: (F) + 4(B)
  • Number of retention policy versions retained: 1
  • Number of restore points available: 5
  • No purge performed afterwards

Day 14 - Third Thursday: Fourth Full (F4)

  • Backup storage: (F) + 4(B) + (F)
  • Number of retention policy versions retained: 2
  • Number of restore points available: 6
  • No purge performed afterwards

Synthetic Full Backup (legacy)

Available with certain cloud storages and CloudBerry image-based backup, Synthetic Full is a great feature that substitutes regular full backups scheduled along with block-level backups.

If enabled, Synthetic Full Backup replaces regular full, which still has to be scheduled. When synthetic full is initiated, a backup agent compares data on the storage with data on machine, and only uploads the changes. A new full dataset is going to be automatically created in a cloud afterwards. In other words, synthetic full backup just replaces full upload with incremental. NOTE: Please contact us to learn about cloud storage providers supporting Synthetic Full Backup type.

Conclusion

Block-level backup is a perfect solution for everyday backup as it can significantly reduce amounts of data that is moved to a storage each day. However, it is still required to schedule full backups to trigger retention policy which clears storage space from unnecessary old versions. In addition, it is highly recommended to take advantage of Synthetic Full backup if possible.

Contact Us

https://git.cloudberrylab.com/egor.m/doc-help-kb.git