-
- Veteran
- Posts: 264
- Liked: 30 times
- Joined: Mar 22, 2011 7:43 pm
- Full Name: Ted
- Contact:
Enhancement request, I think - move repository
I'd like to be able to move a repository without having to modify the jobs which reference the repository. From what I've been able to figure, you have to copy a repository's contents to a new repository and edit the various jobs to use the new repository (plus some other things like remove/rescan).
Since I have a lot of jobs, I'd much prefer to just modify the existing repository and point it to a new storage location (for example, move from w:\backups to v:\backups). I don't really care if Veeam facilitates moving the files or if it just provides a way to change the path after I manually move the files.
Since I have a lot of jobs, I'd much prefer to just modify the existing repository and point it to a new storage location (for example, move from w:\backups to v:\backups). I don't really care if Veeam facilitates moving the files or if it just provides a way to change the path after I manually move the files.
-
- VP, Product Management
- Posts: 6012
- Liked: 2843 times
- Joined: Jun 05, 2009 12:57 pm
- Full Name: Tom Sightler
- Contact:
Re: Enhancement request, I think - move repository
Perhaps I'm being silly, but why not just make the new repository W:? Then you don't have to change anything, just copy the files.
-
- VP, Product Management
- Posts: 27120
- Liked: 2721 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: Enhancement request, I think - move repository
Do you move backup files to the new repository because of the lack of free space or just the hardware upgrade?
-
- Veteran
- Posts: 264
- Liked: 30 times
- Joined: Mar 22, 2011 7:43 pm
- Full Name: Ted
- Contact:
Re: Enhancement request, I think - move repository
Tom -- I have (had) multiple repositories on w:. 2 were rather small and I could have moved them easily. The smallest one, however, is associated with about 15 replication jobs. It took me most of a week to copy all 3 repositories.
Vitaliy -- From a conceptual viewpoint, there could be lots of reasons for this feature (which is probably stating the obvious). I had an unusual reason. My main backup repository is 8Tb. By coincidence, I added storage to my SAN and I upgraded to ESXi 5.5. I decided to take advantage of the new >2Tb virtual disk (my repositories are in a VM). So I created a single 8Tb virtual disk and copied all the existing data to the new disk. Then I swapped the drive letters and deleted the old volume (5 spanned disks). I then increased the 8Tb disk and extended the volume. Now I have a single 16Tb virtual disk with a single 16Tb volume on it.
Oh -- and I (oops) had formatted the original volume with the wrong allocation unit size -- so I was able to fix that at the same time.
I guess the point of my enhancement request was to allow for modification of repositories (in particular changing the storage) without having to modify any jobs that reference the repositories.
Vitaliy -- From a conceptual viewpoint, there could be lots of reasons for this feature (which is probably stating the obvious). I had an unusual reason. My main backup repository is 8Tb. By coincidence, I added storage to my SAN and I upgraded to ESXi 5.5. I decided to take advantage of the new >2Tb virtual disk (my repositories are in a VM). So I created a single 8Tb virtual disk and copied all the existing data to the new disk. Then I swapped the drive letters and deleted the old volume (5 spanned disks). I then increased the 8Tb disk and extended the volume. Now I have a single 16Tb virtual disk with a single 16Tb volume on it.
Oh -- and I (oops) had formatted the original volume with the wrong allocation unit size -- so I was able to fix that at the same time.
I guess the point of my enhancement request was to allow for modification of repositories (in particular changing the storage) without having to modify any jobs that reference the repositories.
-
- VP, Product Management
- Posts: 6012
- Liked: 2843 times
- Joined: Jun 05, 2009 12:57 pm
- Full Name: Tom Sightler
- Contact:
Re: Enhancement request, I think - move repository
My question was focused solely on making sure I understood your request as it wasn't exactly clear to me since you said:
To me, if you had to move the files anyway, then I wasn't sure why you wouldn't just move the files and call it W:. That was where the disconnect was from my perspective. But I think I understand what you are getting at now.I don't really care if Veeam facilitates moving the files or if it just provides a way to change the path after I manually move the files.
-
- Veteran
- Posts: 387
- Liked: 97 times
- Joined: Mar 24, 2010 5:47 pm
- Full Name: Larry Walker
- Contact:
Re: Enhancement request, I think - move repository
Could of used a move repository today. Ran out of space and moved backup copy data for one job to new locations. Removed, rescanned thought it worked. started to sync and it is taking too long. Noticed that the number of restore points is wrong, had 70 now only 12. Will see what I get in the morning as this is the offsite backup copy so I expect hours of waiting.
-
- Veeam Software
- Posts: 21071
- Liked: 2115 times
- Joined: Jul 11, 2011 10:22 am
- Full Name: Alexander Fogelson
- Contact:
Re: Enhancement request, I think - move repository
Larry, I would expect incremental job run after performing all these steps. However, could you please check the target repository, do you see the new increment in the corresponding folder? If, for some reason, entire VM data are transferred, the new backups should be placed in the {old_name}_1 folder.
-
- Veteran
- Posts: 387
- Liked: 97 times
- Joined: Mar 24, 2010 5:47 pm
- Full Name: Larry Walker
- Contact:
Re: Enhancement request, I think - move repository
They were being placed in the new folder. I can import the old ones and read the data but a rescan doesn't find them all. Because I can import I am not going to find out why this happened.
-
- VP, Product Management
- Posts: 27120
- Liked: 2721 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: Enhancement request, I think - move repository
Backup copy job can only me mapped to a VBK file without incrementals, that is why job has created a new backup/files chain.
-
- Veeam Software
- Posts: 21071
- Liked: 2115 times
- Joined: Jul 11, 2011 10:22 am
- Full Name: Alexander Fogelson
- Contact:
Re: Enhancement request, I think - move repository
Most likely you've imported backups prior to performing rescan of the repository folder, that's why rescan didn't work. No need to import, rescan is enough and, moreover, it would allow you to proceed with increments rather than copying the entire VM data again.
-
- Enthusiast
- Posts: 99
- Liked: 12 times
- Joined: Jul 23, 2012 3:48 pm
- Contact:
Re: Enhancement request, I think - move repository
I have had to do a lot of this recently. Ran out of space on one of my volumes, added hard drives and couldn't expand the existing volume. So I made a new volume and moved some of the jobs. All I did was make a new repository on the new volume, move the data for some of the jobs (making sure the job itself was disabled or that I could get back to it before it was scheduled to run), and then just update the storage location of the job after the move was complete to point to the new repository.
-
- Influencer
- Posts: 15
- Liked: 4 times
- Joined: Nov 11, 2013 10:53 pm
- Full Name: a p
- Contact:
Re: Enhancement request, I think - move repository
I'm definitely in favor of this as a feature.
I'd love to be able to right-click a job and "Migrate to a new repository".
In my estimation, this would:
-Prevent a new run of the job from executing until the migration is completed (or at least offer this as an option, to avoid weirdness with restore points).
-Move the existing backup files for this job from the old repository to the new one.
-Change the job's target repository accordingly.
There are currently too many error-prone steps involved to shift an organization's backups from one piece of storage to another. And the "change the drive letter" idea only works if you can do it all in one lump. But when you're talking about moving several terabytes of information around, it's going to take several days to complete, and it has to be done in parallel and in pieces, adjusting the appropriate jobs as you go.
Generally, without this, how do you age out your old backup storage target gracefully and point all the jobs to a newer larger faster one? I counted at least 15 clicks per job unless I'm doing it wrong, and that's just if it goes well. That's also with an unknown amount of babysitting while the manual file copy completes.
If someone has already posted some PowerXXX to deal with this, I'm sorry I missed it. That would be an acceptable alternative.
I'd love to be able to right-click a job and "Migrate to a new repository".
In my estimation, this would:
-Prevent a new run of the job from executing until the migration is completed (or at least offer this as an option, to avoid weirdness with restore points).
-Move the existing backup files for this job from the old repository to the new one.
-Change the job's target repository accordingly.
There are currently too many error-prone steps involved to shift an organization's backups from one piece of storage to another. And the "change the drive letter" idea only works if you can do it all in one lump. But when you're talking about moving several terabytes of information around, it's going to take several days to complete, and it has to be done in parallel and in pieces, adjusting the appropriate jobs as you go.
Generally, without this, how do you age out your old backup storage target gracefully and point all the jobs to a newer larger faster one? I counted at least 15 clicks per job unless I'm doing it wrong, and that's just if it goes well. That's also with an unknown amount of babysitting while the manual file copy completes.
If someone has already posted some PowerXXX to deal with this, I'm sorry I missed it. That would be an acceptable alternative.
-
- Product Manager
- Posts: 20284
- Liked: 2258 times
- Joined: Oct 26, 2012 3:28 pm
- Full Name: Vladimir Eremin
- Contact:
Re: Enhancement request, I think - move repository
The typical approach includes moving backup files to a newly-created repository and mapping backup jobs to the moved data (Edit -> Storage -> Repository -> Map). I've never counted the clicks, though. Thanks.Generally, without this, how do you age out your old backup storage target gracefully and point all the jobs to a newer larger faster one? I counted at least 15 clicks per job unless I'm doing it wrong, and that's just if it goes well.
-
- Influencer
- Posts: 15
- Liked: 4 times
- Joined: Nov 11, 2013 10:53 pm
- Full Name: a p
- Contact:
Re: Enhancement request, I think - move repository
I don't mean to focus on the clicks, really. My perspective has been that it doesn't scale at all. If I have 2 or 3 jobs, it's not a big deal. As the environment grows and I manage more and more jobs and repositories at different locations, this becomes more challenging to administer. As the backing files become large (TB+), I can't necessarily sit and watch the copy complete, so now I'm either copying files that could be out of date by the time the copy finishes or stopping a job for an extended amount of time until the copy completes and the other steps dependent on those files moving can be completed. So as our environment grows, expands or evolves, this feature saves meaningful amounts of time and stress and minimizes the time needed to perform the steps and get on to the business of capturing another backup to the new target, which is all I really wanted to do. Hope that makes sense =)
-
- Influencer
- Posts: 15
- Liked: 4 times
- Joined: Nov 11, 2013 10:53 pm
- Full Name: a p
- Contact:
Re: Enhancement request, I think - move repository
For me, here's an alternative to all of this:
Start backing up to the new repository without moving files. Just age out the old ones as the restore points expire, then remove the old repository when it's no longer in use.
This might not fit for everyone, particularly if they want to forklift the old repository out ASAP. But in my case, I could live with specifying the new datastore target, leaving the old backups where they sit, then just waiting for the files that were there to expire out. Anything new could be written to the new target immediately without moving the old files. This would accomplish "migration" by abandonment and ignore the copying and mapping. I'm imagining some scenarios where it might not work, but it's something that was rolling around in my head.
Start backing up to the new repository without moving files. Just age out the old ones as the restore points expire, then remove the old repository when it's no longer in use.
This might not fit for everyone, particularly if they want to forklift the old repository out ASAP. But in my case, I could live with specifying the new datastore target, leaving the old backups where they sit, then just waiting for the files that were there to expire out. Anything new could be written to the new target immediately without moving the old files. This would accomplish "migration" by abandonment and ignore the copying and mapping. I'm imagining some scenarios where it might not work, but it's something that was rolling around in my head.
-
- VeeaMVP
- Posts: 6139
- Liked: 1932 times
- Joined: Jul 26, 2009 3:39 pm
- Full Name: Luca Dell'Oca
- Location: Varese, Italy
- Contact:
Re: Enhancement request, I think - move repository
Not sure it will always work: based on the type of backup, you should also move at some point the full backup. Think about reversed incremental, there is no active full backup creation unless specifically configured (not default), and since the full backup is also the latest one, this needs to be created directly into the new repository.
Luca Dell'Oca
Principal EMEA Cloud Architect @ Veeam Software
@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2022
Veeam VMCE #1
Principal EMEA Cloud Architect @ Veeam Software
@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2022
Veeam VMCE #1
-
- Product Manager
- Posts: 20284
- Liked: 2258 times
- Joined: Oct 26, 2012 3:28 pm
- Full Name: Vladimir Eremin
- Contact:
Re: Enhancement request, I think - move repository
Also, if you just want to start creating new restore points in a new repository, paying little attention to the previous chain, then, you can probably delete corresponding backup data "from backups" and change target settings of a given job. With rotated media regkey in place, the job should start backing up data to the new repository smoothly.
Even though it's not exactly what you're asking for, it still might be useful in some situations.
Thanks.
Even though it's not exactly what you're asking for, it still might be useful in some situations.
Thanks.
-
- Veeam Software
- Posts: 21071
- Liked: 2115 times
- Joined: Jul 11, 2011 10:22 am
- Full Name: Alexander Fogelson
- Contact:
Re: Enhancement request, I think - move repository
Yes, this is something you can accomplish with the current version. Here's an existing topic with more details: Change Repository Without Copying Files.andrewpetre wrote:For me, here's an alternative to all of this:
Start backing up to the new repository without moving files. Just age out the old ones as the restore points expire, then remove the old repository when it's no longer in use.
-
- Lurker
- Posts: 2
- Liked: never
- Joined: Oct 14, 2014 1:04 am
- Full Name: Michael Leo
[MERGED] Feature Request: Moving Backup Repo (case #00647287
This is regarding the ease of changing repository locations or hostnames in the console is not as robust or simple as it could be.
We must be able to make changes within Veeam in order to match changes in the Virtual infrastructure ongoing.
In my case, our network evolved. A storage VLAN was added and new interfaces plumbed into our vSphere hosts, the backup SAN, and the VEEAM server. This was very difficult to reconfigure even though logically, nothing changes. Essentially, we wanted the same servers backed up to the same SAN using the same VEEAM server. Just over the new network.
Please let me know if more details are needed.
We must be able to make changes within Veeam in order to match changes in the Virtual infrastructure ongoing.
In my case, our network evolved. A storage VLAN was added and new interfaces plumbed into our vSphere hosts, the backup SAN, and the VEEAM server. This was very difficult to reconfigure even though logically, nothing changes. Essentially, we wanted the same servers backed up to the same SAN using the same VEEAM server. Just over the new network.
Please let me know if more details are needed.
-
- Veeam Software
- Posts: 21071
- Liked: 2115 times
- Joined: Jul 11, 2011 10:22 am
- Full Name: Alexander Fogelson
- Contact:
Re: Enhancement request, I think - move repository
Michael, in your case you might not need to change anything, if repository server was added into Veeam B&R console by DNS name. Just changing the corresponding primary address in the hosts file on the Veeam B&R server should do the trick.
-
- Lurker
- Posts: 2
- Liked: never
- Joined: Oct 14, 2014 1:04 am
- Full Name: Michael Leo
Re: Enhancement request, I think - move repository
Masking the true host name resolution by adding hosts file is a very bad practice. It confuses system administrators when you address a host as different names in different places. Please note that not only did the DNS name and address of the repository change, but so did the DNS name and address of the vSphere hosts. Nothing actually moved. Granted, it would have been nice had the infrastructure been totally planned in advance, but I assert this isn't possible. Things change.
-
- Veeam Software
- Posts: 21071
- Liked: 2115 times
- Joined: Jul 11, 2011 10:22 am
- Full Name: Alexander Fogelson
- Contact:
Re: Enhancement request, I think - move repository
I got your point, just wanted to suggest a possible workaround, which could serve as a temporary solution until you find time to perform all the required changes in Veeam B&R console to reflect environmental changes. Anyway, thank you for the feedback.
Who is online
Users browsing this forum: justin.hendren, sarapinho and 135 guests