Prerequisites for Wasabi Cloud NAS (WCN)

Before you sign up for your free trial account, you may want to check that your system and source storage meet the following requirements.

• PC with 64-bit (x64) processor.

  The WCN client makes API calls to interact with the Wasabi Cloud. Depending on the number of sources mapped through the WCN client, the configuration of global settings, and the policies attached to the sources, the volume of API calls may increase. Poor CPU performance can adversely impact API performance.

• 64-bit Microsoft Windows 7/Server 2008 R2/Windows 8/Server 2012/Server 2012 R2/Windows 10/Server 2016/Server 2019/Windows 11/Server 2022.

  Microsoft Windows 7/Server 2008 R2 computers must run at least Service Pack 1 and have the KB976932 and the KB3033929 security updates installed.

• Minimum of 4 GB of physical RAM.

• Minimum of 60 MB of available hard disk space for installation.

  WCN maintains a database in the product installation folder to track the files it manages. The database size is directly proportional to the number of managed files. For example, if WCN manages 1 million files, the database size will be approximately 100 MB. Insufficient free space for the database will hinder WCN functionality.

• Microsoft .NET Framework 4.8 installed.

• The firewall on the computer responsible for managing inbound and outbound network traffic must not impede the transmission of data via the following TCP ports:

  • 80 - outbound rule only (for communication with object storage target over HTTP connection).

  • 443 - outbound rule only (for SaaS activation and/or communication with object storage target over HTTPS).

    The Wasabisys domain must be accessible through the network firewall, and the application should have the capability to connect to the license server and object storage endpoints. Ensure that the cloudnas.wasabisys.com domain is whitelisted, which is required to use a licensed version of WCN software.

  • 445 - outbound rule only. This is used for communication with the Server Message Block (SMB) network share target.

Source Storage Requirements

For each network share that is used as a source, you must assign an empty folder on a locally mounted volume on the WCN computer. This folder is used as a shadow copy location and contains a copy of each file on the NAS source in the form of a stub file. The shadow copy folder acts as a gateway between the NAS source and the bucket.

With data replication, there is no difference from the local volume source. However, when the WCN Space Reclaiming mechanism needs to replace the actual file on the NAS source with a stub file, it only creates the stub file in the shadow copy folder. This way, if you need to retrieve a nearline file manually, you need to perform the operation on the stub file in the shadow copy folder. The same applies to the Active Sync mechanism (unless you have configured the mechanism to automatically retrieve on the source synchronized data from other sources). When you need to synchronize the contents of the source and bucket (target), you need to perform the operation on the shadow copy folder and all restored data will appear there in the form of stub files, which you can then manually restore on the NAS source.

As stub files are actually located only in the shadow copy folder, to retrieve them on-demand, you must export the shadow copy folder as a SMB/Network File System (NFS) share on your network. Users and applications should then attempt to open a nearline file on the exported shadow copy folder in order to automatically retrieve it directly on the NAS source.

As a general rule, the capacity of the shadow copy folder must be at least 15% of the capacity of the NAS source itself.

Getting Ready

Before pairing a source and target, review the following source storage requirements. With WCN, you can add as many source-target pairs as needed. Sources can contain data prior to pairing them with their your bucket storage. The following source types are supported:

• New Technology File System (NTFS) or Resilient File System (ReFS volume), mounted on the computer running WCN as a local volume with Read & Write permissions and on which the System account is granted Full Control.

  You can use as a source the whole volume or just a folder on it. You cannot use as a source a folder whose parent folder is already paired with a bucket (i.e., is set as a source itself).

• SMB or NFS share accessible on the same network as the computer, running WCN and a dedicated account (Active Directory domain or local account on the NAS appliance), which has Full Control (on Windows) or Read & Write permissions (on Linux) over each share, which will be used as a source.

  To use network storage as a source, for each network share you must prepare an empty, control folder located on a locally mounted volume on the WCN computer. The control folder is similar to a shadow copy folder and is used only for storing stub file copies of the actual files on the network share. The shadow copy folder acts as a gateway between the NAS source and the bucket.This facilitates a retrieval of data to the network share if you enable Space Reclaiming. For details about configuring a NAS source, refer to Source Storage Requirements.

• Folder on the volume or network share (to be used as a shadow copy).

Data Protection

While WCN gains programmatic access to your data at the source and bucket levels, WCN prevents unauthorized access to your data, both when at rest and in transit.

• The WCN workflow supports applying any Windows techniques for controlling access to and protecting data at rest at the source level.

• WCN does not require maximum privileges of the credentials used to access the bucket. WCN adopts the bucket’s own mechanisms to ensure that credentials are protected and not compromised.

• The credentials to access the bucket are stored in the registry of the computer that is running WCN and are encrypted using Advanced Encryption Standard with Wasabi’s 256-bit key.

• Data in transit to cloud buckets is protected. Users benefit from secure transfer (SSL/TLS) and also rely on the bucket provider's mechanism for protecting data in transit.