Wasabi recently released their Wasabi Cloud NAS offering and you may wonder, like some of the SEs I work with, if Veeam can protect its shares.

The answer is: YES, of course!

If that is all you need to know then you can stop reading, else keep scrolling down.

Introduction

Wasabi Cloud NAS is presented as the “Bottomless NAS file storage”.

It installs as a service on a windows server and offers a nice and simple UI allowing you to configure your replication and offload policies.

Based on these policies, the service will only keep small stub files on local disk. It is 100% transparent to the end user, extremely simple to use and with zero egress/ingress fees from Wasabi, makes for an attractive/interesting NAS solution.

How can we protect it? That is what you are about to find out.

In this post we will explore some basic backup and restore operations, list some caveats around offline extended file attribute, discuss what happens when you leverage Wasabi Cloud NAS’s file versioning and Compliance Mode.

Let’s dive in!

Lab Setup

I used the default install options which creates a “Wasabi Cloud NAS” folder that I then exposed as a regular SMB share.

From a high-level, Wasabi Cloud NAS will replicate your data to your wasabi bucket of choice, allow you to reclaim (i.e. offload) your files by leaving just stubs and retrieve (i.e. rehydrate/download) them as desired.

To better understand Wasabi Cloud NAS’s behavior during Veeam NAS backup, I chose to replicate files every second.

I also wanted to understand the behavior when running Veeam NAS backup. I was especially eager to learn if Wasabi would re-hydrate (download) every single file on Veeam NAS backup incremental runs, therefore I chose an aggressive reclaim policy.

In terms of global settings, there is a “enable progressive retrieval” which when unchecked, only streams requested portion of a file.

In the advanced settings, I bumped my thread count to 16. The other interesting “advanced setting” is “Show reclaimed file as offline”: Essentially, Wasabi will stamp the stub file with the “offline” extended attribute.

Note that this setting can be problematic for Wasabi Cloud NAS replication after a Veeam restore operation. We will come back to this later but just trust me for now and let’s uncheck that option.

Creating and running the Veeam NAS backup job

The lab is setup, all the files have been stubbed out, we are ready to backup.

We won’t show the NAS backup job setup as this is well documented.

Note also that changing ACL handling did not yield different results than those listed thereafter.

Initial full backup

Because of the settings I chose, note that all data is streamed down and never stays on the Wasabi Cloud NAS’s local disk.

Occasionally some of the files may have to be fully downloaded but they are reclaimed rather quickly.

Incremental run – no file modified

Next, I wanted to validate that the stubs would be enough for Veeam to compute the source share tree CRC (Change File Tracking).

Indeed, no data was streamed down, and the increment ran fast.

Increment run – 2 files modified

Below you can observe the Wasabi sequence of events when modifying a file.

As expected, only the 2 modified files were streamed down during that incremental run.

I only observed a short network utilization burst for the stream down of the 2 files needing backup.

Restoring the entire share

For test #1, I modified only 1 file but chose to restore the entire share “with overwrite” to observe behavior on the Wasabi side of things.

It seems that Wasabi is very efficient at detecting when overwritten files have the same content.

I did observe a lot of “restore/reclaim” operations in the Wasabi logs but I only saw “true” data transfer for that 1 modified file. It seems** that most of these operations were related to stub metadata. (**I would respectfully defer to a Wasabi expert for confirmation).

For test #2, I have simply deleted the entire share’s content. In my case deletion was almost instantaneous since all files were fully offloaded and only stubs remained on disk.

Upon restore, as expected with my Wasabi Cloud NAS policies, as soon as a file was restored, it started offloading right away without the need to wait for the full share restore to complete.

It is important to note that a full restore will require some local disk space (up to the source data size).

Restoring when “Show reclaimed file as offline” was selected

In this test, the original backup was performed with the “Show reclaimed file as offline” option checked which adds the offline extended attribute (O) to each stubbed-out file.

This may seem obvious, but Veeam NAS backs up the files with ALL of their attributes (including the Offline extended attributes).

I deleted all files from the source share and performed a full restore. You can see on the screen shot below that most, if not all, files where excluded from replication.

The explanation can be found in the Wasabi Cloud NAS documentation where you can read:

Note that overwriting existing files won’t break replication, only restoring new files (either the data is missing from the source share or you are restoring a file with the “restore>keep” option).

This could easily be fixed with a powershell one-liner to set Attributes back to Normal.

Get-ChildItem $mypath -recurse -force | foreach {$_.Attributes = 'Normal'}

Note: A more complex script may be required should you need to conserve other attributes besides the offline flag.

What happens on restores if file versioning is enabled?

Enabling file versioning is but a click away using Wasabi Cloud NAS UI. As you have probably guessed, it uses bucket versioning.

In the example below, I have modified a file multiple times to create multiple versions.

Let’s see what happens when I restore over it.

Wasabi bucket versioning creates a new version of that file enabling additional flexibility to recover your data.

Enabling compliance mode and restores

Enabling compliance mode turns your NAS into a WORM device. This means that any file you want to modify must be saved as a new file.

From a restore perspective, and to the risk of stating the obvious, this simply means that overwrite restores won’t work.

You could restore files with the “keep” option but beware that the restored file will be WORMED and will consume more storage on your Wasabi bucket.

A better option maybe to restore to an alternate location.

Conclusion

In this post I covered basic backup and restore operations and shed light on some the caveats pertaining to offline extended attribute option, Wasabi versioning and compliance.

If you have made it this far, I thank you very much for reading and hope this will provide some guidance.