Rotated hard drives support in v8

[bernardw]

Is there any way to remove a drive from a "rotated hard drive repository" I added one accidentally. Now the repository has changed drive letters to follow my mistake addition and there is no way that I can see to change the repository to a different drive letter!

If there is no current way to do these functions - shouldn't there be a way to do it?

[veremin]

What if you create a new repository without rotated drive option, move backup files to it, re-map backup jobs and delete the wrong repository afterwards?

[TonioRoffo]

I need some more information on rotated drive option.

* We are using a QNAP drive to connect the external, rotated drives. Drives present themselves as a CIFS share on the NAS \\nasname\sharename - where the CIFS name always stays the same, eventhough we have ~10 disks present. A backup copy job seems to run fine as long the drives are empty. As soon as a previously used drive presents itself, a new VBK gets created and fails halfway, because my disks haven't got the room for multiple VBK's. Shouldn't the VBK's be deleted if they are out of retention? Are they deleted before or after the backup run?

Basically I want to run a backup copy job, every night, to a drive, where the drive keeps a single .VBK

Thanks

[foggy]

Retention applies at the end of successful job run.

To perform cleanup of existing backup files prior each run, use the ForceDeleteBackupFiles registry key.

[JulianBlue]

"To perform cleanup of existing backup files prior each run, use the ForceDeleteBackupFiles registry key."

Are you saying that the ForceDeleteBackupFiles reg key is still DOING MORE THINGS in v8 (or v9?) than the "Rotated Hard Drives" setting of a Repository ?

Because I need to create everytime a single Full VBK on each rotated drive because of size contraints, so I ended up with a brutal pre-script:
del R:\CopyJob\*.vbk
del R:\CopyJob\*.vib

Thanks

[Gostev]

I wouldn't say "it does more", but it certainly "deletes more". Basically, it brutally wipes out everything from the job folder of newly inserted hard drive, whether or not some backups may still be under job's retention policy. Whereas the Rotated hard drives setting is "smarter" and only deletes backup files no longer under retention.

Looking at your script, it does exactly the same thing as what ForceDeleteBackupFiles registry key does.

[bernardw]

One thing to remember is that the Registry Keys only work on the "drive letter" the job last ran on. It does not move to the new drive letter when the rotated media changes drives.

[foggy]

For Windows repositories this shouldn't be the case, they support drive letter change.

[bernardw]

With Case # 01718268 and Veeam 9 it seems to be that the backup content is not removed when the drive letter changes (we are still working through the case).

My preference is to delete the content of the backups before the new backup runs because I have 6 TB drives and 4+ TB of backups to put on them. If the cleanup happens after or does not happen at all then my drives are full and the backups fail.

So we are trying to figure out what is going on and validate how the registry keys work in conjunction to the Veeam 9.

[foggy]

Thanks for sharing the case ID. If the repository is a Windows server (not CIFS share), I'd be interested in the results of your findings.

[bernardw]

Yes the repository is a windows server - USB drives directly connected to the Veeam console server.

[foggy]

Just to check, do you rotate drives each time the job runs? If the drive is the same and just the letter changes, cleanup will not be triggered.

[bernardw]

Yes I rotate the drives every day (other then the weekend). Every time I rotate the drives I want a new VBK file to be created by the Copy Job and the only way for it to fit is for the old files (VBK and possibly VIB) need to be deleted before the job starts.

In general I get the same drive letter from day to day and it works just fine. Last week we tried changing the drive letter and syncing the job. It detects that the media has changed but it did not delete the VBK file before running the copy job.

[foggy]

We will try to reproduce the behavior you're seeing, I'll get back with the results.

[foggy]

This turns out to be an issue with the backup copy jobs, regular backup jobs are unaffected. Will be addressed in the next version. Thanks for the heads up!

[bernardw]

Cool thanks for the update!

[Jamie Pert]

Hello Everyone,

Just so I am telling my client the right thing, can someone confirm whether the issue which Gostev suggests will be addressed in the next version is what I am seeing.

I am using Veeam 8.0.0.2084 to backup my client's production environment via a standard nightly reversed incremental job to a local iSCSI LUN (located on a Synology NAS). I then have 5 x 2TB USB 3.0 disks which are plugged into the USB 3.0 port on the synology and then published on \\dsnname\usbshare1, when disks are rotated it once more shows up as the same share.

The issue I am seeing is that the retention policy doesn't kick in, I have the correct settings in the repository config - but slowly the USB disks are filling up, the job is set to keep 2 retention points. I look and there is one .vbm file and on each backup occurrence there is a *.vbk and a *.vib file. At present the disk I am looking at 1 .vbm file and approx 6 x vbk and vib files.

I presume the easiest way to tackle this is to just manually delete these seemingly orphaned *.vbk and *.vib files which fall outside their retention period?

Regards,

Jamie Pert

[foggy]

Jamie, could you please clarify, you're doing backup copy to these rotated disks and the repository is exposed as CIFS share, right? Please keep in mind that retention on rotated drives works in case of Windows repository only.

[Jamie Pert]

Oh I didn't know retention didn't work on CIFS share. Sorted with a synology triggered script

[resruss]

Oh I didn't know retention didn't work on CIFS share.

So we've finally taken the bold step of migrating away from robocopy as a post-job script to Backup Copy jobs to CIFS and hit the same retention issue.
I understand that it's be design, but has anyone got a decent post-job action we can take.
From what I understand, Veeam purges all references to the previous backup chain when the media is rotated, so we can't query the database and delete items from disk.

Our design is:
1 VBR with a single dedicated CIFS NAS as the primary repository (I know it's not perfect).
2 rotatable NAS with the same IP and UNC path marked as rotatable media in Veeam.

We can't be the only people doing this, how does everyone else handle this?

[foggy]

What kind of post-job action do you need? Please note that rotated drive cleanup is available via the registry value.

[resruss]

So the post-script action we want is retention, as we've got 3 VBKs and a few VIBs on each NAS at the moment, which we're retentioning manually.

I looked at the registry key ForceDeleteBackupFiles, but saw that it's no longer needed in Veeam 8 and above (according to https://www.veeam.com/kb1154)

Am I mistaken, is the key still useful or is there another way to retention via a post-script?

[veremin]

Am I mistaken, is the key still useful or is there another way to retention via a post-script?

It depends on your requirements.

As stated in the referenced thread, the said key removes everything it finds in the job folder on newly-inserted drive, while corresponding GUI option (Rotated drive) does that only for backup files falling out of the specified retention.

Thanks.

[resruss]

Thanks v.Eremin,

Our requirements are to preserve the current backup chain only.
We tested that ForceDeleteBackupFiles with DWORD 3 and found that once we enabled our Backup Copy job it just left the VBM file.
We've since removed the registry key and rebooted.

To be more precise about our retention needs:
So what we noticed before we added the registry key is that the Backup Copy Job was set to:
- Forever Forward Incremental (no synthetic fulls created)
- Restore points was set to 4
At any point there was 2 - 4 VBK files and 3 VIBs between each chain, which I would expect
We're looking for a way to remove the old chains once the new one is created, retaining just a single copy of the VBK and VIB

Is there any way to achieve this on CIFS, even a clever post job script would be great.
Ideally, what we'd be after is if the backup chain no longer exists in the Veeam catalog, remove it from disk, but I'm not sure if this is possible in PowerShell, or too dangerous to do.

So figured I'd post here and see what solutions others have come up with in this situation.

[foggy]

You can create a script that would remove all backups older than the most recent full.

[resruss]

Yep, that's what I'm after, not sure how to start that though, which is why I'm posting here.
I want to keep the most recent VBK and subsequent VIBs but remove everything else.

Anyone got a sample / something similar to the above.

[foggy]

You can ask for assistance with that in the PowerShell subforum.

[JeremyWJ]

Is it possible to retain a set number of restore points on each drive with a copy job using rotated drives?

It appears I can only keep a set number across all drives.

[foggy]

Provided the repository is a Windows server, backup copy job should maintain the configured number of restore points on each drive.

[JeremyWJ]

The problem I'm having is the job is creating full copy jobs on the drives when I switch them. It is not continuing the chain currently on the drive with a new incremental. The result is the job takes 5 days to complete instead of a couple hours. I assumed this is due to the retention, but I'm not sure. I had the retention set to 2.

I have 5 drives, one for each weekday. If I leave say "Monday" in there for a few days it will do an incremental on it everyday just fine. Then when I put in "Tuesday" it will want to do a full again despite there already being a full backup there. Then when I switch back to "Monday" it start a new full backup on that drive as well, despite doing incrementals just fine before I rotated back to it.