Moving backups to a new repo, copied recovery points marked "Keep Forever".

[cmangiarelli]

As per another post, I am in the process of moving my Nakivo backups from older Data Domains to Synology NAS arrays. The process I plan to use is:

1. Install Nakivo Transporter on the Synology NAS.
2. Register Synology Transporter with Director.
3. Create a new "local folder" repo on the Synology transporter.
4. Configure a backup copy job to mirror the existing DD repo to the Synology Repo.
5. Delete the backup copy job, as you can't edit the destination target of the backup job if the copy job exists, but tell it to "Keep existing backups".
6. Edit the VM backup job to point the VMs to their new location (this is a pain when you have a lot of VMs, wish there was an easier way to do this or have Nakivo automatically discover existing backups).
7. Run the VM backup job to start storing new backups on the Synology repo.

I ran a test and this worked fine, except all of the old recovery points that were copied by the backup copy job in step #4 had their retention set to "Keep Forever". I'm guessing this occurred when I deleted the copy job but told it to keep the backups. I'm assuming this is operating as intended? With 200 VMs and each having 9-11 recovery points, I can't manually reset the retention on 2,200 recovery points to fix this. I understand why it might have gotten changed when the backup copy job was deleted, but the Director wouldn't let me re-point the backup job until those copied backups were no longer referenced by another job object. I can use the "delete backups in bulk" to manually enact my original retention policy, but that will take 3 months to run the cycle. Any ideas?

Edited September 22, 2023 by cmangiarelli

[The Official Moderator]

30 minutes ago, cmangiarelli said:

As per another post, I am in the process of moving my Nakivo backups from older Data Domains to Synology NAS arrays. The process I plan to use is:

1. Install Nakivo Transporter on the Synology NAS.
2. Register Synology Transporter with Director.
3. Create a new "local folder" repo on the Synology transporter.
4. Configure a backup copy job to mirror the existing DD repo to the Synology Repo.
5. Delete the backup copy job, as you can't edit the destination target of the backup job if the copy job exists, but tell it to "Keep existing backups".
6. Edit the VM backup job to point the VMs to their new location (this is a pain when you have a lot of VMs, wish there was an easier way to do this or have Nakivo automatically discover existing backups).
7. Run the VM backup job to start storing new backups on the Synology repo.

I ran a test and this worked fine, except all of the old recovery points that were copied by the backup copy job in step #4 had their retention set to "Keep Forever". I'm guessing this occurred when I deleted the copy job but told it to keep the backups. I'm assuming this is operating as intended? With 200 VMs and each having 9-11 recovery points, I can't manually reset the retention on 2,200 recovery points to fix this. I understand why it might have gotten changed when the backup copy job was deleted, but the Director wouldn't let me re-point the backup job until those copied backups were no longer referenced by another job object. I can use the "delete backups in bulk" to manually enact my original retention policy, but that will take 3 months to run the cycle. Any ideas?

Hello @cmangiarelli. To address your inquiry effectively, we recommend generating and submitting a support bundle to support@nakivo.com by following the instructions outlined here: https://helpcenter.nakivo.com/display/NH/Support+Bundles By doing so, you will facilitate a thorough examination of your issue by our esteemed Technical Support team.

Your cooperation in this matter is greatly appreciated.

[The Official Moderator]

On 9/22/2023 at 9:49 PM, cmangiarelli said:

As per another post, I am in the process of moving my Nakivo backups from older Data Domains to Synology NAS arrays. The process I plan to use is:

1. Install Nakivo Transporter on the Synology NAS.
2. Register Synology Transporter with Director.
3. Create a new "local folder" repo on the Synology transporter.
4. Configure a backup copy job to mirror the existing DD repo to the Synology Repo.
5. Delete the backup copy job, as you can't edit the destination target of the backup job if the copy job exists, but tell it to "Keep existing backups".
6. Edit the VM backup job to point the VMs to their new location (this is a pain when you have a lot of VMs, wish there was an easier way to do this or have Nakivo automatically discover existing backups).
7. Run the VM backup job to start storing new backups on the Synology repo.

I ran a test and this worked fine, except all of the old recovery points that were copied by the backup copy job in step #4 had their retention set to "Keep Forever". I'm guessing this occurred when I deleted the copy job but told it to keep the backups. I'm assuming this is operating as intended? With 200 VMs and each having 9-11 recovery points, I can't manually reset the retention on 2,200 recovery points to fix this. I understand why it might have gotten changed when the backup copy job was deleted, but the Director wouldn't let me re-point the backup job until those copied backups were no longer referenced by another job object. I can use the "delete backups in bulk" to manually enact my original retention policy, but that will take 3 months to run the cycle. Any ideas?

@cmangiarelli, I can recommend using the standard way to move the backup data to another repository. Did you have a chance to use a backup copy and use the retention that works for you (https://helpcenter.nakivo.com/User-Guide/Content/Backup/Creating-Backup-Copy-Jobs/Creating-Backup-Copy-Jobs.htm)?

I am looking forward to hearing from you.

[cmangiarelli]

I figured out that if you detach the repo prior to deleting the backup copy job (in step#5 above), it will retain the original retention dates. I plan to use this same process when I move my production data over in a few weeks. If the retention dates get messed up though, I'll just use the "Delete backups in bulk" functionality once a week to clean my repo storage. The new arrays have a much larger storage capacity, so leaving a few extraneous recovery points around for a few weeks shouldn't cause any issues.

[The Official Moderator]

37 minutes ago, cmangiarelli said:

I figured out that if you detach the repo prior to deleting the backup copy job (in step#5 above), it will retain the original retention dates. I plan to use this same process when I move my production data over in a few weeks. If the retention dates get messed up though, I'll just use the "Delete backups in bulk" functionality once a week to clean my repo storage. The new arrays have a much larger storage capacity, so leaving a few extraneous recovery points around for a few weeks shouldn't cause any issues.

@cmangiarelli, your information has been received and forwarded to our 2nd Level Support Team. We will follow up with you shortly. Thank you for using NAKIVO Backup & Replication as your backup solution.

[The Official Moderator]

15 hours ago, cmangiarelli said:

I figured out that if you detach the repo prior to deleting the backup copy job (in step#5 above), it will retain the original retention dates. I plan to use this same process when I move my production data over in a few weeks. If the retention dates get messed up though, I'll just use the "Delete backups in bulk" functionality once a week to clean my repo storage. The new arrays have a much larger storage capacity, so leaving a few extraneous recovery points around for a few weeks shouldn't cause any issues.

>>I ran a test, and it worked fine, except that all the old recovery points copied by the backup copy job in step #4 had their retention set to "Keep Forever." This happened when I deleted the copy job but told it to keep the backups. Is this the intended behavior?

It all depends on the NAKIVO retention policy used to create the recovery points in the repositories. If a new retention policy is used, the recovery points on both the source and target repositories will expire.

>>With 200 VMs, each having 9-11 recovery points, manually resetting the retention on 2,200 recovery points to fix this is not feasible. I understand why it might have changed when the backup copy job was deleted, but the Director wouldn't allow me to re-point the backup job until those copied backups were no longer referenced by another job object. I can use the "delete backups in bulk" to manually enforce my original retention policy, but that will take three months to complete the cycle.

>>I discovered that detaching the repository before deleting the backup copy job (in step #5 above) will retain the original retention dates. I plan to use this process when moving my production data over in a few weeks. If the retention dates get messed up, I'll use the "Delete backups in bulk" functionality once a week to clean my repository storage. The new arrays have a much larger storage capacity, so leaving a few extraneous recovery points around for a few weeks shouldn't cause any issues.

In this case, the best option is to use the "Delete backups in bulk" functionality. Thank you so much for your attention and participation in our community. We are looking forward to hearing from you.