Here is my small intro: I am building a replication box with Rockstor 4 that I plan to host it off site. My current server on site is using Rockstor 3.9 (I plan to upgrade once v4 is “stable” ). The connection between the two servers will be through Wireguard. My setup is kind of a hybrid site-2-site VPN using Wireguard, so long story short, I must use wg client directly on my replication box but my main server is behind a router. I can provide more info about this if needed.
What I would like to achieve is replicate my shares of about 2TB locally, not going through Wireguard, then continue the incremental snapshots through the VPN.
My question, since the configuration of a replication service is dependent of the network interface and the replication task is bound to the IP + ID of the distant appliance, is there any way to change the IP address and interface name for a configured replication task?
After some initial tests, I am getting server error 500.
I know my way using BTRFS commands, but I would like to achieve this using Rockstor for convenience.
I am open to any idea you might have
Thanks a lot!
@G_Man_be Hello again.
I can pop in on this one:
if this version is 3.9.1-16 then replication is broken, it was later fixed in the Stable release. But if it’s 3.9.1-0 I’m pretty sure it did work back then. But that’s a long way back (years) and much as been fixed all over since then.
So exact version numbers via:
yum info rockstor
should help to at least rule that one out.
As for the wireguard I’m afraid I’ve not experience but there are a few here on the forum who are way more up on networking than myself so hopefully they can chip in.
Hope that helps.
@phillxnet, thanks for the interest.
My server on site is version 3.9.2-57, actually I have no issue with the replication itself. I managed to make it work once using my local ip range and once using my wireguard ip.
The problem is after I create the replication task with my local ip, and I want to change it, I must remove the configured distant appliance and recreate it with the new ip. After doing this, the task will fail because it cannot validate the ip.
Here is an error:
DoesNotExist: Snapshot matching query does not exist.
Maybe there is a manual way to run the first “btrfs send” then create the task?
Let me know if I need to better explain
It’s a little more involved unfortunately as there are tasks and db entries setup so it may be that, at least for now, an alternative backup / replication setup would fit your needs better. Btrfs send depends on taking a read only snapshot and then sending that snapshot. Once then takes another snapshot and sends the difference between the first and second … and so on. And all in the stable state of Rockstor is 3 snapshots on both sender and receiver and the oldest snapshot is then deleted on each as they in turn achieve a successful replication. We do have some robustness issues to attend to and did in fact have a slightly better setup once before but then an API change in pools forced a partial implementation and we lost some robustness. But as you say you have had some success.
Essentially the current setup is not robust to IP change or a failed replication. But in the latter case one can usually just remove the last sender snapshot of the 3 and the next replication event will work as normal. See the following issue we have open for this failure point:
Not quite your issue but related.
It takes around 5 replication events to achieve the stable state I think. I’ve got some notes on this when I last worked in this area so will do a tecnical wiki to help anyone wishing to contribute to the code in this area. Unfortunately I’ll not have much time for this for a while, at least until we get our re-release out via the newer 4 variant.
Hope that helps at least with a little context.
As for alternatives maybe some folks to chip in but the following has some btrfs based alternatives:
Hope that helps.
I am wondering whether the IP/location change can be made more easily using a script like this:
since it utilizes a configuration file, maybe you just need to change the ssh target (or fake the local one) …