Moving backups to Linux Hardened Repository

[BuffaloBucks]

I just finished setting up our first Linux Hardened Repository on Ubuntu 22.04 LTS with immutability. I formatted the disk with XFS just like the directions said. I moved the first couple backups over there today from a Windows repository formatted with ReFS and it doesn't appear to be utilizing fast clone like I expected so the storage space used is way more than it should be and if it does this for all of them I won't be able to move all the backups.

For the first job I utilized "Move Backup" on the entire job and it reported: "Succeeded Fast clone was used for 20 of 28 backups" for the 2 VMs in that job.

For the next one I wanted to take all the VMs/Backups in two jobs and move them to a brand new job with a new name. To do this I created a new job and set the repository to the new Linux hardened repository. I moved a large VM that had 1.29 TB of backups as shown as the total size of all the backups, not the ReFS reduced amount. The "Move Backup" job reported "Succeeded 29 backups (1.2 TB) moved at 860 MB/s 0:23:59" The full 1.2 TB is showing up as used space which is ok, but the repository is also showing that the free amount was also reduced by 1.2 TB which it should not have been that much if the synthetic full backups were being recognized properly in a reduced size as they were on the Windows ReFS repository.

How do I get this resolved? What do I need to do to get fast clone working on the new Linux repository so that I don't run out of space?

[Gostev]

Hi, we're unable to troubleshoot technical issues over forum posts. Please open a support case and our support engineers will get this resolved for you. Thank you and Merry Christmas!

[BuffaloBucks]

Thanks Gostev. I opened case # 07065750 but am questioning the responses.

The first response said that I am running Ubuntu 22.04.3 LTS and that it is unsupported and that I can only run Ubuntu 18.04 LTS, 20.04 LTS, or 22.04 LTS and need to downgrade to use fast clone. Are all versions of 22.04.x supported or must you only use 22.04?

I responded asking to confirm this and also shared the following additional information I found here: https://helpcenter.veeam.com/docs/backu ... =120#linux

Limitations
After you have moved backup chains to a Linux backup repository with Fast Clone support, you must create active full backups for these chains to activate Fast Clone. You can also schedule the backup file compact operation instead of active full backup.

I asked if this was the issue I was experiencing.

The second response said that I just need to schedule a compact of the full backup file to activate fast clone. Well, that isn't an option as I received the following error when attempting to set it on the job: "Immutable backups feature requires the usage of forward incremental backup mode with periodic fulls"

At this point I am not sure if any of the information I am receiving is accurate anymore. I came to the following conclusions and would like to know if option 2 is correct so that I can move forward.

I have come up with only two options the way I understand it so far.

1.) Move all my current backups to the new Immutable repository and run Active Fulls on all of them.
a.) I do not have enough storage space available on the new repository to move all my current backups and store a new active full in addition after running a new active full on all of
them so this will not work.
2.) Disable current jobs one at a time and create new jobs pointing to the NEW Immutable storage.
a.) New backups get created on the Immutable repository with Fast Clone working.
b.) My older backups will sit on the old repositories until I delete them but the exist for recovery if needed in the meantime.

[Gostev]

There's certainly no requirement to run vanilla version of Ubuntu 22.04 specifically.

Based on the responses you're getting, I suggest you request your support case to be escalated to a more experienced support engineer (you can request your engineer directly or use Talk to a Manager functionality of the customer portal). This should have never been about troubleshooting of basic fast cloning requirements if what you say in the first post is true and fast cloning already works at least for some VMs. Clearly this would not be possible if your repository was missing something in that department?

[BuffaloBucks]

A new engineer picked up the case today and was able to answer one of my questions.

In addition, I did some more testing today and found that I had one of my backup jobs on the old repository that never had Synthetic fulls setup. The VM that I moved that was in question was from that backup job. Because of that it took that full backup to activate Fast Clone. I moved some other VMs from another backup job on the old repository that had synthetic fulls enabled and they transferred over properly and ran a synthetic full and they worked properly with fast clone without taking up any extra space. I enabled synthetic fulls on the backup job that didn’t have them enabled yet so tonight after the job for them runs, they should be good to move as well.

Thank you for assistance.