Moving backup files

[codot]

Hello,

Not sure if someone has been over this subject, I couldn't find any topic about it.

I had an issue. The NTFS volume I was backing up on was nearly full so I decided to move the files from one backup volume to another volume.

First I've deleted the backup reference from the "Backups" view (backup reference, not the actual backup files). Then I have moved the files from one volume to another.

Finaly, I've tried to import the backup files. My problem is that I now have 5 references to the same backup job (retention set to 24, 6 times a week backup with a full set on the 6th day of each week) with the _imported suffix since I have a total of 5 vbk files plus vrb's in the backup folder of this VM.

I have tried to modify the backup destination on the job and run it again, but it has started a new cycle, not recognizing the previous backups in the same folder it is actually saving the vbk in.

Is there a way to import those vbk files in the same reference in the "Backups" view to have only one cycle displayed and managed?

Not sure I made myself very clear...

That could be an improvment for future version : an wizard to move backup jobs in a consistent manner.

Thanks.

Clement.

[Vitaliy S.]

Hello Clement,

If you need to change destination target for your backup jobs, you need:

1. Relocate whole backup set (all VBK, VIB and VRB files) to a new storage.
2. Update Path to Folder option in the Edit Backup Job settings with the new storage path.

This way, the job will continue running transparently.

When you choose Remove from Backups you remove all the records from SQL configuration database, so the corresponding VBK file cannot be used to continue a backup job any more. You can import the VBK and use it for restore purposes, but you cannot "attach" imported backup set to a job.

Thanks!

[codot]

Allright, thanks Vitaliy. Next Time, I'll know what to do. I wasn't sure if there was a path recorded in the DB for each and every backup occurence previously made, so I didn't thought this would work.

So, no need to re-run the job after the update on the path to folder var? If I want to restore a file after this update, the backup record in "backups" will request the path to folder var from the backup job?

Thanks.

[Gostev]

There is no need to re-run the job if backup location was updated correctly by editing the job as explained above. Thanks!

[flavor4real]

[merged]

Hello,
I have a VEEAMSERVER1 which runs all Backup Jobs. We are setting up a temporary VEEAMSERVER2 with the identical Jobs, including Job names.

1st. Question: Can I share the VEEAMSQL Database between these two VEEAMSERVERS?

2st. Question: If I would move all VBK's and VIB's from the VEEAMSERVER1 Storage Drives to the VEEAMSERVER2 Storage Drives, and connect the new VEEAMSERVER2 to the existing VEEAMSQL DB. Would this work and will I be able to restore in case I have too?

Thanks,

[Vitaliy S.]

1. No, two or more backup servers cannot share the same database.

2. Yes, but once you've done that, you would also need to update destination target for existing backup job to point to storage drives on Veeam Server 2. If you don't want to continue backup jobs and use these files for restore possibilities only, then all you have to do is import those backup files to Veeam Server 2.

[analyst]

The ability to move backup jobs and change destinations within the application would be a significant enhancement! It's a pain to move all files, edit job paths when managing hundreds of backups. Many backup vendors provide this functionality wihtin their product. It would be sweet to be able to simply right click a job and select "Move" to move all files associated with a particular job to another storage destination and have the files move and data updated within the backup.

[Gostev]

We only had a handful of requests for this feature, not sufficient to justify implementing it. Plus, the value it adds to the product is questionable (comparing to other pending features). It's definitely not a common task - especially if you carefully plan your deployment in advance, which is usually the case with larger customers. And for smaller customers who did not do advance planning, it's not a big deal to update a few jobs and move a few files manually. In any case, it only happens once in a life time, pretty much. If you've done the backup placement mistake once, you are unlikely to repeat it.