Skip to main content

If I were to create a new copyjob to replace an old one, and I want it to only move over the very latest restore point and none of the previous restore points that are currently in the repository; can this be accomplished by taking a new active full on the source jobs and then running a sync now on the new copyjob and telling it copy over the latest? If not, can this only be accomplished by wiping out all current local and cloud and starting from scratch?

It’s some time ago, but if I remember correct the copy job wizard asks if you want to process all restore points or the last one only….


If I were to create a new copyjob to replace an old one, and I want it to only move over the very latest restore point and none of the previous restore points that are currently in the repository; can this be accomplished by taking a new active full on the source jobs and then running a sync now on the new copyjob and telling it copy over the latest? If not, can this only be accomplished by wiping out all current local and cloud and starting from scratch?

pEdited]
If you run active full, it should copy older ones anyway.
I think you can rename source folder (so no wipe needed), launch a full and then copy job.


If I were to create a new copyjob to replace an old one, and I want it to only move over the very latest restore point and none of the previous restore points that are currently in the repository; can this be accomplished by taking a new active full on the source jobs and then running a sync now on the new copyjob and telling it copy over the latest? If not, can this only be accomplished by wiping out all current local and cloud and starting from scratch?

pEdited]
If you run active full, it should copy older ones anyway.
I think you can rename source folder (so no wipe needed), launch a full and then copy job.

That’s not a bad idea. I didn’t consider a folder rename. By doing that, what happens on the Veeam side of things? Does Veeam see that chain tied to that folder, and if I rename it, it will fail because it can’t find a folder by that name, but by running a new full, it won’t matter? That now makes me think, what if I did “remove from configuration” on the current backup chain and then ran a new active full? Would that have the same effect? I think the issue there will be all of the old restore points still sitting in the same folder as the new chain, and that can get confusing if you need to end up pruning out that old chain.

 

But from you experience, if I take a new active full, I sync and tell it to only copy the latest, it won’t go back further than the beginning of the new backup chain (which in this case would the new full)?


For my experience Veeam will create another folder with right name and redo a full active backup (but I always prefere a manual active full launch). Never got an error with this method.


I checked and did not see the option to select which restore points in the BCJ wizard.  A question would be are you using the same repository for the BCJ and VM at the destination?  If so you might be able to map the job to use the existing files and then it will only copy changes from the new BCJ.

@marcofabbri - also makes a good point as well if the above does not work. :smiley:


Have checked, too.

No, this option is not available with Backup copy Jobs, it’s available with tape jobs.

Sorry, I did mix up these two….


Indeed, agree with @JMeixner and @Chris.Childerhose . As @JMeixner  mentioned, that is only possible with tape-jobs, not with copy-jobs. Run an active full so you have a new chain or map to existing chain as @Chris.Childerhose  mentioned.


@bp4JC rename folder did the trick?


Regarding the original question @bp4JC was asking: doesn’t a backup copy job always only copy the latest backup state in the very first run and this will thus always be an active full? A single new VBK is produced.

https://helpcenter.veeam.com/docs/backup/vsphere/backup_copying_process.html?ver=110

From my knowledge it’s the other way around: it’s not easy to have it copy the full chain with all the history… Here we would need some folder operations...

 


Regarding the original question @bp4JC was asking: doesn’t a backup copy job always only copy the latest backup state in the very first run and this will thus always be an active full? A single new VBK is produced.

https://helpcenter.veeam.com/docs/backup/vsphere/backup_copying_process.html?ver=110

From my knowledge it’s the other way around: it’s not easy to have it copy the full chain with all the history… Here we would need some folder operations...

 

That’s what I was thinking. That if I take a new active full on the source job and then a new active full on the copyjob, any pending restore points that have not been copied over will just stay locally and not get copied over.

 

@marcofabbri  I am holding off on the folder rename at the moment. I was talking to my CTO about all of this and he took a look at our cloud connect server and he is noticing some network bandwidth issues that he wants to address. I am going to hold off while we explore that. It’s a great suggestion though, and I will probably utilize it if the bandwidth investigation turns up dry.

 

@Chris.Childerhose The source jobs are going to a NAS or a SAN, and the BCJ’s are going offsite to a datacenter. I may be mis-understanding what you are asking. Does that seem like the correct answer to your question?

 

@JMeixner call me crazy, but I really want to get to mess around with Tape backups one day. I have no idea why...I just want to try it out. What are the write speeds like? Do they tend to take longer?


Regarding the original question @bp4JC was asking: doesn’t a backup copy job always only copy the latest backup state in the very first run and this will thus always be an active full? A single new VBK is produced.

https://helpcenter.veeam.com/docs/backup/vsphere/backup_copying_process.html?ver=110

From my knowledge it’s the other way around: it’s not easy to have it copy the full chain with all the history… Here we would need some folder operations...

 

That’s what I was thinking. That if I take a new active full on the source job and then a new active full on the copyjob, any pending restore points that have not been copied over will just stay locally and not get copied over.

 

@marcofabbri  I am holding off on the folder rename at the moment. I was talking to my CTO about all of this and he took a look at our cloud connect server and he is noticing some network bandwidth issues that he wants to address. I am going to hold off while we explore that. It’s a great suggestion though, and I will probably utilize it if the bandwidth investigation turns up dry.

 

@Chris.Childerhose The source jobs are going to a NAS or a SAN, and the BCJ’s are going offsite to a datacenter. I may be mis-understanding what you are asking. Does that seem like the correct answer to your question?

 

@JMeixner call me crazy, but I really want to get to mess around with Tape backups one day. I have no idea why...I just want to try it out. What are the write speeds like? Do they tend to take longer?

Yeah that answers my question.  I think if you do the active full that should solve the issue as noted by others. :smiley:


Regarding the original question @bp4JC was asking: doesn’t a backup copy job always only copy the latest backup state in the very first run and this will thus always be an active full? A single new VBK is produced.

https://helpcenter.veeam.com/docs/backup/vsphere/backup_copying_process.html?ver=110

From my knowledge it’s the other way around: it’s not easy to have it copy the full chain with all the history… Here we would need some folder operations...

 

That’s what I was thinking. That if I take a new active full on the source job and then a new active full on the copyjob, any pending restore points that have not been copied over will just stay locally and not get copied over.

 

@marcofabbri  I am holding off on the folder rename at the moment. I was talking to my CTO about all of this and he took a look at our cloud connect server and he is noticing some network bandwidth issues that he wants to address. I am going to hold off while we explore that. It’s a great suggestion though, and I will probably utilize it if the bandwidth investigation turns up dry.

 

@Chris.Childerhose The source jobs are going to a NAS or a SAN, and the BCJ’s are going offsite to a datacenter. I may be mis-understanding what you are asking. Does that seem like the correct answer to your question?

 

@JMeixner call me crazy, but I really want to get to mess around with Tape backups one day. I have no idea why...I just want to try it out. What are the write speeds like? Do they tend to take longer?

Yeah that answers my question.  I think if you do the active full that should solve the issue as noted by others. :smiley:

Perfect. I’m glad I was reading that right. I am getting the impression that I was looking at this correctly. If I start a new backup chain, the next copy run should only copy the full and any subsequent vib’s from the new backup chain and ignore the restore points from the old chain that have not been copied over. That still begs the question though: if I don’t utilize @marcofabbrisuggestion and rename the old source folder...would things still happen that way? His suggestion really has me thinking...at the very least, it is a nice fail safe.


Regarding the original question @bp4JC was asking: doesn’t a backup copy job always only copy the latest backup state in the very first run and this will thus always be an active full? A single new VBK is produced.

https://helpcenter.veeam.com/docs/backup/vsphere/backup_copying_process.html?ver=110

From my knowledge it’s the other way around: it’s not easy to have it copy the full chain with all the history… Here we would need some folder operations...

 

That’s what I was thinking. That if I take a new active full on the source job and then a new active full on the copyjob, any pending restore points that have not been copied over will just stay locally and not get copied over.

 

@marcofabbri  I am holding off on the folder rename at the moment. I was talking to my CTO about all of this and he took a look at our cloud connect server and he is noticing some network bandwidth issues that he wants to address. I am going to hold off while we explore that. It’s a great suggestion though, and I will probably utilize it if the bandwidth investigation turns up dry.

 

@Chris.Childerhose The source jobs are going to a NAS or a SAN, and the BCJ’s are going offsite to a datacenter. I may be mis-understanding what you are asking. Does that seem like the correct answer to your question?

 

@JMeixner call me crazy, but I really want to get to mess around with Tape backups one day. I have no idea why...I just want to try it out. What are the write speeds like? Do they tend to take longer?

Yeah that answers my question.  I think if you do the active full that should solve the issue as noted by others. :smiley:

Perfect. I’m glad I was reading that right. I am getting the impression that I was looking at this correctly. If I start a new backup chain, the next copy run should only copy the full and any subsequent vib’s from the new backup chain and ignore the restore points from the old chain that have not been copied over. That still begs the question though: if I don’t utilize @marcofabbrisuggestion and rename the old source folder...would things still happen that way? His suggestion really has me thinking...at the very least, it is a nice fail safe.

I guess the test would be to do it and then if you see anything abnormal cancel the BCJ and go the folder rename route instead.


And for your question regarding tape.

Veeam supports LTO only.

Speed depends on the used LTO generation. LTO-6 has a speed of 150MB/sec, LTO-9 has a speed of 400MB/sec. And this per tape drive.

 

And your primary storage has to be fast enough to read the data at this speed to utilize several drives.


And for your question regarding tape.

Veeam supports LTO only.

Speed depends on the used LTO generation. LTO-6 has a speed of 150MB/sec, LTO-9 has a speed of 400MB/sec. And this per tape drive.

 

And your primary storage has to be fast enough to read the data at this speed to utilize several drives.

What kind of hardware specs/resources do you typically implement when you are setting tape backup infrastructure?


For larger customers I use IBM TS4500 tape libraries with several tape drives. It consists of whole rack sized frames and is extendable to 14 rack sized modules with more than 100 drives and several thousand tape slots. (have to lookup if the 14 modules are still correct nowadays… but you have some serous trouble to get 14 rackspaces in a row in most datacenters...)

But I did not have a full equipped TS4500 in a Veeam environment up to now. Had some in Spectrum Protect environments though.

Smaller customers get a smaller IBM library like a TS4300 (this is fine because you can expand it with several stackable modules) or a Quantum library. The Quantum libs are very good, too.

There are some more manufacturer (HP, EMC..), but I didn’t use them in my environments. So, I cannot tell anything about them….

 

You said that you want to test tape… then either a single drive or a very small lib like a HP or IBM Autoloader would probably a good device for you. Perhaps you can get a used one to keep the costs down…

And be aware, all these devices are using fibre channel connections (except the single drive which a built into your server).


Hello, I have question about Backup Copy Job. How Veeam process data when:

1.Backup Job Daily Increment with Saturday synthetic full
2. Start Backup Copy Job Periodic - 7 days - Veeam always create the most recently restore point and create forever forward incremental chain on destination repository.

How it’s work ? Veeam will Merge increment backup in source repository from 7 days and transfer to destination repository ?
Helpcenter don’t describe this case.


For a periodic backup copy job, the type of the source backup job doesn‘t matter.

If you choose 7 Days for the periodic setting, veeam will copy each 7 days the most recent restore point to the backup copy target. Only incremental blocks will be copied. It doesn‘t depend on a full or incremental backup in the source job.

 


Comment