Time machine backup on SMB share

    • OMV 4.x
    • geaves wrote:

      could that write up be used in the same way but for OMV? Or is there something within that process that would fail.
      Unfortunately the whole write up is a fail since it only tries to cope with creating backups (using the pretty unreliable tmutil setdestination method). This tutorial totally ignores two things:

      • why we do backup: to be able to (do a full) restore. This won't work with such a hack since the share is not announced automagically in the network. So once your Mac's drive died you won't be able to restore from your backup unless you're an expert. Everything that requires special knowledge or manual work around backup is bad
      • it also ignores reliability. An SMB server doing TM backups must at least support the F_FULLFSYNC Extension to reliably store backups. Otherwise data corruption will happen anyway. So trying this prior to Samba 4.8 is a horribly bad idea


      The web is full of dangerous TM tutorials and confusion (like the one spread here, not understanding that TM over AFP still works flawlessly). It started back with OS X 10.5 when people proposed ugly hacks to make TM work over SMB, NAS vendors like Synology advertised TM capabilities without using an appropriate Netatalk version supporting the recently introduced new AFP calls and so on. Then people loose data, forget about these complicated hacks but of course the tutorials remain...
    • tkaiser wrote:

      Works as expected, restore and disaster recovery included.
      That is interesting. Mine looks just the same.
      OMV

      Source Code

      1. root@korostorage:~# afpd -V
      2. afpd 3.1.9 - Apple Filing Protocol (AFP) daemon of Netatalk
      3. This program is free software; you can redistribute it and/or modify it under
      4. the terms of the GNU General Public License as published by the Free Software
      5. Foundation; either version 2 of the License, or (at your option) any later
      6. version. Please see the file COPYING for further information and details.
      7. afpd has been compiled with support for these features:
      8. AFP versions: 2.2 3.0 3.1 3.2 3.3 3.4
      9. CNID backends: dbd last tdb
      10. Zeroconf support: Avahi
      11. TCP wrappers support: Yes
      12. Quota support: Yes
      13. Admin group support: Yes
      14. Valid shell checks: Yes
      15. cracklib support: Yes
      16. EA support: ad | sys
      17. ACL support: Yes
      18. LDAP support: Yes
      19. D-Bus support: No
      20. Spotlight support: No
      21. DTrace probes: No
      22. afp.conf: /etc/netatalk/afp.conf
      23. extmap.conf: /etc/netatalk/extmap.conf
      24. state directory: /var/lib/netatalk/
      25. afp_signature.conf: /var/lib/netatalk/afp_signature.conf
      26. afp_voluuid.conf: /var/lib/netatalk/afp_voluuid.conf
      27. UAM search path: /usr/lib/netatalk//
      28. Server messages path: /var/lib/netatalk/msg/
      Display All
      Mac

      Source Code

      1. merula-pc:~ lars$ sudo sw_vers
      2. Password:
      3. ProductName: Mac OS X
      4. ProductVersion: 10.13.6
      5. BuildVersion: 17G65
      6. merula-pc:~ lars$ sudo tmutil destinationinfo
      7. ====================================================
      8. Name : backup
      9. Kind : Network
      10. URL : afp://lars@korostorage._afpovertcp._tcp.local./backup
      11. ID : F8597DEE-F8CD-40ED-85DF-2D5877383F58
      Display All
      I did not modified the default settings, neither for AFP in general nor for the share itself. The only change in the share is that I enabled the time machine support. The share resides on an LUKS-encrypted RAID-5 of the OMV but that should not make any difference, shouldn't it?
      I also tried to connect the share with user credentials from OMV as well as a guest (with guest read and write access enabled). Make no difference. Any more hints what I could try?
    • Perhaps there are clues in my experience this week:

      My TM has not been working on two servers. I just stopped using it. With @tkaiser asserting that it works; I decided to reinstall the plugin. It did not work. I then thought about wether this may be a file system issue. I have UnionFS which is actually mergerfs holding together my data that resides on multiple EXT4 formatted drives. I then started to recall all the adjustments I had to do if I wanted to have my PlexDB on my fused volume. So I made the same adjustments to the /ect/fstab that I need to to use that volume to hold my Plex transcode directory and PlexDB. TimeMachine now sort of works — I have to investigate if I am really having issues with multiple clients using the same volume to TM their Macs.


      defaults,allow_other,use_ino,dropcacheonclose=true,func.getattr=newest


      github.com/trapexit/mergerfs
      OMV 4.x on intel
    • ajaja wrote:

      TimeMachine now sort of works

      Apple invented an own AFP call for TimeMachine back at 10.5 times and did the same with SMB defining a new SMB Extensions for the simple reason to sync data to disk without having layers in between that do not do this (keep data cached). I would never use any FUSE based filesystem for my TM shares. Never!

      My choices are either ZFS or btrfs since those CoW filesystems allow for snapshot creation so you can always revert back to older snapshots if your sparse bundle gets corrupted. With btrfs a recent kernel and also a recent Debian version is important (since older Debian releases ship with a horribly outdated btrfs-tools package that will cause more harm than do any good if you need to query/repair btrfs filesystems)