Best Recipe??? CloudBerry & Tiered Backup With NAS & Cloud

MSP360 Backup
1

Hi, I’ve been using CloudBerry since '15 successfully to Glacier. Has been on an older XP machine (!) which pulls from a NAS and pumps the data up to Amazon. This is a kludgey system. So need to re-do it.

BIG QUESTION: What’s a best backup recipe that will enable file versioning (like Time Machine)? And which has BOTH a local NAS backup server AND a cloud backup?

CONCERN: We had a nice NAS device on SMB LAN networking. And we could put CloudBerry directly on the NAS. However, with the threat of ransomware, there’s the danger that a problem on any member of the LAN desktops could propagate to the shared files NAS.

SOLUTION: Two NASes: 1 x sharing and 1 x backups

(1) FILESHARING NAS – for file sharing and large files, serving everyone on the LAN.

(2) BACKUP NAS – The filesharing NAS rsyncs over to a second NAS that is not on SMB LAN networking. The connection would be via SFTP (i.e. SSH).

This seems to be a recommended solution when you get beyond the basics. Our sense is that basic backup is mostly too basic.

CURRENT LAN CONFIGURATION: W10 desktop clients, shared BSD NAS device, all over wired Ethernet and also some WiFi for laptops.

PROPOSED SOLUTION:

  1. DESKTOP BACKUPS: Considering doing rsync (or if there’s a W10 GUI version of this) or other backup software to the BACKUP NAS over SFTP. Full near real-time backups but no risk. Important that VSS is working.

  2. FILESHARING NAS: Same as desktop backups, SFTP to BACKUP NAS, with no risk.

  3. BACKUP NAS TO CLOUD: Put CloudBerry (re-purposed license to Linux) on Linux in a VirtualBox Guest on the BSD NAS. Use CloudBerry to pump versioned files to some cloud host. 2.5 TB total without duplication for versioning.

BEST PRACTICES QUESTIONS

a) VERSIONING - How can we do file versioning, rather like TIme Machine on Mac? This is essential for protection against ransomware.

b) THRASHING With four or five clients pumping files into the NAS Backup NAS, plus Cloudberry pumping files up the Cloud, will this create disk thrashing on the Backupu NAS? Or is the server smart enough to queue things, and it just takes longer? Probably there won’t be that many files eligible for backup in any given hour or two anyway.

c) DIRECTORY CHANGE PROPAGATION – If a directory name change takes place, or even if a directory is moved, this can create cascading unnecessary changes. How does CloudBerry deal with this? And similarly, how would Cloudberry deal with deletions, as the propagate from desktop to Backup NAS to cloud?

d) ARCHITECTURE – Is the above plan the best architecture? Let’s just ignore the file sharing NAS, and think of this recipe as A) first, backup local clients to local backup NAS and then (B) backup local backup NAS to remote Cloud.

SUMMARY RECIPE

I’m hoping that someone here will have some professional insight here. Getting this right could be helpful to a lot of people.

Thanks,

JM

2

[reply=“JHM;d290”]
Hi!

Regarding your questions:
BIG QUESTION: What’s a best backup recipe that will enable file versioning (like Time Machine)? And which has BOTH a local NAS backup server AND a cloud backup?
You can install the software on A Windows machine, specify that NAS as a source network share, and that’s basically it. You can set any number of versions to keep on storage side as you like, even base it on time/date and not the number of versions, so there are many possibilities to keep as many versions as you like.

CONCERN: We had a nice NAS device on SMB LAN networking. And we could put CloudBerry directly on the NAS. However, with the threat of ransomware, there’s the danger that a problem on any member of the LAN desktops could propagate to the shared files NAS.
We’ve discontinued NAS software last year, so I don’t think that config would suit you.

**PROPOSED SOLUTION:

  1. DESKTOP BACKUPS: Considering doing rsync (or if there’s a W10 GUI version of this) or other backup software to the BACKUP NAS over SFTP. Full near real-time backups but no risk. Important that VSS is working.

  2. FILESHARING NAS: Same as desktop backups, SFTP to BACKUP NAS, with no risk.

  3. BACKUP NAS TO CLOUD: Put CloudBerry (re-purposed license to Linux) on Linux in a VirtualBox Guest on the BSD NAS. Use CloudBerry to pump versioned files to some cloud host. 2.5 TB total without duplication for versioning.**

  4. Can’t really comment on 3rd-party software usage and how it could affect our software’s functionality, but if you’re just syncing files and it works for you to transfer the data to another device and then back them up using our software that should work. Make sure there are no VSS conflicts when doing such operations.

  5. We consider FTP/SFTP to be a legacy protocol and this functionality is provided “as is” within our software.

  6. Yes, that should work. You can use Windows client for that, since functionality-wise it is a bit better than Linux version.

**BEST PRACTICES QUESTIONS

a) VERSIONING - How can we do file versioning, rather like TIme Machine on Mac? This is essential for protection against ransomware.

b) THRASHING With four or five clients pumping files into the NAS Backup NAS, plus Cloudberry pumping files up the Cloud, will this create disk thrashing on the Backupu NAS? Or is the server smart enough to queue things, and it just takes longer? Probably there won’t be that many files eligible for backup in any given hour or two anyway.

c) DIRECTORY CHANGE PROPAGATION – If a directory name change takes place, or even if a directory is moved, this can create cascading unnecessary changes. How does CloudBerry deal with this? And similarly, how would Cloudberry deal with deletions, as the propagate from desktop to Backup NAS to cloud?

d) ARCHITECTURE – Is the above plan the best architecture? Let’s just ignore the file sharing NAS, and think of this recipe as A) first, backup local clients to local backup NAS and then (B) backup local backup NAS to remote Cloud.**

A) You can simply specify the number of versions to be kept on storage during creation of any backup plan and that’s it, no additional actions required, the software will do the rest.

B) The software is smart enough to queue the files during upload, so you should be fine on that front.

C) There is an option called “delete files that were deleted locally”, so the software will remove deleted/renamed files/folders, so if you enable it you won’t have to worry about that.

D) Yes, you can use 2 separate plans for that with different retention for each(if you want, of course), or set up a hybrid plan that will first upload data to local destination and then to the cloud one.

Let me know if I misunderstood you regarding some of the points.

The setup should actually be very simple: Install the software on a Linux/Windows machine, connect to your NAS, select the files for backup and their destination, that’s it.

3

Matt,

Super thanks for your detailed and thoughtful answers. Some clarifications though . . .

  1. LINUX NOT WINDOWS – We want to use Linux as the host for CloudBerry which pumps data to the cloud. Our NAS is not Windows-based. We don’t want the expense of another Windows 10 Pro software license – and maintenance effort – just to support CloudBerry. Please keep developing Linux. It’s a self-fulfilling prophecy that if you don’t develop it, it won’t be used etc. etc.

  2. SFTP IS LEGACY??? – FTP is legacy, for sure. But is SFTP legacy? How else will we connect between machines securely?

  3. NETWORK SHARES – The purpose of an SFTP connection is to get away from a SMB Windows LAN connection – which is vulnerable (e.g. via Network Share) to ransomware.

  4. NAS SOFTWARE – No concerns about NAS – we are using NAS4Free (similar to FreeNAS). It’s BSD and supports VirtualBox. We want to put CloudBerry on Linux (OpenSUSE) in VirtualBox. So we have only one machine that is our secure local backup machine AND cloud gateway. NICE!

4

[reply=“JHM;920”]

  1. Linux version is in very active development, we’re planning to introduce block-level and image backups this year. We have a Linux section in the forum where you can provide your feedback.

  2. Yes, our primary focus is on cloud service, so for Windows version of the product FTP/SFTP is considered to be in a legacy status. For Linux FTP/SFTP will be supported in version 2.6, it is not available yet.

  3. Judging by my personal experience, any connection has its vulnerabilities. Still, if you’re just going to upload backups to the cloud you just need to make sure the files are locally available if you don’t want to use SMB.