WAN Accellerator rebuild question

[stevenrodenburg1]

Hello,

I had a perfectly working running Lab setup with a normal NAS backup-repo in site A and a Windows 2016 b1607, ReFS based repo in "E:\Backups" in Site B (a different city, WAN-link is 100 Mbit). The setup uses WAN Accelerators to transfer copy-jobs to site B. The Veeam Version is 10a.

It's a lab and I was messing around with that Win2016 box and broke the 8-disk storage-spaces volume hosting the E: drive so I had to re-create it from scratch (create a pool, then a volume on top of it, then format it as ReFS with 64kb and so on).
I removed the remote copy backups by removing them from the configuration to "inform" Veeam that they physically did no longer exist).

The D: drive, with a huge global cache folder on it, was not damaged by me messing around. I only mistakenly nuked the E: drive with the backup folder on it.

I disabled the always running copy-job directly after killing the E: drive.
After the re-build of the ReFS Volume, the repo which used to be on E:\Backups was back exactly as it was before. I did NOT do a rescan of the repository (I forgot).

So I re-built that E: drive and the path E:\Backups was valid again (Veeam never noticed it was gone) and re-enabled the copy-job. Did not touch it afterwards. So the job starts by itself and I just watched it finish. The source VBK is 135 GB.
The backup file in Site B ended up being 12 GB in size. I noticed it saying that for many VM's, it took a significant amount of data from the global cache (this is expected, because that survived my handywork) but also, and this is the weird part, from "the target repository", which can't happen because there was nothing there in E:\Backups to start with directly after the rebuild.

So I deleted the copy-backup from the GUI and disabled the copy-job.
With the E: drive empty once again, this time, I did do a rescan of the repository.
I then re-enabled the job and as soon as the red icon (disabled) went away, clicked on "active full" this time. This time, I only got the expected "X GB obtained from global cache" messages for each VM and no "X GB obtained from target repository" messages this time. This is how I expected it to work, because there was nothing in the target repo to obtain anything from.
However, the resulting backup file is again 12 GB.

Same is happening with a second copy-job which is still running while i'm writing this. The very first VM who's data was transferred in the copy-job was of an OS version that was not copied before since the rebuild, so even though there is plenty to fetch from the global cache from, there is most certainly nothing to fetch from the target repository from at this point. Yet, several GB where fetched from the target repo according to the job log. This can't be.

2 Questions:
- How can the VBK file in the remote repo be 12 GB while it's source VBK is 135 GB? (stored "veeam" deduped and compressed. NAS does not do dedup or compression).
- How can it "obtain X GB from the target repo" during the very first copy-job run, even though the target repo is empty? Was it because I forgot to rescan the repo after re-creating it? Did that confuse Veeam (veeam never knew the repo on E: was gone and then rebuilt).

[HannesK]

Hello,
I see that you put a lot of work in writing all the details. I hope, that I still have everything in my mind, while answering your questions.

I do not cover anything about NAS. Because the WAN accelerator is not used for NAS backup copy jobs.

12GB vs. 135GB VBK sounds much. I mean, if you never did any compact full or synthetic full, then differences are normal. But that sounds much. More like that the source is "per job chain" and you only copied one VM to the destination (which is probably not the case from what you wrote). So the easiest thing to test is whether restore (file level and instant VM recovery) still work. And then check with support, because guessing at that level of complexity in the forum is "dangerous troubleshooting".

The message might be a UI issue. Not sure, whether it's worth to investigate that corner case.

Summary: I would check whether the copied data is valid. If not, then please follow the forum guidelines and contact support

Best regards,
Hannes

[stevenrodenburg1]

Hello Hannes,

Thank you for your response. The NAS is merely the storage for the primary on-premise backups. It is fronted by a Linux NFS gateway so Veeam does not speak to the NAS directly. It's not the "NAS backup" function of the product.
Anyway, still baffled, I deleted the copy-backups and the copy-jobs and re-created the job from scratch, linking it to the same source backup-job. Then started the job and everything went as expected. Job-behaviour is normal (only fetches stuff from the global cache) and sizes are correct.
I have no Idea what happened the first time and I deleted the evidence so to speak, so a support-case is not possible. Nor is it needed anymore (it works now). Maybe Veeam BR got confused by my actions.

I don't recommend anyone spending time on this issue (which is not an issue anymore since starting over). And it's a lab environment so accidents are "happy accidents" (copyright Bob Ross

I had a customer lose their remote data once (their admin pulled 2 disks out of a running RAID5 array -> bye bye data) and re-creating the storage and the repo etc. (essentially what happened in my case) worked fine then. That was with v9.5 instead of 10a.

Oh well, guess I'll register this in my mind as a freak accident and forget about it. Thanks again for your time.