Article ID: kb00083Last Modified: 09-Oct-2026

Block-Level Backup Explained (legacy backup format)

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

In this article, we discuss the 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 a 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 the retention policy, you need to schedule a full backup in addition to the regular block-level backup. It can be specified on the Full Backup Options step of the wizard:

CloudBerry backup agent purges versions based on

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

Once a backup plan completes, the agent checks the retention policy and purges affected versions, if any.

Below, we illustrate 14 rounds of a 3-version 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, the first (oldest) version equals the 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 the regular full backup, which still has to be scheduled. When a synthetic full backup is initiated, the backup agent compares data on the storage with data on the machine and only uploads the changes. A new full dataset is then automatically created in the cloud. 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 the amount of data moved to storage each day. However, it is still required to schedule full backups to trigger the 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
Production