So over the weekend, our weeklys failed - The NAS we back up to was full. At the time our retention was set to 25 points.
Veeam Backup & Replication creates a forever forward incremental backup chain in the following way: During the first session of a backup job, Veeam Backup & Replication creates a full backup file on the backup repository.
Our backups are about 1.2tb for full, 30-40gb per incremental. The NAS has 6.8tb space. Normally, we can just squeeze 4 weekly backups on there with the associated incrementals.They're offloaded to tape weekly, so it's not essential to keep them, just quicker if we need access to them within a month.Anyway, after these problems, I lowered the retention to 21, which should only keep 3 weeks worth, prior to the full that it is trying to create. I left the job to run overnight - It failed.Thinking maybe my maths was wrong, I reduced the number to 15 and manually ran the job (though not the full, just an incremental), surely leaving 2 weeks worth, plus 1 for the point I was creating. Either way, I was now 10 points LESS than my original retention policy, so surely it should have at least deleted the oldest week.It did not.
I have now set the retention to 2. Surely this should keep the last full and any incrementals since? Every single file is still there, I'm just gathering more incrementals!My weeklys are now 4 days overdue, I need to get a full done today. Is there a way I can safely remove files from the drive without screwing the backup chain? All have been written to tape anyway, I just need the last 11 incrementals and previous full in order to create this weeks full?
Hi Jamie,I guess you're using forward incremenal backup method (don't mix it with forward incremental-forever backup). Unfortunately, there is no way to work around here and remove just a part of the backup chain. You should consider the chain as a whole piece.
Without previous incrementals, newer ones don't make sense. And you won't be able to restore from them.Let me share a good KB, which explains how backup methods work (retention policy included):If you say, you're having that backup chain already on tapes and right now there is no space on a disk, it would be safe to delete the whole backup chain, adjust retention policy (+ maybe backup method) and start the backup over.Please let me know what you think.Picture to explain the retention policy = 3 points. You might want to do this with two jobs. A regular job, and then a Backup Copy Job. Retention is retention and can be set to different numbers. Say if you do the default 14 and you backup weekly, then you are going to see backups getting overwritten after 14 weeks to match the retention. For backup each month, you'll get 14 months.
Make sense?You also need to determine which backup method you will be doing. Forward, Reverse, or Forever Incremental.
They have each have their place. Head over to this place and read through the different backup methods.
JV-Tech-Services wrote:I agree with Denis and Robert. In my experience, incremental backups run a lot quicker than reverse incremental. And the restore process is honestly not that much faster with reverse incremental. I haven’t found reverse incremental in Veeam to be worth the longer backup time every night. Hope this helps. Have a great day!I exclusively use Reverse because we off-site with rotated media.
My entire environment can be restored from one disk. If our company went poof, I don't want to be reliant on multiple media to get us up quickly, especially if the chain is across media and say one media goes bad.Anyway to each to their own based on their requirements. Hi Jamie,I guess you're using forward incremenal backup method (don't mix it with forward incremental-forever backup). Unfortunately, there is no way to work around here and remove just a part of the backup chain. You should consider the chain as a whole piece. Without previous incrementals, newer ones don't make sense.
And you won't be able to restore from them.Let me share a good KB, which explains how backup methods work (retention policy included):If you say, you're having that backup chain already on tapes and right now there is no space on a disk, it would be safe to delete the whole backup chain, adjust retention policy (+ maybe backup method) and start the backup over.Please let me know what you think.Picture to explain the retention policy = 3 points. The problem is, I have all of last weeks incrementals, but haven't managed to do the synthetic full which combines them all. Things are even weirder (to me) now - Since i set the retention to 2, and set the job off doing an incremental, it has completed the incremental and is now 'Merging oldest incremental backup into full backup file'. So now it is overwriting last weeks full, adding all the incrementals since then.This will get me what I want I guess - an up to date synthetic full - but entirely different behavior to normal.
Why hasn't it just deleted the older fulls, and created a new synthetic full for this week? The thing is that removal of the backup points happens by the end of the backup task.
Veeam is able to produce a new backup point and then applies the removal procedure, calculating how many restore points will be left in repository if it deletes the oldest backup chain. If this number is less than retention number you set, Veeam won't delete anything.it does want to meet your retention policy, even if it has to be some redundant points on repository temporarily.
Please let me know if there is any question about it. OK, this turned out to be down to several confusions on my part. But have learned - Number of restore points is not neccessarily number of files.
(This was the start of my problems)- Retention algorithm is applied at the END of a full backup. (not knowing this made me try allsorts, making things worse)- If you don't schedule a synthetic full at any time, it will merge all incrementals into the last full taken, and will take AGES. (down to my own ignorance, since it is documented in the link andrew supplied above)Thank you very much to andrew for taking the time to review logs and patiently help me.Also, chuckdiesel - Thanks for the advise. The NAS is indeed presented as a local drive.
We moved to 2012 r2 just last month just for the dedupe. Strangely (for me) the whole process went pretty smoothly and dedupe worked a treat!