Explanation of backup tags on Restore UI?
-
@CJ Gotcha, so they are all listed as Incremental because that is the type of job the backup has assigned to it, even if you have full backups periodically, they're still part of an Incremental backup job so will always be marked incremental. At least I'm 99% sure of this.
The key vs differencing is as follows:
-
Key backup is a full backup, this is the type of backup that is used for the future differencing ones. So any time a full backup is run on an Incremental job, it will be listed as a new key backup not as a "full" backup.
-
Differencing is a increment of an incremental backup, so you have a Key of say 60GB and the next one is an increment of that of like 500MB, you'd have 1 key and 1 differencing.
-
-
@planedrop If key is a full backup and differencing is a incremental backup, what's going on with the backups that have both attached to them? And the one backup that says 2 key?
-
@CJ I think there is still some misunderstanding.
A key backup is part of an incremental backup, it's the full of an an incremental.
When you setup an incremental backup there still has to be an initial full backup, then the increments start, this is called the Key backup.
So say you have a Incremental backup setup with a periodic full every 5 backups, you'd see something like this from start:
Key > Increment > Increment > Increment > Increment > New Key > Increment
Each key is a "full" backup but they are called Keys because they are part of the incremental chain so they aren't standalone.
-
@CJ said in Explanation of backup tags on Restore UI?:
@planedrop If key is a full backup and differencing is a incremental backup, what's going on with the backups that have both attached to them? And the one backup that says 2 key?
a full backup is a complete transfer of one file ( .xva ) for the VM
During incremental backup job , we transfer the VM metadata + 1 file per disk. When it's possible, and when the schedule don't force full (which should be renamed ) , we only transfer the changes since the last backup. In general, all the disks are transferred either as key or as incremental. A mixed transfer should only happens when there are invalid snapshots, or new disks
We're working on the clarification : https://xen-orchestra.com/blog/xen-orchestra-5-83/
@CJ it is strange to see such a mix of key/differencing. Did you manually delete some backups, or snapshots ?
-
@florent I have not deleted any backups or snapshots. I did do a snapshot rollback for one VM but I see the same mix for all of my VMs. I did recently enable memory inclusion for my snapshots which caused some problems because I did not have an SR defined for the memory on one of the hosts. Additionally, I have been getting the following error in my backup reports.
cleanVm: incorrect backup size in metadataI haven't had a chance to read the blog post yet, but I would love to see in the documentation an example of the proper way to do nightly incremental backups with a weekly full backup. That is what I have attempted to configure with my current setup but I still get both an incremental and full backup on the weekend. I don't want to set a Full Backup Interval of 7 because that seems like it would cause the full backup to change days if there was ever a problem.
-
@CJ that's it: the suspend disk ( memory) is always a full, I can fix it
cleanVm: incorrect backup size in metadatashould have been fixed since the last release, I will look at it againOn the schedule configuration: for now, you can't schedule a "every day except on sunday" easily
What I would do is 7 schedule (1 per day of week)
The differencing ( monday => saturday ) with a retention of 2 each , so you'll keep the backup at least a week worth of differencing, no full backup interval
The sunday backup will have "force full backup" and may have a longer retentionThe differencing/key backup chain is working for all the schedule of the same backup job
-
@florent I am on commit 74ff6. I see that there have been a bunch of new commits, so I'll update and check if that fixes the issue. When I did a search, the impression I got was that it was fixed and once the problem backups rotated out the error would go away.
Seven different schedules seems like a lot to manage. But you did make me realize that I can change my incremental backup to run every day but the day I have my force full backup scheduled. So I'll still need two schedules but now I won't have two backups on the same day.
-
@CJ yes that is simpler
-
@florent I updated to the latest commit yesterday but the backup still gives me the incorrect size error. Is there something else I should look at?
-
@CJ I didn't have time to check, but I am not forgetting it ( I think it may be related to the suspended disk )
-
@florent No rush. AFAICT it's not breaking anything.
-
@florent I'm not sure what's going on, but the incorrect size warning seems to be intermittent now.
Jan 22nd - No size warning. Half of the VMs cleaned 1 unused VHD, the others had 0.
Jan 23rd - Size warning and 1 unused VHD cleaned on half of the VMs. Others had neither.
Jan 24th - Same as Jan 23rd.
Jan 25th - Size warning and 2 unused VHD cleaned on half of the VMs. Others had 1 unused VHD cleaned.
Jan 26th - No size warning. All VMs cleaned 1 unused VHD.It doesn't seem host related as each host had VMs in both categories. Hope this helps. Let me know if you need any more info.
