Way to detect if Fast CLone for ReFS is enabled

[ian0x0r]

Hi there,

Is there a registry key set somewhere to show that a ReFS repository in server 2016 has been enabled for fast clone? I know a message pops up if you are adding a repository that is not fast clone capable. Just wondered how this is tracked.

Thanks,

Ian

[tdewin]

Do you need just to detect if the repo is detected as ReFS?
check this : veeam-backup-replication-f2/upgrade-to- ... ml#p217323

[ian0x0r]

Thanks Timothy,

That's a useful tip. Does that guarantee though that fast clone feature will be used?

Thanks,

Ian

[tdewin]

If ReFS 3/Windows 2016 is detected, fast clone should be used automatically.

[SBarrett847]

I feel this needs to be Clearer in the GUI - I have Jobs seeded from customer sites that don't take advantage of Cloning until they are compacted by Veeam in the new Repo

I find it very difficult to actually get the compact to run, and also very difficult to quickly tell if the Fast Cloning is then enabled.

I have other Jobs that report [Partial fast clone] when merging which makes no sense - I am constantly babysitting/ manually re-running these jobs from new customers until the point at which Fast Cloning kicks in and I can then set the GFS up for the customer.

It is time consuming for me and not clear what Veeam is doing from the GUI. It is surprising that the GUI is so poor for something that is very much a Major Feature in 9.5

[rendest]

We are seeing several more conditions in which fastclone isn't being used either, so maybe some clear notifications stating why could be helpful.

One occasion was when a repo is drained and formatted to be used as a ReFS repo (but not removed from the Veeam repository inventory), the align block checkbox is never checked, and fastclone is never used.
Another occasion was when data was migrated from another lun with a different block size, and fastclone couldn't be used since blocksize was different (this was a reverse incremental job, hence a manual active full backup was required)

In both occasions everything seemed ok, until looking through the logs and seeing Veeam wasn't happy with the situation.

[Gostev]

It's a very simple rule: both the backup repository and the backup files in the repository must be created by Veeam 9.5 for fast clone to work.

[SBarrett847]

That is understood, however making sure both the backup repository and the backup files in the repository are created by Veeam 9.5, does not guarantee that fast clone is going to work. The problem being highlighted is that the GUI is not clear that this major Feature of 9.5 is not operating for the Job.

[Gostev]

making sure both the backup repository and the backup files in the repository are created by Veeam 9.5

It does, actually... or at least I am not aware of any scenario where it does not? For example, all scenarios you have listed above do not meet either of these requirements.

GUI highlights if fast clone is being used with [fast clone] tag next to each supported operation.

[dellock6]

Not sure which additional confirmationyou may need, in the logs maybe? Unless there's an inconsistency here, logs and UI would show you the exact same information, that is either fast clone is used, or not. I've already experienced a couple of scenarios where fast clone was not used, and as Anton said, they both showed that not all the conditions were met.

For example, once we had to reformat a volume originally created with 4k clustes, with 64k. After we moved back the existing chains into the volume, the first weekly synthetic full actually failed to leverage fast clone. That was totally expected, since by moving the files with regular file explorer copy/paste operations, we actually reset any alignment of the custers. That synthetic full got created as a ful blown file, and only after another week we experienced the fast clone on another synthetic full creation. At first sight, you may have said that all the files used in the first synthetic had been created by VBR 9.5 , but in reality they have been "created" by windows explorer. Only after a week all the conditions had been met. (also because the file were previously aligned at 4k, so the alignment had to be re-done for 64k).

[rendest]

Thats exactly what we had, only we used reverse incremental, and fastclone is never used until a manual active full.

[ian0x0r]

Going back to my original point, other than not receiving a popup stating "This volume is NOT fast clone capable" or words to that effect when you first create the repository there is not anything to state that the backup repository is fast clone capable unless you already know this to be true. This could be used a decision for backup placement by a backup admin.

[btmaus]

I've moved a couple of backup jobs onto a new ReFS repository. One job, I deleted all the restore points and started it again from scratch, and it is showing [fast clone] when doing a merge at the end of the job, however I don't see this on the others that I moved over.

What do I need to do to get the others to use fast clone, I cannot delete the restore points on these jobs?

[tdewin]

You need to run an active full on the job to use ReFS functionality. This is because the blocks need to be aligned in the backup files, which is not the case by default with the backups that you have copied from NTFS for example

[btmaus]

OK thank you, I'll go ahead and that.

[btmaus]

OK so for the backup jobs that I ran Active Full on, I see fast clone now.

I setup a backup copy job that has done two weekly copies, however, I am not seeing fast clone on this? Repository A is 2016 with ReFS and contains the backup files (which are created by Veeam 9.5 on ReFS 3.1), and Repository B is also 2016 with ReFS and is the target for the backup copy jobs.

What am I missing?

[Gostev]

Again, there could only be two reasons: either Repository B itself, or some of the backup files participating in the synthetic full operation were not created by 9.5.

[btmaus]

When should I see the [fast clone] on the Backup Copy job? It's now up to keeping 4 weeklies (which is what it is set too)?

Also, I don't see any space savings on these, they all consume the full amount. Is this correct?

[Gostev]

Starting from the second weekly at the latest, so it is definitely not working for you.

[btmaus]

I have another repository in a different location, that was setup from new with 9.5 and 2016 with ReFS, it's now got 4 weeklies and a monthly, I don't see any [fast clone] or space savings either.

[Gostev]

Unless you are using active fulls with your Backup Copy jobs - I have no idea what could be the issue here, so let our support review the debug log files and tell you.

[btmaus]

I have the option "Read the entire restore point from source backup instead of synthesizing it from increments" checked ... is this what I am not seeing space savings?

Not seeing [fast clone] though, so have opened a support ticket. #02090861

[Gostev]

Correct, this is the reason.

[deduplicat3d]

Starting from the second weekly at the latest, so it is definitely not working for you.

Why isn't it the first weekly? Does that mean on the backup copy job you need at least 2x the space of the full backup size? What if you have weeklys and monthlys?

[Michael.Szabo]

I've been struggling with this too. Why not have in the logs in the GUI a note showing the reason for fast clone not being used? I'm sure the checks are in the logic so it wouldn't be very hard to add in at all. It could also point to a KB article listing the resolution for the particular issue encountered. I'm sure it would result in less questions to the forums and less support jobs.

[HannesK]

Hello,
and welcome to the forums. Showing more messages in the UI creates more questions

There is a quite detailed article in the user guide about requirements and limitations https://helpcenter.veeam.com/docs/backu ... ml?ver=100

Best regards,
Hannes

[NightBird]

Veeam Backup & Replication does not use Fast Clone for backup repositories configured with Veeam Backup & Replication 9.5 Update 3a or an earlier version. After upgrade, such backup repositories will work as backup repositories without Fast Clone support. To leverage Fast Clone, you must remove such backup repositories from the backup infrastructure and add them once again.

Is 9.5U 3a not a typo error ? Fast clone exist since 9.5 GA isn’t it ?

[Gostev]

Yes, fast clone existed since 9.5 GA. This seems to be talking about some unrelated repository configuration upgrade issue though.

[NightBird]

I don't really understand the statement here, if we are on <= 9.5U3a and we upgrade to v10 we can have problem on repositories side (fast clone not working anymore) ?

[Gostev]

I also don't understand it, and not aware of any issues in these regards. Nevertheless, if you do run into the issue of fast clone not working after upgrade to v10, it seems that solving it will be super easy by simply re-creating the repository object in Veeam configuration.