So I did some testing after following the procedure written in this thread. Just to clarify, these are the steps I had to take:
Old PC/share: \\PC-Old\Share
New PC/share: \\PC-New\Share
1. Move the external hard drive to the new PC
2. Add new repository in Veeam as \\PC-New\Share
3. Go to existing backup job, and with \\PC-Old\Share still selected as the backup repository, click Map Backup
4. Map to backup to the same job
5. Now change the backup repository in the job to \\PC-New\Share and I could see the backup files listed
6. Click next, next, next and Finish
7. Job ran normally!
We're experiencing server growth, which is causing us to address hardware storage issues within our repository environment. All in all, not a bad issue, it's by design for increased usage of Veeam, specifically the use of backup copy jobs for its GFS abilities for our retention policies.
I've been able to change the target location without issue within Veeam and I've been manually moving the repository folder from one location to the other, prior to changing the target within the job(s) themselves. I just want to confirm that this is the best method or if there's another way that I should be migrating the destinations for these jobs.
It's likely that I'll need to migrate the jobs at least one or two more times before our upgrades are complete.
Could you clarify the issue?
Do you have existing backup jobs mapped to the repository?
You can just add the repository, make rescan it and you will see all backup files and restore points on it. Then you can map there your existing jobs if you have any.
We currently are running Windows 2012 servers for our Repository servers. We have Windows Dedup enabled and seeing good results.
We are now looking at upgrading these servers to Windows 2012R2. Is it as simple as building the new servers and moving the attached RDM's from the old servers to the new ones? Or is the a process out there that documents the steps required for replacing/upgrading the Repository servers?
That was what I thought as I have moved backup jobs around for space reasons. My biggest worry is copy jobs due to issues I am having now with moving them around. I am worried that I will move them and not be able to point the jobs to the new location.
You can wait for patch#2, if there are GFS restore points in backup copy job chain. The patch#2 should address the issue related to mapping a backup copy job to a chain with GFS restore points.
However, if there are no GFS restore point in chain, feel free to migrate repository now.
I wish to move a job from an old repository to a new one, but this job has 2 copy jobs associated with it which I don't want to touch or restart. One is offsite with low restore points, and one is a long term retention copy. If I point the backup job to the new repository, will the copy jobs just carry on fine with the incrementals? or will they lose the CBT and trigger a full copy?
ok thanks, that explains a basic move, but I should have added more in my original post.
What about this scenario. My current repository is a large RAID6 and was too slow to transform backup chains into rollbacks each week for this one job, so that job has 4 or 5 full VBKs files (so its large) The new repository is RAID10 but smaller, but it'll be quick enough to run rollbacks now, so it means that the old files wont all fit. I don't mind starting a new chain using the new settings in the new location, but I don't want to start a new chain on the copy jobs, as I'm short of disk space in that copy job location.
If you perform repository change correctly, backup copy job should proceed fine with incremental runs even if you start the backup job from scratch (unless specific source repository is specified to look for restore points in).
So I'm worrying over nothing then, I just edit the job, tick on the rollbacks box and point it to the new location , keep all the copy jobs the same, and it'll just work?
What will happen to the old backup files, will they just remain the original location and i'll have to tidy up manually once I'm happy with the new backup?
Will I end up having two lots of backups in the Disk section with the same name, but different creation times?
- If you decide not to move backups to a new repository, but leave them there, they will not be deleted automatically.
- Name of backup file includes the backup date, so names will differ.
Hi, I've seen a few posts related to my question, but they are 12 months or more old, so I'm wondering what's the situation with the newer versions of Veeam:- I've got a client running Veeam on an old physical server and their backup repository is a SAN LUN that's mounted as a local disk to the server as a drive letter. They want me to re-install Veeam onto a brand new server that's got "tons" of internal disk capacity that will be setup as a new backup repository and they want me to migrate their backup job configurations/settings and to also move/relocate the repository. They then want me to decommission the old Veeam server and re-purpose the LUN as quickly as possible.
If there's no way to migrate the backup job settings/configuration database from the old Veeam server to the new one, it's no big deal for me to setup all the jobs again on the new server, but what's the best way for me to move/relocate the repository? I want to be able to restore from previous backups if required.