Jump to content

Sanoid/Syncoid (ZFS snapshots and replication)


Recommended Posts

  • 4 weeks later...
  • 4 weeks later...

@steini84: Looks like mbuffer needs to be updated for UnRaid V7:

 

root@NAS:/boot/config/plugins# find . -name '*mbuffer*'

./unRAID6-Sanoid/packages/mbuffer-20240107-x86_64-1_SBo.tgz

./unRAID6-Sanoid/packages/mbuffer-20240107-x86_64-1_SBo.tgz.md5

root@NAS:/boot/config/plugins# mbuffer -v

mbuffer: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory

 

The stock version of mbuffer that comes with v7 seems to work:

root@NAS:~# mbuffer --version

mbuffer version R20240107

Copyright 2001-2023 - T. Maier-Komor

License: GPLv3 - see file LICENSE

This program comes with ABSOLUTELY NO WARRANTY!!!

Donations via PayPal to [email protected] are welcome and support this work!

Edited by foo_fighter
  • Like 1
  • Upvote 2
Link to comment
9 hours ago, foo_fighter said:

@steini84: Looks like mbuffer needs to be updated for UnRaid V7:

 

root@NAS:/boot/config/plugins# find . -name '*mbuffer*'

./unRAID6-Sanoid/packages/mbuffer-20240107-x86_64-1_SBo.tgz

./unRAID6-Sanoid/packages/mbuffer-20240107-x86_64-1_SBo.tgz.md5

root@NAS:/boot/config/plugins# mbuffer -v

mbuffer: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory

 

The stock version of mbuffer that comes with v7 seems to work:

root@NAS:~# mbuffer --version

mbuffer version R20240107

Copyright 2001-2023 - T. Maier-Komor

License: GPLv3 - see file LICENSE

This program comes with ABSOLUTELY NO WARRANTY!!!

Donations via PayPal to [email protected] are welcome and support this work!

When I check for the mbuffer version I get the same error. Do you happen to have any other packages installed that may have it included? i.e. AutoSlackPack? And/or any tips on repointing to the correct libcrypto.so.1.1.

Link to comment
41 minutes ago, Seriphim said:

When I check for the mbuffer version I get the same error. Do you happen to have any other packages installed that may have it included? i.e. AutoSlackPack? And/or any tips on repointing to the correct libcrypto.so.1.1.

I don't have any other packages that use it, I also checked for any more recent slackware packages for mbuffer but couldn't find any.

 

I fixed it in a very crude way until this plugin can be updated: I uninstalled the plugin and rebooted. Then I copied the default mbuffer bin to save it. I then reinstalled the plugin, which overwrote mbuffer with the incompatible one. Then I copied the saved version back over to get everything working again.

 

Link to comment

The problem is that the version of mbuffer installed by the plugin is not compatible with the new OS version (7.x). This becomes even worse because the OS provides its own mbuffer package, which will in fact get broken by the incompatible package being installed on top of it. I don't know which functions of the OS rely on a (functioning) mbuffer package... so the fallout of this (if left untreated) is entirely unclear at this point.

 

To fix this package problem for now, you can run the following command in a terminal (SSH/WebGUI Terminal):

sed -i '/^mbuffer-20240107-x86_64-1_SBo.tgz/d' /boot/config/plugins/unRAID6-Sanoid.plg

and reboot your system afterwards (you must do this, for the OS to reinstall its own package).

 

The reboot will remove the broken package and the plugin is now patched not to install it again (instead use the one provided with the OS). This solution will "permanently" fix the problem (even through reboots, if you really must use the plugin), at least until you reinstall or update the plugin (it then needs to be reapplied).

 

This is a temporary solution and something the plugin author should fix ASAP, installing a broken package on top of an existing OS package is very bad for several reasons, to the point it may impact stability of the OS itself.


Be advised that even when uninstalling the plugin, you will need to reboot your server for the OS to reinstall the package which was overwritten by this plugin, and this should really be done to ensure smooth operation.

 

If it were my server, I'd make do without this solution and uninstall the plugin (on 7.x) until it is fixed.

Let's hope to hear back from the developer soon, but he's last been online two months ago...

 

CC @Squid (FYI)

Info for the developers: The installed perl package is also semi-broken (it is linked against the now EOL and no longer available OpenSSL version).

perl-5.34.0-x86_64-2_slack15.0: libssl.so.1.1 => not found // libcrypto.so.1.1 => not found (so anything SSL will fail when using that package)

 

Edited by Rysz
  • Like 2
  • Upvote 3
Link to comment
  • 2 weeks later...
Posted (edited)
8 hours ago, dgriff said:

I'm still having issues with this plugin even after removing the problematic mbuffer and reverting to the built-in unraid mbuffer v20240107.  Lots of "cannot send broken pipe" errors.

 

warning: cannot send 'zfsarchive/Storage@autosnap_2024-07-05_02:47:01_hourly': Broken pipe

 

and a critical error after a bunch of pipe errors:

 

CRITICAL ERROR: zfs send -I 'zfsarchive/Storage'@'autosnap_2024-06-25_00:47:02_daily' 'zfsarchive/Storage'@'autosnap_2024-07-05_09:47:01_hourly' | pv -p -t -e -r -b -s 990765088 | lzop | mbuffer -q -s 128k -m 16M | ssh -S /tmp/syncoid-192.168.1.10-1720198988-3554 192.168.1.10 ' mbuffer -q -s 128k -m 16M | lzop -dfc | sudo zfs receive -s -F '"'"'zfsbackup/Storage'"'"' 2>&1' failed: 256 at /usr/local/sbin/syncoid line 889.

 

Yet it all seems to transfer properly, so I think it's just a mbuffer / v7 issue and everything is still syncing properly despite the messages.

 

This seems not a mbuffer package problem, but an intermittent network connection instability during the transfer.

If it were an mbuffer package problem the whole command chain would fail and no transfer would go through at all.

 

Edited by Rysz
Link to comment
Posted (edited)
On 7/7/2024 at 12:33 AM, Rysz said:

 

This seems not a mbuffer package problem, but an intermittent network connection instability during the transfer.

If it were an mbuffer package problem the whole command chain would fail and no transfer would go through at all.

 

Thanks for the reply!

 

[SOLVED]

 

Update - I had to reinstall sanoid a while ago, and it looks like I messed up the config options on my replication target so it was generating snapshots on the target as well as the source.  Of course that will cause issues because it can't have snapshots synced if they're generated on the source and the target.  Which one to believe?  Disabled and gonna see what happens.

 

Edit: seems fine now even between V7 and V6 (both ZFS file systems were created on V6, so don't need to worry about any compatibility issues there).

 

Edited by dgriff
May have figured it out...
Link to comment

i have read the Thread  an saw the Problems with unraid Version 7.x:

This happens when i try to use syncoid from source Unraid 7.0 Beta1 (Servername unraid3) to destination Unraid 6.12.10 (Servername unraid2). Executed from Unraid 6.12.10

 

root@unraid2:~# /usr/local/sbin/syncoid -r --no-sync-snap root@unraid3:nvme/Vms/WindowsADServer hdd/backupDockerVms/WindowsADServer
NEWEST SNAPSHOT: syncoid_unraid2_2024-07-09:02:15:03-GMT02:00
INFO: Sending oldest full snapshot nvme/Vms/WindowsADServer@autosnap_2024-06-01_00:00:01_monthly (~ 35.7 GB) to new target filesystem:
mbuffer: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory
lzop: <stdin>: not a lzop file
0.00 B 0:00:00 [0.00 B/s] [>                                                                                           ]  0%            
cannot receive: failed to read from stream
CRITICAL ERROR: ssh      -S /tmp/syncoid-root@unraid3-1720546099-3596 root@unraid3 ' zfs send  '"'"'nvme/Vms/WindowsADServer'"'"'@'"'"'autosnap_2024-06-01_00:00:01_monthly'"'"' | lzop  | mbuffer  -q -s 128k -m 16M' | mbuffer  -q -s 128k -m 16M | lzop -dfc | pv -p -t -e -r -b -s 38351274272 |  zfs receive  -s -F 'hdd/backupDockerVms/WindowsADServer' failed: 256 at /usr/local/sbin/syncoid line 549.

   

If I understand the thread correctly, this will no longer happen when both servers are on 7.0.x (on the same version).w


Thanks for a feedback
Andi
 

Link to comment
3 minutes ago, andber said:

i have read the Thread  an saw the Problems with unraid Version 7.x:

This happens when i try to use syncoid from source Unraid 7.0 Beta1 (Servername unraid3) to destination Unraid 6.12.10 (Servername unraid2). Executed from Unraid 6.12.10

 

root@unraid2:~# /usr/local/sbin/syncoid -r --no-sync-snap root@unraid3:nvme/Vms/WindowsADServer hdd/backupDockerVms/WindowsADServer
NEWEST SNAPSHOT: syncoid_unraid2_2024-07-09:02:15:03-GMT02:00
INFO: Sending oldest full snapshot nvme/Vms/WindowsADServer@autosnap_2024-06-01_00:00:01_monthly (~ 35.7 GB) to new target filesystem:
mbuffer: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory
lzop: <stdin>: not a lzop file
0.00 B 0:00:00 [0.00 B/s] [>                                                                                           ]  0%            
cannot receive: failed to read from stream
CRITICAL ERROR: ssh      -S /tmp/syncoid-root@unraid3-1720546099-3596 root@unraid3 ' zfs send  '"'"'nvme/Vms/WindowsADServer'"'"'@'"'"'autosnap_2024-06-01_00:00:01_monthly'"'"' | lzop  | mbuffer  -q -s 128k -m 16M' | mbuffer  -q -s 128k -m 16M | lzop -dfc | pv -p -t -e -r -b -s 38351274272 |  zfs receive  -s -F 'hdd/backupDockerVms/WindowsADServer' failed: 256 at /usr/local/sbin/syncoid line 549.

   

If I understand the thread correctly, this will no longer happen when both servers are on 7.0.x (on the same version).w


Thanks for a feedback
Andi
 

 

Did you apply my fixes from above on the 7.0 machine and reboot it after?

Link to comment

After a second reboot i'm online again but array is no more started
image.png.780c93e8295e135c49ce23836a57d17e.png

And boot takes 3 times longer then before ....

Could i undo the change from this line?

sed -i '/^mbuffer-20240107-x86_64-1_SBo.tgz/d' /boot/config/plugins/unRAID6-Sanoid.plg


 

Link to comment
Just now, andber said:

After a second reboot i'm online again but array is no more started
image.png.780c93e8295e135c49ce23836a57d17e.png

And boot takes 3 times longer then before ....

Could i undo the change from this line?

sed -i '/^mbuffer-20240107-x86_64-1_SBo.tgz/d' /boot/config/plugins/unRAID6-Sanoid.plg


 

 

Yes, just uninstall and reinstall the Sanoid plugin and the modification is gone. But that's definitely not related to your problems, the line just disables a package of the plugin and doesn't interact with the system at all, so it should in fact boot faster because it's one less package to be installed as part of the plugin installation.

  • Thanks 1
Link to comment

Hey.

 

I have created a pull request that does not install mbuffer and perl 5.34 (perl 5.38.2 is preinstalled on unraid 7) with the sanoid plugin on unraid 7. I don't have unraid 7 available for testing. Maybe some else can replace the local unRAID6-Sanoid.plg with the one in the PR (https://github.com/Steini1984/unRAID6-Sainoid/pull/6) and test the changes on unraid 7. On unraid 6 it works for me.

 

When this plugin works on unraid 7 the name is misleading, but I don't know if changing the name of a plugin is supported or creating a new one would be easier...

 

Update: The PR is already merged (faster than I expected). Please test the new version (2.2.0c) under unraid 7.

Edited by SoerenS
  • Like 2
  • Thanks 1
Link to comment

it seems also new version of mbuffer avalible : 

20240707:
- fix IPv4 address printing
- listen on IPv6 and IPv4 if possible
- add debug messages for defaults on address family
- build fix for systems without getaddrinfo
- gracefully handle empty address infos

Link to comment
17 hours ago, Masterwishx said:

it seems also new version of mbuffer avalible : 

20240707:
- fix IPv4 address printing
- listen on IPv6 and IPv4 if possible
- add debug messages for defaults on address family
- build fix for systems without getaddrinfo
- gracefully handle empty address infos

 I could build the new version, I have the build env still available from building mbuffer-20240107-x86_64-1_SBo.tgz.

 

But I think this version won't give sanoid any benefit. The last version works well (on my end) and sanoid itself has not been updated (means sanoid won't require any of these changes). Maybe the IPv6 and IPv4 feature is interesting, but for home networks maybe not.

  • Like 1
Link to comment
1 minute ago, SoerenS said:

 I could build the new version, I have the build env still available from building mbuffer-20240107-x86_64-1_SBo.tgz.

 

But I think this version won't give sanoid any benefit. The last version works well (on my end) and sanoid itself has not been updated (means sanoid won't require any of these changes). Maybe the IPv6 and IPv4 feature is interesting, but for home networks maybe not.


Besides, I think it's bad practice for a plugin to install or update packages that are shipped with the OS.

There's usually a reason that the OS is sticking to a specific package version, and it may impair stability.

  • Like 1
Link to comment
40 minutes ago, Rysz said:


Besides, I think it's bad practice for a plugin to install or update packages that are shipped with the OS.

There's usually a reason that the OS is sticking to a specific package version, and it may impair stability.

True, for unraid 7 this is not an option. Would be only feasible for unraid 6, but as mentioned before I don't see a benefit.

  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...