I wanted to remove some of incremental backups because space is limited and I have many getting backed up throughout the month. I later learned that removing either one of incrementals or base backup would break the chain and I will not be able to restore when required. However here's the reply to question I found by staff:
If I was to backup ONLY the VBK and VBM file to tape, would this be enough to recover the VM in the event of a disaster? Is it necessary to have the VRB files as well?
No, .vbk file will be enough for recovering VM from it, should any disaster happen.
So I can still remove incrementals and restoration will work, provided base backup is not removed of course?
It would be good to have backup policy option for based on a desired quantity of backups rather than time period. Is this option planned for release?
TechnicGeek wrote:So I can still remove incrementals and restoration will work, provided base backup is not removed of course?
Restoration will work, but from 1 restore point only(the day when the .vbk was created). If you want to restore from time when incremental backups were created - don`t delete them.
TechnicGeek wrote:It would be good to have backup policy option for based on a desired quantity of backups rather than time period. Is this option planned for release?
Shestakov wrote:Restoration will work, but from 1 restore point only(the day when the .vbk was created). If you want to restore from time when incremental backups were created - don`t delete them.
Does deleting only the latest incremental still break the chain? If I backed up last week and decided that there were no new changes or changes worthy of backing up since last incremental, can I delete last incremental and still expect all previous incrementals to work when restoring?
Yes, if you delete the last backup, older once will work, but you may have problems with next backups since the information about the file you are going to delete will remain in database and the next job run will create Full backup.
By the way, why do you want to delete the increment?
Shestakov wrote:Yes, if you delete the last backup, older once will work, but you may have problems with next backups since the information about the file you are going to delete will remain in database and the next job run will create Full backup.
By the way, why do you want to delete the increment?
I mentioned that in previous question. I want flexibility in managing backups due to external hard drive space limitation that I use to backup data. For risk management I also do backups with other software.
With retention of incrementals, is incremental deleted only when new incremental is about to be created or as long as Veeam runs in the background and detects external hard drive plugged in?
Merge of the incremental restore point into full backup is performed at the end of backup job. Kindly, take a look at Backup Retention Policy Help Center article for more details.
Shestakov wrote:Yes, the oldest restore point will be deleted only when new one is created with no errors. So in fact you need space for an additional increment.
I have backups backdating to the middle of May and they are not being deleted, despite 14-day retention policy:
If the number of restore points on disk is less than job’s retention restore points won’t be merged into full backup. To make sure we are on the same page regarding retention logic, kindly, take a loot at this Help Center article.
My bad - I copied your name from account details but did not realize you specified only your location. Sorry about that.
I am curious what your use case is for calendar days over successful backups? For me I would rather know how many backups I have rather than what day the job was run. Number of backups retention policy, I believe that is a different way of saying what VEB already does. It counts the number of successful backups against the retention policy to know when to start removing old ones.
Dima P. wrote:Correct. VEB takes into account not calendar days but days on which backup files were successfully created.
This terminology in use by Veeam, is not among the best or luckiest choises. I also had to think twice and do some googling before i understood what they reaaly ment...
Would be better to use the same terminology, that we are used to in VBR...
Dima P. wrote:If the number of restore points on disk is less than job’s retention restore points won’t be merged into full backup. To make sure we are on the same page regarding retention logic, kindly, take a loot at this Help Center article.
It didn't remove in my case later as I found. I had 1 original + 14 incrementals and even changed number of days of backup policy from 14 to 8. Don't know if making this change is applicable in the process but it didn't make the difference.
I was expecting main backup integrate obsolete backups after deleting them if they outside of policy threshold but it wasn't happening. FYI - I deleted 5 incrementals and what happened was that new main backup file created in addition to one original. The last incremental was in August and recent backup was done at the end of October. The backup has a size of almost same as original backup. I thought there should only be 1 original backup, modified as time goes, integrating obsolete backups into itself. I also used "Backup to Rotated Drives" feature additionally. I would make "Standalone Full Backup" once per month on different external drive. Does this sound like it's a bug? What if this confused VEEAM's retention policy as I was switching between?
Don't know if making this change is applicable in the process but it didn't make the difference.
Retention is applied at the end of backup job run, so to force the immediate merge you should start a backup job
I deleted 5 incrementals and what happened was that new main backup file created in addition to one original.
That is expected. You deleted the latest incrementals manually but metadata and backup database were not update. Job started a health check and thought that backup chain was corrupted, thus made a new full backup.
