Question use Replication or Rsync?

[PhilD13]

I have 2 servers with Truenas installed on them. One uses latest Bluefin (Server1) and the other uses the latest Cobia (Server2). Looking at the options in Data Protection I see that there is a Replication Task that could be used and also an Rsync task that could be used. I did some reading around but still have a few questions that did not seem to really be answered about the Replication task.

If using the Replication task option I understand the replication task makes an associated Snapshot task and then sends the snapshot to the target server?
What happens if the First (sending) server has a hardware failure or is destroyed. Is the data on Server2 actually available for direct use or does the data residing on server 2 have to be restored to a new server to be used? Does the data just go poof if the first server is unable to supply the data?

I guess I don't get how sending the replication tasks snapshot to a different server actually protects my data from loss unless the replication task initially replicates all the data onto the second server?

I also understand that a Replication task might not be the best option for a 1GB network due to being able to saturate the network?

I understand the data protection tabs Rsync task is slower, and it sends the actual data not a snapshot and also not as likely to saturate the network. This generally seems to be true.
I do know for a fact with Rsync task that the data resides on the second server and is accessible.

Rsync was what I was using to send data from Server1 to a QNAP (Server 2) until QNAP decided to fry the backplane. I'm pressing into service an old Supermicro with the latest Cobia installed on it to be the second server. Storage space on the second server is not an issue.

 

[winnielinnie]

Is the data on Server2 actually available for direct use

Yes. A snapshot is simply a point-in-time of the complete filesystem.

Every time you successfully replicate from source to destination, the destination's "live" filesystem is an exact replica of the latest snapshot that was sent; doesn't matter if it was from a full or incremental replication. (Unlike the snapshot used in the replication, the files on the live filesystem can be written, modified, deleted, etc. You do NOT want to mess with files on a backup destination while it is currently being used solely as a backup role.)

Does the data just go poof if the first server is unable to supply the data?

No. For the reason explained above. However, it's good practice to test if you can access the files on the backup by browsing the (read-only) snapshot, or mounting the dataset itself. (Keep in mind that any changes you do on the destination will be erased upon the next replication from the source. Backups with ZFS are a one-way direction.)

I guess I don't get how sending the replication tasks snapshot to a different server actually protects my data from loss unless the replication task initially replicates all the data onto the second server?

It does.

A snapshot is not simply "parts" of a filesystem. A snapshot represents an entire filesystem. The first time you run a replication task, whatever snapshot it sends over has to send everything in the snapshot ("filesystem"). Any subsequent sends will be incremental, only sending over the differences. Either way, this incrementally sent snapshot is sill an entire filesystem on the destination, since it shares the same blocks as the base snapshot from before.

I also understand that a Replication task might not be the best option for a 1GB network due to being able to saturate the network?

Why should that matter too much? You can limit the speeds and/or schedule it to happen overnight only. Besides, the incremental sends shouldn't take that long after the first initial ("full") send.

 

[PhilD13]

Thanks for answering my questions. It makes me feel better that I'm on the right track with my thinking.
The speed didn't matter too much but I had read some old (2012) stuff that came up as suggested topics when I made up the questions title that it was an issue. I generally do heavy stuff between midnight and 7am anyway so everything is finished by the time we are ready to start editing and transferring photos. Your description of what happens on the replication (first time full replication, then snaps of changes mirroring the primary) was what I thought but did not run across that (or missed it)

It's just my wife and I using the system for her business and we generally don't mess with the backup server files. One case would be if something catastrophic happens to the primary (server1) server. To keep working we would need to make the secondary backup server the primary while I fixed or put together a new server. Nothing worse than to not be able to work on a clients files if the "server is down"

Maybe I should just set Destination Dataset Read-only Policy to Ignore when creating the replication? It would be the same as I was doing with Rsync where data on the second server was always available read/write and we just didn't mess with it.

 

[winnielinnie]

Maybe I should just set Destination Dataset Read-only Policy to Ignore when creating the replication? It would be the same as I was doing with Rsync where data on the second server was always available read/write and we just didn't mess with it.

It doesn't make too much of a difference. The readonly propety can be changed at any time. The reason to have it set to "on" is a safeguard to prevent accidentally "using" the backup dataset (as a live filesystem). You can set it to "ignore" if you want.

 

[PhilD13]

Okay, I see the point of the read only.

I will do some more reading on the replication task setup and and make up a test replication task as I would like to give it a try. I'm currently having some issues with broken pipe and permission denied errors causing the replication task to fail.

In the interest of getting the main data transfer task started, I went ahead and made a couple necessary changes to the existing Rsync tasks that had been going to the failed server to connect and point to the new server and started the rsync tasks to begin getting the data sent over.

 

[winnielinnie]

In the interest of getting the main data transfer task started, I went ahead and made a couple necessary changes to the existing Rsync tasks that had been going to the failed server to connect and point to the new server and started the rsync tasks to begin getting the data sent over.

You can't (shouldn't) use both.

This will duplicate all blocks, essentially doubling the size needed for the backup.

 

[PhilD13]

No, I wasn't planning to use both.

The server I just put together has at least 2.5 times the currently needed capacity, so I have some room to give things a try without impacting space. I'm going to get the data over there with Rsync so there is a copy of the data. Once I feel good about the safety of the data again, I will get the replication task sorted out and working with some test data. If I think it might be more efficient to use a replication task instead of Rsync, I will replicate the real data using a replication task, and once successful remove the rsync task and the data from that task. If I don't think it is better or more efficient and reliable than an Rsync task, then I will continue as I have always done and use Rsync and not worry about using a replication task.

You have provided some really good information on the replication process. I want to do more reading so I can decide which is the one I am most comfortable trusting my data to. Replication or Rsync. Thanks

 

[winnielinnie]

You have provided some really good information on the replication process. I want to do more reading so I can decide which is the one I am most comfortable trusting my data to. Replication or Rsync. Thanks

Keep in mind Rsync is "file-based", while ZFS send/recv is "block-based".

This makes incremental transfers ridiculously quicker (with ZFS to ZFS).

• No directory trees need to be populated and compared every time it runs.
• Only modified blocks are transferred (even for large files).
• Moving files around or renaming them does not require the entire file to be sent over, all over again. (Only the metadata blocks, which reflect such changes, are sent over.)
• It preserves the snapshot history of your filesystem, without needing to maintain extra copies or hardlinks of files.

 

[PhilD13]

That's good to know!
I am leaning towards using the replication task and I guess that's why I keep seeing if you have two or more Truenas systems to use replication. between them.

Other than the documentation, are there any resources you would recommend I read or take a look at so I can learn more about the process?

 

[winnielinnie]

Other than the documentation, are there any resources you would recommend I read or take a look at so I can learn more about the process?

It's really tricky to find a one-stop shop for ZFS information, usage, and understanding. You just have to "search around" and find what sticks, and also caters to your unique way of learning.

I prefer to learn visually and just trying it "hands-on". I know hands-on isn't always the wisest approach, since you don't want to play around with valuable data, and you might not have the resources (or time) to setup a brand new VM just to play with ZFS.

There's a primer on Ars Technica called "ZFS 101", which is a good place to start (even if it's a few years old).

 

[PhilD13]

I skimmed and read some of that article back in June before I made the first Scale server. Mostly to get an idea if Raidz2 was what I wanted for my setup when planning the move from a QNAP server on which I had used multiple Raid6 groups (vdevs in zfs) for the pool. The article is well written and there are other related articles too on the site worth a read.