Change backup copy mode for the existing job in v10?

[foggy]

The reasons are mentioned in this thread above. We are tracking the demand for this functionality, however, I cannot comment on any plans regarding it at the moment.

[FrancWest]

In the release notes of v10a (https://www.veeam.com/kb3228), I read this:

Backup copy jobs in the immediate mode: added support for replication from backups created from backup copy jobs; removed re-transfers of already copied backups for backup chains with transform to rollback option enabled.

What does this exactly mean? Are we able to switch to immediate mode while using the existing backup copy chains?

[foggy]

Hi Franc, no, this doesn't speak about switching. It basically speaks for itself - you can now create replication jobs from backups created by backup copy jobs as a source, and in addition v10a addresses some transfer overhead for the cases where transform to rollback option is used in source backup chain.

[FrancWest]

ah, ok, didn’t now that was a limitation before 10a.

It isn’t mentioned here as a gotcha:
https://helpcenter.veeam.com/docs/backu ... ml?ver=100

[ChrisGundry]

I would like to add my +1 for this issue.

We have multiple copy jobs with retention going back several years, also with shorter retention of only 7-14 days on some jobs. But in almost all cases, it would be better for us to use the new 'immediate copy' jobs so that our secondary locations are more quickly updated and are kept up to date if a new point is craeted. At the moment it is possible for our jobs to get out of sync with the source job/points such that when the job runs it is not copying the latest point, but the day/point before. The job is then 'out of sync' until someone notices and re-runs the job manually. The immediate copy method would resolve this.

However, we cannot use it, because we don't have the space to re-create all of our jobs and all of the data from scratch. In addition, we can't delete all of our old recovery points going back several years and start from scratch. If Veeam cannot 'convert' the recovery points/chains, then perhaps they can re-look at a feature I have requested several times over the last x years...? The feature being to have old jobs/points 'age out' based on a pre-defined policy. Basically you say "there won't be any new points coming in for this job, the new job is x. Overall, keep 1 year worth of points.". Then as the new points come in, the old points are deleted and both jobs are 'managed' for you and the old points will eventually all be deleted. This means no more space usage (except for inter-job dedupe losses) and no manual point deletion required.

[Gostev]

This requires Backup Copy job to have time-based retention (same with GFS retention in primary jobs that was added in v10), as opposed to restore point count based. We're making this change to Backup Copy jobs in v11. Thanks!

[FrancWest]

As described above you cannot switch from periodic to immediate mode due to datafile differences between the two job types. That's fine, but why can't you even switch from periodic to immediate mode by cloning an existing periodic copy job to a new job and change that one to immediate mode? Since there's no backup datafile present for this new cloned job, the argument about the different file structure isn't valid. Now you have to recreate the job completely with all it's settings.

[Gostev]

These switches in either direction were determined to have too many opportunities for data corruptions bugs. So, it would take too much resources and time to make them possible. On the other hand, it's not something we expect any given customer to keep doing periodically (switching copy modes back and forth) - more of a once in a life time operation.

[FrancWest]

Ok, but why is it not possible when cloning an existing job? Datacorruption is not valid here I think, since no backups files are being created yet for the cloned job. It would make migration from periodic to immediate much less of a hassle when you have many copy jobs. Clone job, switch newly created job to immediate mode and optional change the target repository and done .

[Gostev]

It's the scenario that needs to be tested, and may uncover plenty issues around business logic that are not immediately obvious. I am yet to see even a simplest change or feature that does not result in a bunch of bugs, but Backup Copy jobs is a particularly sensitive area.

Again, the main consideration for me here is investing R&D and QC resources into a one-time migration scenario... meaning spending all these R&D resources for a functionality that does not add long-term, on-going value to the product. Making it very hard to justify with hundreds of other pending features which are all unlike that.

[FrancWest]

ok, I understand completely, thanks! For end-users it's hard to comprehend that a even the simplest change would take much more effort on you side.

[eisback]

Hi, after we upgraded from 9.5 to 10.0 we changed the copy mode for VMware Backup Copy from Periodic to Immediate copy ... is their a way to avoid that he starts with a new full backup? I created the the job with the same name but then he created a new folder with the value 1 at the end ... thanks! Nico

[Egor Yakovlev]

Hi Nico,

I have merged your post into existing thread. Please check answers above.
As for the folder naming, it is 100% expected as new job will always get new GUID assigned, even if name matches old one, and will be considered totally independent from original.

/Thanks!

[foggy]

You could keep the folder name if it's somehow critical but you are not able to re-use the existing backups - you will have to start from scratch anyway.

[lowlander]

Hi, we noticed the following in the backup properties of a immediate mode BCJ : The object are listed in the objects pane, however looking to the file pane overview all corresponding files are listed starting with a red cross, greyed-out and in italics. Per line item we have the option to copy path, Forget and remove from disk.

When the BCJ runs, new files are listed and no jobs are failing.

Is this visibility of files within the Backup properties view expected and related to the immediate mode of the BCJ ?

thanks !

[Egor Yakovlev]

If under Backup Properties you see a red cross with italic text(as well as options to Forget and Remove) - that means backup files that we put to destination target are no longer there(someone deleted\moved backup files outside our product - we expect them to be there, but apparently they are not).
You should investigate who got rid of the files.

/Thanks!

[foggy]

Or just use the 'Forget' functionality to clean up the database, if that's not a big deal for you.

[Zew]

Veeam finally gives me the BCJ style I've always wanted, but screws me by greying out the option and forcing me to rebuild/re-seed my entire offsite repo.

I understand the technical complications have been discussed, which I'm thankful for. As others have mentioned some form of cleanup in which Veeam could use the dataset that's already there, to migrate old BCJs into new BCJs would be very beneficial. In a way that each Job/Chain can be migrated in a way that is viable to the storage media being used and the amount of space that was allocated to it from previous storage requirements. This way , I believe, can prevent two main heart aches;

1) Having to re-seed from production side.
2) Storage Constraints

Of course, if Veeam really wanted to impress the technical crowd, pull off the above while actual retaining GFS restore points, and AAP information on specific jobs. If I could have the above without these bonuses I could at least migrate a fair good amount of jobs without sacrificing too much.

Thanks guys.

[mriesenbeck]

I wholeheartedly support this message. In order to migrate current customers we would need to reseed, meaning many consultancy hours, hours driving around disks, double storage, where storage is already hard-limited in most case. So I have decided to keep using the periodic mode, also since Immedate mode has one big disadvantage for our use case, since you can no longer select individual VM's from the infrastructure. I tend to keep the backup jobs as individual as possible to have the biggest performance and flexibility and calculate plenty of storage for the local backups, to prevent the storage from filling up due to less dedup, but every now and then there is a situation when multiple VM's do end up in a single backup job, yet I only want to Backup Copy maybe only one or two out of them. Of course I could an Exclusion to realize that, but it would be way more convenient to simple be able to still select items from the infrastructure. Also, I find that the statistics of the Immediate mode are much limited to that in the periodic mode. But all things that aren't that much of a biggy, I know these things are by design, I understand that, and can live with that, but having to reseed to change modes is really a no go.

Don't misunderstand me, I appreciate how Veeam keeps on adding new cool features, but migrating from an older feature to a new one, could get more attention. Same issue I have with the Immutable Repositories and customers who already use non-immutable. It would have been very helpful if there would have been an option or tool built, or even powershell, to move these existing backups/backup copies over to the new immutable ones. Obviously initially the advantages of XFS would (partially) stay unused, but eventually they would have. What I needed to do now is to manually copy over my existing backup copies from non-immutable to immutable, remap and it works again, but it's a lot of effort, since I have to temporarily re-enable ssh (to use filetransfer/ssh), start a copy job from an ssh/sftp client and keep track on when it finishes, rescan, remap and retest, while I feel this could have been build into the product, since Veeam is connected to all repositories and has all the permissions to do so automatically.

Cheers,

Michael

[foggy]

Hi Michael, thanks a lot for the valuable feedback, your voice is heard.

[Dima P.]

Hello folks,

Thank you for sharing your thoughts! Need some intel on your current backup copy configuration. Can you please tell if backup files created by your periodic backup copy job are stored in per-VM fashion or as a single backup file (this option is controlled in the target repository properties)? How many restore points you have in the periodic backup copy job? Thank you in advance!

[Zew]

Hey Dima,

In my case I don't use Veeam Enterprise licensing which from the UI and checking my repo's is required for Per-VM backup files. (Odd, I don't remember this constraint in the past).

It usually depends on the job, but can be any where from 2 retention points (with keep certain full backups for archival purposes), to jobs with 4-7 retention points with no full backup archival.

Not sure how this helps, but hope it helps.

[bsmith-mmo]

+1 for converting Periodic BCJ's to Immediate without reseeding.

[Dima P.]

Hello folks,

Thanks for the feedback! Is it ok to allow mapping but to the latest restore point converted to the full backup (i.e. synthesize full backup from latest incremental restore point and then map it to a new backup copy)?