A client with a Synology NAS in the office asks you to “set up cloud backup.” It sounds like one task. It is really two, and getting them straight is the difference between a backup that saves the client and one that quietly mirrors their mistakes into the cloud. Here is how to answer that request as the IT shop running the service, not as someone following a consumer setup guide.
First, separate the two questions hiding in the request
When a client points at their Synology and says “back it up to the cloud,” they usually mean one of these, and often both without realizing they are different:
- Protect the laptops and servers, with the NAS involved as fast local storage.
- Protect the data that actually lives on the NAS shares.
Sort out which one, or both, before you configure anything. They use different mechanisms and different policies, and lumping them together is how clients end up with a gap they do not discover until a restore fails.
The NAS is a vault, not the whole strategy
For the endpoints and servers, run your normal branded service: deploy your agent to each machine, keep a local vault on the client’s NAS for fast, LAN-speed file pulls, and send an encrypted copy offsite to the cloud for the disaster case. The NAS you already manage becomes the fast-restore tier, and the cloud is the tier that survives a fire, theft, or ransomware event that reaches the office. This also puts the client’s existing NAS investment to work instead of buying separate local backup hardware.
For the offsite copy, you pick the bucket: Synology C2, Wasabi, Backblaze B2, or Amazon S3. You connect it and pay the vendor directly, with no storage markup in the middle, so the margin stays yours.
Backing up what lives on the NAS is its own job
If the client’s important files live on the NAS shares themselves, those shares need their own protection, separate from the endpoint jobs above. Two accurate routes:
- Back up the shares through an agent on a Windows or macOS machine that has them mounted, so the share contents flow into the same service and console as everything else.
- Use Synology’s own Hyper Backup to push the NAS to a cloud target on its own schedule.
Either way, treat it as a distinct policy with its own retention. Do not assume the endpoint backups cover the NAS shares, and do not assume protecting the NAS shares covers the endpoints. They are separate assets.
Say this to the client: sync is not backup
Many clients believe they are already covered because the NAS “syncs to the cloud.” Depending on the synchronization configuration, changes or deletions can propagate to the cloud destination, which may leave you without a recoverable historical version. Backup keeps point-in-time versions you can roll back to. When a client tells you they already sync, that is your cue to explain the difference, because it is usually not the protection they think it is.
Run it like the rest of your book
However each client’s storage is arranged, every endpoint and job shows up in one Backup Ops console. You catch missed jobs each morning, pull reports, and push config remotely. Server clients get SQL and Exchange jobs, full disk images, and bare-metal restore as standard, not add-on SKUs, and a server bills the same as a workstation. The NAS-equipped client is just one more account in the same view.
Prove the restore before you need it
- Test both tiers. Pull a file from the NAS local vault to confirm fast local recovery, and pull one from the cloud copy to confirm the disaster path works.
- Test a share restore. If you are protecting the NAS shares, restore one before you tell the client they are covered.
- Keep versions from before an infection. Retained point-in-time copies offsite are what let you roll a client back past the moment ransomware hit.
- Set retention deliberately. Match how long you keep versions to the client’s needs rather than paying to store data no one will restore.
Bottom line
Cloud backup for Synology, done right, is not about turning the NAS into a backup gadget. It is placing the NAS as the local vault inside a branded service, sending an encrypted offsite copy to the cloud bucket you chose, and protecting the NAS’s own shares as a separate, versioned job. If a partner would rather host the offsite vault on their own Windows hardware than a cloud bucket, WholesaleBackup Server is an option, though most partners run cloud offsite plus a local vault like the one the client’s NAS already provides.
