Backup to 2nd NAS

[voodoomatze]

Hi all,

I need your advice on how to best integrate a secondary NAS as Backup target.

Scenario:
- TS-453mini is my primary NAS (4 x 3TB RAID 5)
- TS-239 Pro is my secondary NAS (2 x 3TB RAID 1)

I plan to use the secondary NAS SOLELY as a backup target. The two NAS are directly connected in their own privat net.
Now I am wondering: What is the best (mostly fastest transmission) way to hook up the secondary NAS. Options I am aware of so far:
- iSCSI (Upside: Easy integration to prim NAS; Downside: Loosing some space on the target due to EXT4 on LUN on iSCSI target on EXT4)
Speed: ??
- RSYNC server (Upside: Easy integration; more efficient on disc space)
Speed: ?? - Compression can be apply so effective transmission speed should be improved
- NFS share (Upside: Easy integration; more efficient on disc space)
Speed: ?? Compression: ??
- AFS, SMB, etc. I kind of rule out as I think the management overhead should make these approaches inferior to NFS at least.
- Other ideas ??

Really appreciate your feedback!!

vm

[storageman]

How you going to get 8TB on 3TB?

[voodoomatze]

How you going to get 8TB on 3TB?

Not really the point. However, obviously only some of the data shall be backed up to the 2nd NAS.

[storageman]

I would use RTRR.

[voodoomatze]

I would use RTRR.

RTRR is identical with rsync afaik.
Do you have any reasons why you suggest RTRR?

[storageman]

I would use RTRR.

RTRR is identical with rsync afaik.
Do you have any reasons why you suggest RTRR?

Incorrect.

RTRR is based on date and size changes to files. For LAN/home user it is the best choice because performance issues shouldn't be a consideration(also can be set to auto replicate)
RSYNC is based on block changes and is more efficient on large files because only the delta changes get replicated. It's the only one to use across the WAN.

While RTRR is slowed down because it has to replicate the full file, RSYNC is slowed down by having to first compare blocks.
If small files RTRR is a good choice.

[rolldog]

I'm trying to do the exact same thing. My primary NAS is already up and running, and my 2nd NAS is completely empty right now. To setup RTRR to back one NAS up to another, do I need to setup 1 storage pool on the 2nd NAS and create one large volume, then go to my primary NAS to set it up using RTRR to backup to the 2nd NAS?

[P3R]

I plan to use the secondary NAS SOLELY as a backup target. The two NAS are directly connected in their own privat net.
Now I am wondering: What is the best (mostly fastest transmission) way to hook up the secondary NAS.

If it's a backup, why the extreme focus on speed?

Why not simply have it scheduled and let it rattle along as fast as it can? Who cares if it takes an hour? Or four? Or six?

- iSCSI (Upside: Easy integration to prim NAS; Downside: Loosing some space on the target due to EXT4 on LUN on iSCSI target on EXT4)
Speed: ??

Could be a possibility if you feel comfortable accessing that LUN when your main NAS no longer exist. Personally I feel much more comfortable having a backup on a general shared folder.

- RSYNC server (Upside: Easy integration; more efficient on disc space)
Speed: ?? - Compression can be apply so effective transmission speed should be improved

Rsync is great on very slow (WAN) connections but very rarely a best fit on LAN. Compression is only useful on some types of data and on slow (WAN) connections.

- NFS share (Upside: Easy integration; more efficient on disc space)
Speed: ?? Compression: ??
- AFS, SMB, etc. I kind of rule out as I think the management overhead should make these approaches inferior to NFS at least.
- Other ideas ??

The performance difference between protocols is probably negligable so why not instead use what's most easily used across different platforms. Today that's most often CIFS/SMB.

RTRR is identical with rsync afaik.

Absolutely not. Two very different protocols. Both technically and more importantly, in what situations they fit.

Rsync shines on very slow (WAN) connections and with small changes in very large files. RTRR is more feature rich and almost always the better choice on a LAN.

RTRR is based on date and size changes to files.

RTRR can also be configured to do a byte-by-byte comparison, but then it'd better be on gigabit or faster media.

[storageman]

Rsync shines on very slow (WAN) connections and with small changes in very large files. RTRR is more feature rich and almost always the better choice on a LAN.

RTRR is based on date and size changes to files.

RTRR can also be configured to do a byte-by-byte comparison, but then it'd better be on gigabit or faster media.

I see no option in RTRR for block changes, please explain.

[P3R]

I see no option in RTRR for block changes, please explain.

I didn't say anything about blocks, RTRR only works with complete files.

You said that RTRR works with date and size changes (which is correct) but I added that it also have the option to compare the actual file content between source and destination, similar to rsync but done in another way.

[storageman]

Hmm, that is greyed out in my test. No sure the purpose of checking file contents and causing slower backups.

[P3R]

Hmm, that is greyed out in my test.

Okay, not all options are available in all modes of operation but I seem to be able to select it in both local and remote backup jobs in HBS.

Yes a complete file check will be slower than not doing it and depending on data volumes and available bandwidth, may even be impossible so use with care.

I never found any use for the option myself but for completeness of the thread I wanted to point out to the community that a data comparison option is available also in RTRR.