Clarification: Do incremental backups (either incremental image backups or incremental file backups) form a dependence chain with past incremental backups like in traditional incremental backups?

general discussion
1

Hello,

I read this: Wording: incremental vs. differential - #2 by uroni

So, just a little bit of clarification. Does this imply that UrBackup works like duplicacy in that incremental backups (both incremental image backups and incremental file backups) do not form a dependence chain with earlier incremental backups i.e. does it kind of work like duplicacy in that there is a central repository of chunks and every backup snapshot references different chunks in said repository in such a way that each snapshot is kinda like it’s own independent backup, and, if no more references to let’s say chunk X are to be found in any snapshot, then chunk X gets deleted?

Does this mean that in below:

Day 1: Full Image Backup
Day 2: Incremental Image Backup
Day 3: Incremental Image Backup
Day 4: Incremental Image Backup

If I delete Day 3, I can still restore from Day 4?

2

For file backups, yes (though whole files instead of chunks). For image backups it depends:

  • Incremental vs differential: Is now a setting in advanced (incremental to last full/last backup)
  • On certain file systems it can do cow-raw backups: And then any backup can be deleted (btrfs, XFS, ZFS, ReFS)
1 Like
3

Thanks for the quick reply uroni.

I read something in the UrBackup administration manual about this.

So, in General->Advanced settings of the UrBackup server, I can specify whether Local incremental image style should be based on the last full image backup or the last image backup. Do I understand it right that choosing the former will mean differential backups and choosing the latter will mean incremental backups?

Additionally, if I choose the former, I can then delete any backup on any day without breaking any sort of dependence chain because they are all just differential backups off of the same full backup, right? On the other hand, if I choose the latter, there will be a dependence chain between the current backup and the past backups, right? So in that case if I delete one incremental backup done on, let’s say, day 3 then backups on day 4 onwards will be unusable, right?

On certain file systems it can do cow-raw backups: And then any backup can be deleted (btrfs, XFS, ZFS, ReFS)

That is good to know.

4

You are correct. based on last full image backup means you’ll create differential backups. Based on last image backup means you’ll be making a incremental image backup chain.

You can also check this out on the Urbackup server webinterface. If you try to delete a non-full image backup , it should mark several other non-full image backups to be deleted as well if you’re trying to delete a incremental backup in the middle of the chain. (then the other backups in the chain will get marked for deletion as well).

1 Like
5

What happens in the case that the maximum number of incremental image backups is reached? Assuming incremental image backups are based on the previous incremental, not full.

Say the max is set to 3. On day 5 of the example in the OP, is the backup from day 4 replaced with a newer incremental based on day 3? Or is day 2 deleted so an incremental can be made based on day 4?

6

I have set “Local/passive incremental image style:” to “Based on last full image backup” in urbackup’s settings and use btrfs for storing backups.
So from @uroni’s comment above, I’d assume cow-raw backups should be used.
But when I check in the filesystem it looks like nothing is shared (only really very small part should change between days, for sure not 400 GB):

# backups/MyClient$  btrfs fi du 2212??-????_Image_C/*.vhd
     Total   Exclusive  Set shared  Filename
 397.47GiB   397.47GiB       0.00B  221201-0208_Image_C/Image_C_221201-0208.vhd
 397.40GiB   397.40GiB       0.00B  221202-0212_Image_C/Image_C_221202-0212.vhd
 397.90GiB   397.90GiB       0.00B  221203-0216_Image_C/Image_C_221203-0216.vhd
 397.59GiB   397.59GiB       0.00B  221204-0217_Image_C/Image_C_221204-0217.vhd
 398.47GiB   398.47GiB       0.00B  221205-0221_Image_C/Image_C_221205-0221.vhd
 398.01GiB   398.01GiB       0.00B  221206-0224_Image_C/Image_C_221206-0224.vhd
 398.44GiB   398.44GiB     8.00KiB  221207-0226_Image_C/Image_C_221207-0226.vhd
 399.69GiB   399.69GiB       0.00B  221208-0227_Image_C/Image_C_221208-0227.vhd
 402.64GiB   402.64GiB       0.00B  221209-0232_Image_C/Image_C_221209-0232.vhd
 404.81GiB   404.81GiB       0.00B  221210-0234_Image_C/Image_C_221210-0234.vhd
 404.82GiB   404.82GiB       0.00B  221211-0238_Image_C/Image_C_221211-0238.vhd
 404.04GiB   404.04GiB       0.00B  221212-0242_Image_C/Image_C_221212-0242.vhd
 404.55GiB   404.55GiB       0.00B  221213-0244_Image_C/Image_C_221213-0244.vhd
 404.47GiB   404.47GiB       0.00B  221214-0249_Image_C/Image_C_221214-0249.vhd
 407.27GiB   407.27GiB       0.00B  221215-0251_Image_C/Image_C_221215-0251.vhd
 407.41GiB   407.41GiB       0.00B  221216-0255_Image_C/Image_C_221216-0255.vhd
 408.63GiB   408.63GiB       0.00B  221217-0258_Image_C/Image_C_221217-0258.vhd
 408.29GiB   408.29GiB       0.00B  221218-0301_Image_C/Image_C_221218-0301.vhd
 408.81GiB   408.81GiB       0.00B  221219-0305_Image_C/Image_C_221219-0305.vhd

Why is there nothing shared between the backups?