My recommendation: Don't use ReadyCloud user home shares
The recent issue with the ReadyCloud server has shown a vulnerablility of losing everything in a ReadyCloud users' home share. While I expect Netgear to take steps to prevent that in the future, I certainly would not rely on it never happening again. My advice is to stop using user home shares for ReadyCloud users. You can create another share (but it can't have the same name as any users' name) and give just one user access. You can take advantage of the case dependancy of share and user names to create similar names (i.e. user "somebody" has access to share "Somebody").
This has the added benefit that you can use that same share with both a local and a ReadyCloud account. Then if the ReadyCloud server is down, local users are not locked out of their data. For these reasons, this has always been my recommendation; the recent events have just added a new and more compelling reason.
If you never even access your NAS remotely, you may even want to consider stopping using ReadyCloud at all. My opinion has always been that Netgear is doing nobody any favors by having a user model where your NAS is your own "little piece of the cloud". It's not. It's a NAS stitting there right next to your computer, on the shelf, in the closet, etc. And ReadyCloud access to it relies on Netgear's server, whether you are next to it or 1000 miles away. There are also other ways to access it remotely where you use the local account rather than the ReadyCloud one. I recommend ZeroTier (do a search), though other VPN solutions and accessing it via remote access to a computer on your network are other options.
Re: My recommendation: Don't use ReadyCloud user home shares
There is so much to say...
Don't use ReadyCLOUD locally.
ReadyCLOUD is not a business grade service, it's a free feature. Look at prices of Cloud services for Pros, you'll see the difference. So downtime is "acceptable". (I'm obviously NOT saying the ongoing issue is acceptable!)
Don't confuse RAID redundancy with backup.
Don't expect that multiple disk failure can't occur.
Don't confuse snapshots with backup.
Don't confuse a resilient backup with an easy-to-restore-from backup.
Nothing replaces an external backup.
Don't assume your backup is ok, check its integrity.
Bidirectional syncing Is not a backup, it's quite the opposite, the surface of vulnerability is increased.
Unidirectional syncing is also dangerous as any accident on the source may be replicated on the destination.
Don't leave your NAS run for 5 years without keeping an eye on the health of the hard drives.
The best solution is not necessarily the one that protects you from everything, it's a balance between resiliency, efforts and money.
Ask yourself the right questions:
How important is the data?
Am I protected against accidental file deletion, accidental file modification, accidental share deletion, virus and ransomware, reasonable hardware failure (eg. one disk), catastrophic failure (multiple disks, chassis), catastrophic situation (fire, theft), software failure (NAS doesn't boot, filesystem corruption), bit rot, etc.
Is resiliency or ease of recover the most important for my backup? Or both?
Do I need high availability (eg. data loss is not important but availability of workspace is)?
How much money, time and effort do I want to put in my backup plan?
I designed my backup plan as an exercise, which somewhat justifies its relative complexity. Sharing here some details as an example. Availability is not a concern for me and wasn't talen into account in the design.
- I have two NASes, each from a different manufacturer, to lower the risk of impact of a software issue on a NAS.
- On each NAS, I use a different filesystem, to lower the risk of impact of an issue related to filesystem.
- Some of my devices transfer their backups to one NAS, some to the other one, to reduce impact of a failure of a NAS before further propagation of backups.
- Daily, the first NAS mirrors the data from its devices to the second NAS, then the second NAS mirrors the data from its devices to the first one, to lower the risk of impact of a complete NAS failure.
- On the second NAS, I use snapshots for versionning of the backups. Because I use mirroring backup tasks, this is required to allow rolling back if a bad backup is propagated to the other NAS.
- On the first NAS, the most critical data is backed up to a Cloud location, to allow easy recovery, increase resiliency while keeping the amount of data low enough to fit in a free Cloud service.
- On the second NAS, fortnightly, the content of the shares and snapshots are copied to a BTRFS USB drive (previous snapshots are retained, it's a cumulative task, not a mirror task), to lower the risk of impact of a catastrophic event.
- On the second NAS, fortnightly, the content of the shares is copied to an EXT4 USB drive (rotating backups to know the exact content of a share at a point in time and also allow versionning), to further lower the risk of impact of a catastrophic failure, as well as reduce the impact of a flawed backup method (bad script, etc.).
- The USB devices are not stored in the same location as the NASes, and I don't use them the same week, so I always have a USB device containing my backup at the other location in case of a catastrophic event occurring during the backup of USB task.
- The NASes are not beside each other, to reduce the probably of a localized issue impacting both.
- The first NAS is behind a UPS, to prevent power issues to damage its hardware or corrupt its software.
Re: My recommendation: Don't use ReadyCloud user home shares
Many of the community postings concern problems because catastrophies and emergencies get our attention. But I have really appreciated the opportunities buried in threads to find out the hows and whys of others' uses of their ReadyNAS devices. As a result, I have learned alot, have better understood how the OS is designed to work and its limitations, have upgraded hardware in my Ultra 6 Plus, and have become more intentional in my use of my NASes. Thanks to jak0lantash, Sandshark, StephenB, mdgm (in some ways more so pre-NetGEAR-employment—although having insider insight and assistance despite company constraints is also helpful), and many others.
- Some of my devices transfer their backups to one NAS, some to the other one, to reduce impact of a failure of a NAS before further propagation of backups.
I forgot to mention something important about that:
A backup should be read-only. For example, if the machine is compromised, you don't want its backup to be exposed and vulnerable.
All the devices push their backups to their assigned NAS. As they push it, they need read-write access. So to avoid fully exposing the backups, for each client device, only the share on its assigned NAS is read-write, the share on its secondary NAS is read-only.
- Daily, the first NAS mirrors the data from its devices to the second NAS, then the second NAS mirrors the data from its devices to the first one, to lower the risk of impact of a complete NAS failure.
This is actually not accurate. Only one NAS controls the mirroring. So the first NAS pushes the backups of its devices to the second NAS and pulls the backups of the other one's devices to itself.
This approach contradicts the previous point that a backup should be read-only. As the first NAS pushes some backups to the second one, it has to access the remote share in read-write. To alleviate the risk implications, the backup tasks between NASes use a dedicated VLAN, and the "exposed" shares are only accessible read-write on the "backup" VLAN, while being read-only on the "data" VLAN.
Also the "first" NAS described here is powered off most of the day, only boots up to perform the mirroring tasks and shut down once complete.
A backup should be read-only. For example, if the machine is compromised, you don't want its backup to be exposed and vulnerable.
My own are read/write (though i probably should change that). My disaster recovery (Crashplan) is not exposed, so I could recover everything even if all the local backups were lost.
There is a trade-off here. If you do pull backups (from the secondary NAS) it is easy to make the secondary shares read-only. But push backups on OS 6 are made from snapshots, so they are always coherent. Push requires read/write. If you use rsync, you can still make SMB, etc read-only (or completely disabled).
I've sketched out my backup plan in other places. Currently it looks like this:
-The main NAS is the 526x. It is a combination of primary storage and secondary storage. My PCs (4 at present) all do Acronis Image backup to 526x weekly. For the two desktops, this is scheduled. The two laptops are done manually.
-A 524x is secondary. Daily backups of each share are made with RN526 as source. Snapshots are enabled, with 3 month retention for most share. The Acronis image share has 2 week retention, to better manage space.
-A pro-6 serves as tertiary. This runs OS 4.2.30, so it is ext instead of BTRFS. Daily backups of each share are made with the RN526 as source. Crashplan runs on this NAS.
I could daisy chain the backups instead of taking them from the primary NAS, but I believe the RN524x snapshots give me enough rollback.
My advice is to stop using user home shares for ReadyCloud users.
I agree - and if you don't have a lot of users, you are better off not using home shares at all. Creating a share for each user is more flexible and easier to troubleshoot.
