[Split] BackupCopyMirrorAll does not set retention flags

[DaStivi]

I'm currently dealing with a very similar scenario: a source VM with approximately 80 TB of data and multiple yearly, monthly, and weekly retention points. The backup chain itself is around 1 PB in logical size, although it only consumes about 150 TB of physical storage.

Unfortunately, the repository move/copy operation failed every time because the Veeam processes on the target hardened repository linux appliance ran out of memory.

As a workaround, I switched to using the registry key that enables migration through a Backup Copy Job. So far, this approach has been working, although I've encountered several other challenges along the way, such as the target storage running out of storage space.

One issue I've noticed with the Backup Copy Job, however, is that the retention flags are completely incorrect after the migration.

The monthly and yearly retention points (VBKs) that are marked on the source repository do not appear correctly on the target repository. For example, the oldest monthly restore points are shown only as regular VIBs on the target side and no longer have the expected retention flags assigned to them.

Has anyone else observed the same behavior during a repository migration using a Backup Copy Job?

I've also a case open on this issues: 08139094

btw. incompletely copied items are not immuteable yet... i had this issue many times, as the out-of-memory error... though that filled my physical storage, as it didn't get deleted on block level at the storage (and it was in additional storage snapshots too!)

with the first test of the "backup copy job" i ended up with only one VBK, this was also immutable then, i couldn't delete of course from the UI... again fillled my storage and the chain where never copied completely, even though, when you right-click the backup copy job and click sync-now, then you'll get the prompt where you could choose "all" but that doesn't change anything !?

anyway for the "FULL-copy" with the regkey you'll need a new copy job hence i had this full backup i couldn't delete... i just had to enable shell and root access on the VBR hardened linux repo to remove the immutable flag manually and delete the file manually then!

[david.domask]

Hi DaStivi,

I've split your question from the previous topic as this is a bit different than the "How To" questions on the previous topic.

BackupCopyMirrorAll simply changes the backup copy job's logic to iterate over all existing points in the source job, it is not the same as what the Move operation does. That is to say, normally Backup Copy jobs act exclusively on the newest restore point, reads data from that restore point and writes it to a new chain. Backup Copy jobs are _not_ simply copying files, but instead creating a new and independent backup chain with the same backup data.

Since it's a new job with its own independent chain & retention, the retention will follow the configured retention on the new Backup Copy job.

I advise continue with Support on the OOM issue for Move Backup, as it sounds like what you're looking for.