Hi everyone,
I was reading some of the old forms on how to backup a Core server to another Core server and there were many different options. I was wondering what is the best way to do this security-wise, not worrying about transfer speed. I have heard people use Rsynce, Replication, and Cloud Synce Tasks. I am just unsure of what is the best way to accomplish this.
I vote for replication. It’s a relatively simple way to do it, but you need to have snapshots enabled. Also, the destination dataset is going to be read-only unless you set it differently (i.e. it is a one-way replication by default). To speed things up, enable the SSH+NetCat option once you have confirmed that standard SSH replication works as intended.
I use a push configuration, ensuring that the receiving NAS has no passwords, etc. on it. If your local dataset is encrypted, it will be encrypted on the receiving end as well. If the receiving NAS is your primary NAS, then you might want to use a PULL configuration instead.
Replication is the quickest way, bar none, to reproduce the data exactly from one TrueNAS to another as the data is copied in large blocks with ZFS checksums, etc. However, as with all things TrueNAS, there are a ton of parameters to learn about and hopefully set correctly, experiment with, realize something was off, redo the replication, etc. until you finally attain replication Nirvana.
Some are more obvious than others. For example, for my use case I have enabled retaining local snapshots beyond their usual expiration date if the replication cannot finish in time. That ensures that if your remote server goes offline for some reason (ice storms, anyone?) that the two NAS’ can later pick up where they stopped off last.
There are tons of additional parameters. It can be daunting. But it is also worth it. A local replication between two pokey single-VDEV NAS cruised along at 400MB/s using 10GbE fiber. Over a throttled network (and if your ISP is Comcast they will throttle you!) the efficiency of replication really makes a difference. Ideally, do a local replication first, then only incrementally update the remote TrueNAS as a lot less data will need to be sent.
Best of luck!
Where is the backup machine located? Is it in the same network, or at another location?
You can set replication tasks to encrypt the data.
EDIT: @Constantin posted seconds before this.
1 Like
Third vote for replication.
Yeah, replication has its quirks, but as far as backups go, it’s pretty damn good in many ways
1 Like
Thanks for the replies. I plan on having the second Core server on a different network, away from home. Also, I would like to have passwords on my receiving NAS, so would it be better to do a pull instead of a push?
It’s up to you. If you feel like the receiving NAS is more secure than the sending one by all means use a PULL. Whichever NAS controls / initiates the connection will have the root password to the other system. (At least for a while, it’s likely the system uses a password less approach subsequently).
Consider carefully how you will get the two NAS’ to talk to each other. Some folk are using Wireguard between MikroTik routers to create a VPN that will work even if both ends of the connection are using dynamic DNS endpoints. Either way, do not even think of exposing your TrueNAS to the internet.
How would I go about setting up WireGuard and MikroTik routers? How could I expose my NAS to the internet?
The Network berg does a great job on YouTube of describing how to set up Mikrotiks and VLANs between them using multiple VPN options (wireguard, openVPN, tailscale, etc). Both Mikrotiks can be on a dynamic IP address and the built-in Mikrotik VPN makes connecting them easy. You don’t even need to sign up for a DDNS service. It’s all there.
I highly recommend looking at the RB4011 series of routers to connect with. Like TrueNAS, there is a steep learning curve but routeros is also highly rewarding.
@Firestorm You could either setup a VPN between the two networks (Wireguard or OpenVPN or maybe even ZeroTier/TailScale type solutions) or SSH.
SSH is much easier in my opinion, but you’d definitely want to make sure you set this up in a highly secure way (ie. either 128-bit ed25519 or 4096-bit RSA key, password-based logins disabled, and maybe even white-listed IP’s only).
As for VPN, Wireguard is probably simpler (works somewhat similar to SSH). OpenVPN is much more involved to setup, but in general, is also a lot more powerful due to it supporting layer 2 bridging and DHCP.
zettarepl.py which is used by TrueNAS for replication does support some feature related to encryption.
If you are worrying about storing your data at a remote location, then you want the data to be encrypted on the remote side, but not expose any password or keys on the remote server. The transfer between source and destination is supposed to be encrypted regardless, unless you decide to proceed otherwise.
With zettarepl.py, you must obey the strict requirement of the snapshot naming convention, otherwise you will most likely not be able to replicate all of your snapshot. This may be just fine.
zettarel.py does give you the option to force encryption of the dataset on the remote side. I just don’t know how this is done in reallity as it would imply a key or passphrase be stored on the remote side.
On the other hand, if the source belong to a pool or dataset that is already encrypted, then zettarepl.py (using underlying zfs options) is capable of transfering encrypted dataset without the need for the remote server to know anything about the encryption key or passphrase.
Overall, replication is great, but zettarepl.py isn’t friendly enough to support any snapshot name scheme. Otherwise, replication is the way to go.
Thanks so much for everyones help. I will be sure to take my time setting this up to be secure.