Veeam Backup & Removable Media (rotated drives)

[Gostev]

This scenario is not yet supported with v6 backup repositories. I believe, you can make it work if you make sure subfolders where each job puts backups into still exist on the newly inserted drives (but I have not tested this myself).

[rileybloke]

Hello,

After upgrading from V5 to V6, I cannot setup a simple backup job.
I have a Dell RD1000 drive which is presented to Windows as a removable drive, physically it is a removeable cartridge similar to a tape, but not tape.

I have 2 cartridges A & B which we alternate daily. In version 5 I had a simple backup job (reversed incremental) full backup every day. This backup job would run overnight and create a VBK file on the cartridge (removabel drive).
We swap the cartridges each day, to ensure we always had a full backup of the VM off-site.
The job was configured for only 1 restore point, as 1 removable drive could only hold 1 full backup.
A script is run to delete the VBK file from the removable drive before the job runs.

In version 6 we had to create a repository pointing the removable drive, the backup job works on its 1st time run directly after creation of the job, but any subsequent jobs failed with an error "Failed to save backup meta to 'E:\Backups\CMSVR1-BK\CMSVR1-BK.vbm' [VEEAM-PC] Failed to save file content. The system cannot find the path specified "

Speaking with support, they advised to delete the VBM file (new in V6) along with the VBK file, but it still failed.
Then support advised I need to create 2 repositories, and 2 jobs, and alternate the jobs with the drives.
I dont think this method is efficient, as the operator would need to make sure the correct cartridge is inserted for that day, in their absence the job would fail, especially if they were absent for a few days.

Is there any way we can run a backup every day as in version 5?
I have had to revert back to Version 5 in the meantime.

Thanks

[rileybloke]

Hi Gostev,

Thanks I tried to keep the folder structure on the removable drives, but it needs the VBM and VBK files to already exist from the most previous job. As we have swapped drives it is not the most previous job, but the 2nd to most pervious, if you get me

Shame, im stuck on V5:-(

[foggy]

Phil, have you set the registry key discussed in this topic above? With the key set, VBR should not require any files to exist at all. (Please note, however, that, as Anton has already said, this scenario was not tested and cannot be supported - just a guess.)

[stormlord]

Hi, I have the same problem, I backup over 10 usb disk. 5 each week in rotation.
But its no sense to create 10 job.
What is the best practice for this in v6 ?

I have think to make backup local and create a erease copy job schedule, but its not very a clean way.
Thanks to all.

[mbiesheuvel]

I also have the same problem. We have lots of customers with Veeam. I want to update them Veeam 6 but this is something I really need.

The problem is that some backups are big > 1TB. This can be copied to an E-SATA disk without any problems but I do not want to use Reversed Incremental (because the 1TB file is changed every single day). This is a big file which needs time to copy.

Thats' why we choose to use the incremental option. In the weekend we shuffle the folder the vbk is stored on and then a new full is made. This method is working and the backups are copied afterwards to disk fine. If we do not shuffle and use the option "transform previous full backup chains into rollback" it takes 24!! hours to complete this. This is abnormal long and that's why I reject to use it. Or is this option optimized in Veeam 6 so it takes shorter to complete?

In other words please enable the option again. I have already tested it in Veeam 6. So I have set the registry key and made a new job. Shuffled the backup and let the backup start. But I get the same error as everyone else:
19-1-2012 14:34:50 :: Failed to save backup meta to '\\nas01\backup\week1\veeam\Backup Veeam\Backup Veeam.vbm'
[BACKUP01] Failed to save file content.
The system cannot find the file specified.

[Vitaliy S.]

Michel, have you tried the workaround that Anton has mentioned in the previous post?

This scenario is not yet supported with v6 backup repositories. I believe, you can make it work if you make sure subfolders where each job puts backups into still exist on the newly inserted drives (but I have not tested this myself).

[mbiesheuvel]

Well we do not backup to disk directly. We backup to a NAS and then with a Backup PC to an E-SATA disk. The point is we want to go back in time for a couple of weeks but do not want to use the retention of 28 days or use the Incremental which wants a full every week. We just want to have the option to create a full backup every week in a new folder which can be copied to disk which contains 1 week data.

I just do not understand why the option is removed. You said it is because of technical reasons? Which reasons if I may ask? I am really interested in the technical answer.

What if we use only one Backup Proxy with one destination? Just like in version 5.

My opinion is Veeam is thinking to much in Enterprise and if forgetting the smaller sized companies with max 5 ESX servers. With this option removed we need to rethink our backup method. I was so happy with Veeam but this really makes me think.

[tsightler]

I think the "technical reasons" are probably referring to the benefits of splitting the metadata into a separate file. There are many, many benefits to this approach, some of which are already in V6 (virtually instant import of backup files, compared to a relatively slow process in previous versions), and some that will be coming in future versions.

Unfortunately, this new enhancement broke an existing feature that some customers were using. This "rotation" feature was not used by the majority of customers, which is why it required a registry key to enable. Most customers seem to simply choose to copy the files for their "offsite" rotation media using a post-job script, which still works fine with V6.

I'm still not 100% clear as to what you are currently doing. You're backup up to a NAS, and then copying this to removable media? Then basically emptying the folder? Have you tried simply copying the VBM file back in place into the new folder? I'll try to play with it a little bit.

[tsightler]

I have 2 cartridges A & B which we alternate daily. In version 5 I had a simple backup job (reversed incremental) full backup every day. This backup job would run overnight and create a VBK file on the cartridge (removabel drive).
We swap the cartridges each day, to ensure we always had a full backup of the VM off-site.
The job was configured for only 1 restore point, as 1 removable drive could only hold 1 full backup.
A script is run to delete the VBK file from the removable drive before the job runs.

In version 6 we had to create a repository pointing the removable drive, the backup job works on its 1st time run directly after creation of the job, but any subsequent jobs failed with an error "Failed to save backup meta to 'E:\Backups\CMSVR1-BK\CMSVR1-BK.vbm' [VEEAM-PC] Failed to save file content. The system cannot find the path specified "

Speaking with support, they advised to delete the VBM file (new in V6) along with the VBK file, but it still failed.
Then support advised I need to create 2 repositories, and 2 jobs, and alternate the jobs with the drives.
I dont think this method is efficient, as the operator would need to make sure the correct cartridge is inserted for that day, in their absence the job would fail, especially if they were absent for a few days.

Is there any way we can run a backup every day as in version 5?
I have had to revert back to Version 5 in the meantime.

This particular use case is easy. If I understand correctly, you're basically just running a full backup every night. So, add the registry key, set your retention to the lowest value, and configure the job to run an active full every night. This works fine in my testing.

[jpaul]

Sounds to me like Veeam needs to make a "USB tape engine" LOL

[pitchpartners]

Well we do not backup to disk directly. We backup to a NAS and then with a Backup PC to an E-SATA disk. The point is we want to go back in time for a couple of weeks but do not want to use the retention of 28 days or use the Incremental which wants a full every week. We just want to have the option to create a full backup every week in a new folder which can be copied to disk which contains 1 week data.

I just do not understand why the option is removed. You said it is because of technical reasons? Which reasons if I may ask? I am really interested in the technical answer.

What if we use only one Backup Proxy with one destination? Just like in version 5.

My opinion is Veeam is thinking to much in Enterprise and if forgetting the smaller sized companies with max 5 ESX servers. With this option removed we need to rethink our backup method. I was so happy with Veeam but this really makes me think.

Totally agree!! Whats happening to the SMB market? Also creating Proxies here n there is not an option for some SMB's.

Please Veeam fix this issue that been broken. Coming from an SMB market, v6 is not so friendly and considering rolling back.

[mbelcourt]

I have the same problem when I use a USB hard drive.

The temporary solution (hopefully temporary) I've found, is to delete the job was done the day before.
1) go to "Backup & Replication"
2) go to the subfolder "Backup"
3) Right click on the job
4) Select "Remove from backups"

The problem is I need to do this every day

[pitchpartners]

Theres no logic in this. Unless this is sorted soon new SMB clients of ours will be sold different backup software.

[tsightler]

I have the same problem when I use a USB hard drive.

The temporary solution (hopefully temporary) I've found, is to delete the job was done the day before.
1) go to "Backup & Replication"
2) go to the subfolder "Backup"
3) Right click on the job
4) Select "Remove from backups"

The problem is I need to do this every day

Once again I will ask, are you simply running a full backup every night? If so, the registry key will still work. Simply configure the job to run an active full every night with the registry key and all is good.

You could also easily script the "Remove from backups" tasks via PowerShell and have the server automatically do this just prior to the backup run.