On the server, you'll see the most recent version of all files, including any files that you deleted or renamed on the client. That backup location is then excluded from the Cloud Station Drive client (so you don’t re-download your backups when you sync). The default backup location is within the existing /home/CloudStation/ folder. It stays up-to-date as you add and change files, functioning as a variation on a synced directory that preserves deleted files on the server and excludes temp files. (Apparently, this was all here under DSM 5 but I never noticed it and I'm not sure it had the same flexibility.)īut wait, there's more! There's now a new Cloud Station Backup client utility that lets you back up any local folder to Cloud Station.
Version history can be accessed by the user thought a right-click context menu on the file or through the DSM interface, so that's cool, although there's no diff tool or way to preview what changed. It also does file versioning and preserves deleted files. DropBox) into a flexible bidirectional synchronization tool. Yeah, I know there are a bunch of other tools that can do this, so no biggie, but it was nice to have as an option.Īt the same time, Cloud Station has evolved from a simple “magic folder” (e.g.
Strangely, my old copy job survived the upgrade and continued to run, but there is no way to create a new job like that. No grabbing that external drive and plugging it into another system. Versioning is better in most ways, but it does require going through DSM to get at the data. USB drives) but loses the ability to do a simple differential backup to USB, which is what I had been doing. Hyper Backup allows multi-version, database-driven backups to both volumes AND mount points (e.g. With DSM 6.0, the old Backup & Replication is gone, replaced by Hyper Backup. Tracking deleted files is also very similar to turning on the recycle bin for a shared folder. The new Cloud Station Backup client utility adds to the confusion about what and how you backup files. The inclusion of versioning in Cloud Station strikes me as problematic because 1) versioning is completely unrelated to file synch and 2) it does something very similar to Hyper Backup. I would love to hear what others think, if my conclusions are correct, and what you find as the best use-cases for each. There seems to be a lot of confusion and overlap between the two.
The current desktop apps for Cloud Server Backup have been updated recently, and there's a Mac 64-bit version ready for MacOS 10.15 "some desert" dropping 31-bit support in the summer.I've had a couple of days to play with the new DSM 6.0 and especially the changes to Cloud Station and Hyper Backup. you need to exclude this folder from syncing back on the two-way task. The destination this setup uses it the DSM user's /home/Drive/Backup/ folder, and access privileges are already correctly configured.
So, for now, I would rather use Cloud Station Backup on Mac (etc) to backup to DSM Drive. It is do-able but needs testing and many NAS owners will struggle to do this. And this is the reason I keep using Cloud Server Backup: the DSM admin must ensure that Team folder / shared folder privileges are set correctly to limit access from other DSM users whether from Drive apps or other methods. This means that using Syno Drive for doing a backup (one-way) task must use a Team folder as its target. Doesn't matter if the first task is excluding the folders you want to store the backups. If you are already using Syno Drive to do a Dropbox-style service with your /home/Drive folder then you cannot set up a second task to somewhere within /home/Drive. The reason being the destination on DSM for backup data. I have a slightly contrary view about moving from Cloud Station Backup (to DSM Drive) to Synology Drive for backup.