To date, we've backed up our ReadyNAS Pros using cheap USB drives. This has served us well over the past three years but as we move forward to much larger disks and volume capacity, I'm rethinking this strategy.We'll be upgrading our systems to a configuration of 4 x 4TB drives in XRAID-2 dual redundancy mode. This will give us ~8TB data with two extra bays for expansion.I originally thought to use a USB hub and 2 x 4TB USB drives, splitting the contents of the data across the two disks. But with the cost of a 2-bay NAS like this Synology DS212j (http://amzn.to/1f0NQh2) so low, I'm thinking this would be a better solution since we can take advantage of the device's faster I/O and built-in power scheduling. I wish we could afford to use our Pros as backup and buy new ReadyNAS boxes but we're not there yet. ;)Any thoughts/recommendations on inexpensive NAS for ReadyNAS backup? Brands? RAID modes (JBOD vs RAID 0)? Any gotchas to consider?Thanks!

The RN102 is the Netgear equivalent - same processor speed, and similar performance. I use mine for backup (with 2 WD30EFRX drives installed, jbod). The RN102's frontview backup works well with my Pro-6 as the source. (I'm not suggesting that the Synology won't). The main issue with the RN1xx and RN3xx is that OS6 still has some issues that need fixing.If you are thinking using RAID-0 to spanning the volume over 2 disks, then I strongly recommend against it. RAID-0 spanning drives is too fragile - any failure destroys the volume. JBOD or RAID-0 that doesn't span volumes are the same thing as far as I am concerned. The main issue with multiple backup volumes is that you need to manually balance the storage occasionally.Overall I like backing up to another NAS - it keeps the backup device completely separate from the source.If you need more capacity, then maybe get a four-slot unit - they would be more cost effective.

Of course! Didn't even think of a smaller ReadyNAS. The RN102 is actually cheaper than the Synology so it makes perfect sense.So if I understand you correctly, best to set up as a multi-volume JBOD, and schedule and run Frontview backup from the RN102 rather than the other way around (scheduling and running from Pro)?Is there any safe way to create a single large volume on a two-bay system like this, so I can avoid having to manually split data across two volumes?

Yes. One caveat is that the RN102 is using btrfs as the file system. I have had no issues with that, but it is a bit cutting-edge for operational use. It's snapshot feature is quite different from the Pro, and in my opinion more useful. I'd leave the anti-virus scans off (doesn't make much sense on the backup, and slows things down).Also, OS-6 currently lacks disk spin-down. My guess is that they will add it shortly, but of course that gambling on futures.dhl wrote:...So if I understand you correctly, best to set up as a multi-volume JBOD, and schedule and run Frontview backup from the RN102 rather than the other way around (scheduling and running from Pro)?Yes. I always run the backups on the destination NAS, it seems better especially if you are combining with scheduled power-on. As always, be careful to not to be aggressive on power-down, since the NAS will shut down even if the backup is not complete. BTW, the RN102 also has WoL, so you could alternatively boot it up from one of the Pros on schedule. I haven't played much with that feature.dhl wrote:Is there any safe way to create a single large volume on a two-bay system like this, so I can avoid having to manually split data across two volumes?RAID-0 is the only way. If you are wanting long-term archival, it is not safe. If you are just wanting a current snapshot of the pro, it might be good enough.I recommend a UPS in any case, but especially if you go with RAID-0.

StephenB wrote:RAID-0 is the only way. If you are wanting long-term archival, it is not safe. If you are just wanting a current snapshot of the pro, it might be good enough.I recommend a UPS in any case, but especially if you go with RAID-0.We keep everything on HCL-compatible UPS (with USB monitoring).On main goal with the backup system is not archiving. We mainly want data protection and recovery in case our main NAS fails or (as in the current case) we need to do a factory reset for whatever reason.StephenB wrote:BTW, the RN102 also has WoL, so you could alternatively boot it up from one of the Pros on schedule. I haven't played much with that feature.Would be great if the some basic scripting were possible with backup scheduling - i.e. run backup on day/time, then power down when finished. Feature request! :wink: It seems like we'd get the most flexibility with a RN104 as we could run that in X-RAID2 single-redundancy mode and still have enough future capacity to back-up the Pros in dual-redundancy, even if we fill all the Pro's slots. I'll have to see if we have enough budget to do this.Re: snapshots - I've never used this feature. I get the impression it works a bit like Time Machine on the Mac, copying differences but making each instance look like a full backup so it takes much less time than a regular back-up?Do snapshots have any big advantages over regular Frontview incremental backups?Can snapshots be used for full volume recovery (i.e. recover C volume)?Can snapshots be saved to a backup drive instead of the source drive?

btrfs snapshots are described here: https://btrfs.wiki.kernel.org/index.php ... napshot.3FIf you do incremental backups with snapshots on, then the previous versions of the folder can still be accessed. This does take space of course, and you may not need them. The main value is that it gives you some ability to recover from user error.It's a btrfs file system feature, so the snapshots have to be in the same volume as the folder. OS6 creates each share as a btrfs subvolume, so the snapshots are essentially part of the share. One consequence is that moving files between shares in OS6 is a copy/delete operation - not as fast as on the Pro.When restoring, the snapshot folders would be included (so you might need to delete them before restoring).

Inexpensive NAS for over 4TB backups - recommendations?

39 Replies

Replies have been turned off for this discussion

mdgm-ntgr
NETGEAR Employee Retired
Jan 07, 2014
Those are timestamps for when the last full backup was run for each job in epoch time. You could use e.g. http://www.epochconverter.com to convert those timestamps to a date and time.
StephenB
Guru - Experienced User
Jan 07, 2014
I believe the values are the timestamps of the last full backups for backup job 1 and backup job 2.
mdgm-ntgr
NETGEAR Employee Retired
Jan 07, 2014
Yes it will use that file to determine whether a full backup or incremental backup should be run based on the settings for the job specified in Frontview.
dhl
Luminary
Jan 07, 2014
mdgm wrote:
Those are timestamps for when the last full backup was run for each job in epoch time. You could use e.g. http://www.epochconverter.com to convert those timestamps to a date and time.

ah yes, makes sense. I'm not gonna worry about it.

My RSYNC incremental backup finished in about 5 minutes, btw.

Since my partners are out of town and the Pro hasn't been touched since I started this process, can I safely assume that RSYNC copied everything, including any files that might have been missed when the initial NSF full backup failed?

Would differences between EXT4 and btrfs account for the differences I see in the amount of data I seen in the backup vs the source (2.94TB vs 3.06TB)?

If not, what else might be going on? There was no info in the NFS log when full backup failed.

mdgm wrote:
Those are timestamps for when the last full backup was run for each job in epoch time. You could use e.g. http://www.epochconverter.com to convert those timestamps to a date and time.

fastfwd

Virtuoso

Jan 07, 2014

dhl wrote:
can I safely assume that RSYNC copied everything

dhl wrote:
can I safely assume that RSYNC copied everything

Why not just check?

cd /path/to/source/directory
find . | sort > ~/src
cd /path/to/destination/directory
find . | sort > ~/dest
cd ~
diff src dest

dhl
Luminary
Jan 07, 2014
awesome. Thanks for the tip!
dhl
Luminary
Jan 08, 2014
@fastfwd -

My *nix skills are self-taught and a bit spotty ;)

How do I specify the directory path on a remote server in the shell?

Thanks!
xeltros
Apprentice
Jan 08, 2014
It depends on what command you use.

for SCP it's host:/path.
for SMB it's //host/path.

man rsync suggest an FTP-like path : rsync [OPTION]... rsync://[USER@]HOST[:PORT]/SRC [DEST]

The script fast fwd sent will work if you mounted the distant volume. Otherwise you can do on each NAS then use scp to copy from one to the other.
dhl
Luminary
Jan 08, 2014
xeltros wrote:
Otherwise you can do on each NAS then use scp to copy from one to the other.

This is what I wound up doing - easier than trying to remotely mount the distant volume.

And the results show that except for a handful of invisible files, source and destination are the same. I did a spot check of one of the invisible directories (a subsonic folder in .webroot) and found it was 180mb. My guess is permissions may have caused the NSF full backup to fail and this along with some of the other invisible files is why I'm see a data size difference between my source and the backup.

Whatever the cause, I'm confident the backup is good and everything's in order.

Thanks @fastfwd and @ xeltros for the shell tips. Always glad to learn! :thumbsup:
xeltros
Apprentice
Jan 08, 2014
Linux commands don't handle hidden files by default.
for example, cp copies only visible files unless you specify -a afterwards or choose to format the source as /source/*. The /* meaning copy of everything in the /source folder (that kind of writing is called regexp = regular expression), depending on the shell this includes hidden files.

Also remember the shell trick only checked files by name, the fastest way to check what is actually there. But if you really want to check file version you'd like to include size and modification date but that's a lot more scripting and unless your transfer sent back some kind of error I assume it's safe to consider the files are correct. You can also try to relaunch rsync with update flag.

Forum Discussion

Inexpensive NAS for over 4TB backups - recommendations?

39 Replies

Related Content

Router recommendation

Comcast Router Recommendations

Inexpensive power supply replacement for legacy 4-bay Readynases

RAX45 VPN software recommendation

Recommendation paramétrage derrière Freebox Revolution

NETGEAR Academy

ProSupport for Business