1 Punkte von GN⁺ 2023-06-27 | 1 Kommentare | Auf WhatsApp teilen
  • Auch nach dem Ende der Time Capsule kann man auf einem kleinen stromsparenden Gerät mit Linux günstig selbst ein dauerhaft aktives Backup-Gerät für macOS bauen
  • Der HP t520 für 25 Dollar inklusive Versand bietet mit Dual-Core AMD G-Series, 4 GB RAM, 16 GB M.2 SATA SSD, 1-Gbit/s-Ethernet und USB-3.0-Ports genug für einen Single-Purpose-Server
  • Als Speicher kann man zwischen interner M.2-SATA-SSD und externem USB3-Laufwerk wählen; mit einer 2-TB-2280-M.2-SATA-SSD liegen die Gesamtkosten bei rund 94 Dollar
  • Auf Bodhi Linux wird mit netatalk und avahi-daemon eine AFP-basierte Time-Machine-Freigabe eingerichtet, aber nach der Veröffentlichung wurde ein Hinweis ergänzt, dass AFP deprecated ist und stattdessen Samba genutzt werden sollte
  • Das erste 460-GB-Backup hätte bei 2 Mbit/s rund 21 Tage gedauert, ließ sich aber durch Power Nap, debug.lowpri_throttle_enabled=0 und die Platzierung nahe am Wi‑Fi-AP auf 120 Mbit/s steigern und auf 8 Stunden verkürzen

ThinMachine als Time-Capsule-Ersatz planen

  • Apple Time Machine war 2007 ein Grund für den Umstieg auf den Mac, später wurde dann kabelloses Backup mit der Time Capsule genutzt
  • Die bisherige Time Capsule lief über 10 Jahre und fiel dann aus; macOS zeigte daraufhin ständig Hinweise auf veraltete Backups an
  • Auch nach der Einstellung der Time Capsule durch Apple lässt sich mit einem Linux-Server ein ähnliches Backup-Gerät selbst bauen
  • Für ein Gerät mit nur einer Aufgabe, das immer eingeschaltet bleibt, eignet sich kleine stromsparende Hardware, die in den Netzwerkschrank passt
  • Ein Raspberry Pi wäre ebenfalls möglich gewesen, war damals aber schwer zu bekommen und mit über 80 Dollar plus Gehäuse und Netzteil preislich unattraktiv
  • Als Alternative fiel die Wahl auf einen gebrauchten Thin-Client-PC; ein HP t520 wurde bei eBay für 25 Dollar inklusive Versand gekauft

Hardware und Stromverbrauch des HP t520

  • Die Grundausstattung des HP t520 für 25 Dollar reicht als einfacher Backup-Server völlig aus
    • AMD G-Series GX-212JC Dual-Core-CPU mit 1,2 GHz und Radeon R2E
    • 4 GB DDR3-1600
    • 16 GB M.2 SATA SSD
    • 1-Gbit/s-Ethernet
    • 2× USB 3.0, 4× USB 2.0
    • 2× DisplayPort, 1× VGA
    • Vertikalständer
    • 18,5-V-Netzteil mit Kabel
  • Wi‑Fi ist nicht vorhanden, was neben dem Router im Netzwerkschrank kein Problem war; bei Bedarf kann der freie mini-PCIe-Slot genutzt werden
    • Das Nachrüsten von Wi‑Fi wurde nicht selbst getestet, daher gibt es keine Bestätigung für 100%ige Funktion
  • Der t520 verbraucht im Idle 6 W, sonst etwa 10 W
    • Bei einem angenommenen Strompreis von 0,35 Dollar pro kWh kostet der Dauerbetrieb mit 6 W etwa 19 Dollar pro Jahr
    • Andere Thin Clients wie der HP t610 können wegen älterer Chipsätze im Idle über 10 W verbrauchen
    • Ein Raspberry Pi 4 wurde mit rund 4 W gemessen
  • Das vorinstallierte OS ist HP Thin Pro, eine angepasste Distribution auf Basis von Tiny Core Linux
    • HP Thin Pro enthält Clients für Citrix und VMWare
    • Das originale Tiny Core Linux wurde ebenfalls ausprobiert, bot aber viel zu wenige Pakete

Wahl des Backup-Speichers: interne SSD oder externes USB3

  • Offiziell unterstützt der interne SSD-Slot des t520 nur 64 GB, diese Angabe stammt aber aus einer Zeit ohne größere M.2-SSDs
  • Der interne M.2-Slot unterstützt die Formfaktoren 2242 und 2260; eine 2280-SSD kollidiert standardmäßig mit dem Lautsprecher
    • Der Lautsprecher lässt sich entfernen, indem man das Mainboard anhebt und zwei Schrauben löst
    • Vor dem Einbau einer 2280-SSD müssen die freiliegenden Kupferpads und Leiterbahnen auf der Rückseite der SSD mit Klebeband abgedeckt werden
    • Da keine Befestigungsschraube vorhanden ist, könnte die SSD aus dem Sockel rutschen, wurde in dieser Konfiguration aber nicht als großes Risiko gesehen
  • Der interne Slot des t520 unterstützt nur M.2-SATA-SSDs
    • Große SSDs sind oft NVMe, aber dieser Slot ist nicht für PCIe/NVMe ausgelegt
    • HP hat unglücklicherweise einen Steckverbinder gewählt, in den sich NVMe-SSDs physisch einsetzen lassen
    • Beim Einstecken einer NVMe-SSD könnten die SSD, das Mainboard oder beides beschädigt werden
  • Bei der Wahl des internen Speichers gab es große Unterschiede bei Preis und Formfaktor
    • Eine 2-TB-2260-M.2-SATA-SSD kostete bei Amazon 149 Dollar
    • Eine 2-TB-2280-M.2-SATA-SSD war ab 69 Dollar zu haben
    • Eine 4-TB-2280-SATA-SSD sprang preislich auf 260 Dollar
    • Die gewählte 2-TB-2280-M.2-SATA-SSD funktionierte problemlos; die gesamten Kosten für die 2-TB-ThinMachine lagen bei 94 Dollar
  • Ein externes USB3-Laufwerk ist eine Alternative mit geringerem Installationsaufwand
    • 4-TB-2,5-Zoll-SSDs gibt es ab 150 Dollar, größere Kapazitäten sind ebenfalls möglich
    • Das Laufwerk lässt sich leicht abziehen, lagern oder an einen anderen PC anschließen
    • Der t520 muss nicht geöffnet werden
    • Nachteil sind das nötige USB3-Gehäuse und eine weniger aufgeräumte Optik

Installation von Bodhi Linux und Partitionierung

  • Gesucht war eine Ubuntu-basierte Distribution mit kleinem Installationsimage; gewählt wurde Bodhi Linux
    • Die HWE-Version war mit 837 MB nur 5 MB größer als die Standardversion und unterstützt neuere Hardware besser
    • Der Download der Ubuntu-ISO war langsam, die Bodhi-Linux-ISO ließ sich schnell herunterladen
  • Der Installationsablauf ist ein üblicher USB-Boot-Prozess
    • Einen USB-Stick mit mindestens 1 GB vorbereiten
    • Mit Balena Etcher das ISO-Image auf den USB-Stick schreiben
    • Den USB-Stick in den t520 stecken und booten
    • Dem Installer folgen und Bodhi Linux auf der SSD des t520 installieren
  • Auf der internen SSD werden OS und Backup-Daten getrennt partitioniert
    • /dev/sda1: efi, 1 GB, Boot-Partition und muss die erste Partition sein
    • /dev/sda2: ext4, 16 GB, für die Bodhi-Linux-Installation
    • /dev/sda3: ext4, gesamter verbleibender Platz, Datenpartition für Backups
  • Auch die Mount-Punkte sind klar getrennt
    • /dev/sda2 wird auf das Root-Verzeichnis / gemountet
    • /dev/sda3 wird auf /mnt/timemachine gemountet
  • Nach der Installation belegt Bodhi Linux etwas mehr als 5 GB auf der SSD; mit 16 GB bleibt genug Platz für zusätzliche Tools

Time-Machine-Serverkonto und AFP-Konfiguration

  • Zuerst werden die Pakete auf den neuesten Stand gebracht
sudo apt update && sudo apt dist-upgrade
  • Danach werden die für Time Machine nötigen Pakete installiert
sudo apt install procinfo netatalk avahi-daemon
  • Avahi ist eine Open-Source-Implementierung von Zero-Config-Networking wie Apple Bonjour und sorgt dafür, dass der Mac den ThinMachine-Server im Netzwerk sieht
  • Netatalk ist eine Open-Source-Implementierung des Apple Filing Protocol und unterstützt Apple Time Machine
  • Es wird ein eigenes Konto timemachine angelegt
    • Dieses Konto hat weder root- noch sudo-Rechte und bekommt kein /home-Verzeichnis
    • Beim Verbinden vom Mac mit dem Server werden dieser Benutzername und dieses Passwort verwendet
    • Dieses Passwort dient nicht zur Verschlüsselung der Backup-Daten
sudo useradd --no-create-home timemachine
sudo passwd timemachine
sudo chown timemachine:timemachine /mnt/timemachine/
  • Zur Einrichtung der Time-Machine-Freigabe wird /etc/netatalk/afp.conf bearbeitet
    • Mit vol size limit lässt sich begrenzen, wie viel Speicherplatz das Time-Machine-Backup in MB belegen darf
    • Hier wird das gesamte Laufwerk für Time Machine genutzt, daher wird kein Limit gesetzt
    • hostname muss nicht dem Unix-Hostnamen entsprechen, ist aber der Name, der im Bonjour-Netzwerk angezeigt wird
;
; Netatalk 3.x configuration file
;

[Global]
hostname = thinmachine

[ThinMachine]
path = /mnt/timemachine
time machine = yes
valid users = timemachine
;vol size limit = 500000
  • Danach werden die nötigen Daemons aktiviert und gestartet
sudo systemctl enable avahi-daemon
sudo systemctl start avahi-daemon
sudo systemctl enable netatalk
sudo systemctl start netatalk
  • Anschließend werden die benötigten Firewall-Ports geöffnet und Netatalk neu gestartet
sudo ufw allow 548
sudo ufw allow 427
sudo ufw allow 4700
sudo systemctl restart netatalk
  • Diese Konfiguration ist AFP-basiert; nach der Veröffentlichung wurde ergänzt, dass AFP deprecated ist und stattdessen Samba verwendet werden sollte

Wiederherstellung nach Stromausfall und Verbindung mit dem Mac

  • Da sich die Backup-Appliance nach einem Stromausfall automatisch wieder einschalten soll, wird eine BIOS-Einstellung geändert
    • Beim Start F10 drücken, um das BIOS zu öffnen
    • Zu AdvancedPower-On Options gehen
    • After Power Loss auf On setzen
  • In den Time-Machine-Einstellungen des Mac erscheint ThinMachine nach einem Klick auf Select Disk als auswählbares Ziel
  • Die Verschlüsselung der Backup-Daten erfolgt auf dem Mac; der Thin Client ist weder an Ver- noch Entschlüsselung beteiligt
    • Geht das Backup-Passwort verloren, gibt es keine Möglichkeit zur Wiederherstellung der Daten
  • Das erste Backup kann lange dauern

Geschwindigkeit des ersten Backups verbessern

  • Auf dem MacBook lagen 460 GB Daten, und Time-Machine-Backups sind atomar, also muss bei einem Abbruch wieder von vorn begonnen werden
  • Die anfängliche Backup-Geschwindigkeit lag bei etwa 2 Mbit/s, was rund 21 Tage für das komplette Backup bedeutet hätte
    • In dieser Zeit hätte jedes Aus- und Einschalten des Servers oder das Verlassen des Wi‑Fi-Bereichs durch das Notebook einen Neustart des Backups erzwungen
  • Power Nap wurde auch im Batteriebetrieb aktiviert
    • Mit aktiviertem Power Nap läuft das Time-Machine-Backup weiter, auch wenn das Notebook zugeklappt ist oder auf Akku läuft
    • Ohne Power Nap wird das Backup unterbrochen und später neu gestartet
  • Während des ersten vollständigen Backups wurde die Drosselung von Hintergrundprozessen deaktiviert
sudo sysctl debug.lowpri_throttle_enabled=0
  • Dadurch stieg die Backup-Geschwindigkeit von 2 Mbit/s auf 20 Mbit/s
  • Nach dem ersten vollständigen Backup sollte die Drosselung wieder aktiviert werden
sudo sysctl debug.lowpri_throttle_enabled=1
  • Nachdem das Notebook näher an einen Access Point des Eero-Wi‑Fi-Meshs gestellt wurde, stieg die Geschwindigkeit von 20 Mbit/s auf 120 Mbit/s
  • Durch die geänderte Priorisierung und die Nähe zum AP verkürzte sich die Zeit für das 460-GB-Backup von 21 Tagen auf 8 Stunden

Ergebnis im Einsatz und weitere Möglichkeiten

  • Nach einigen Tagen verschwanden die Warnungen über veraltete Backups auf dem MacBook, und die Backups liefen im Hintergrund zuverlässig
  • Der t520 könnte mit zusätzlichen Laufwerken zu einem NAS ausgebaut werden, es bestand dafür aber kein Bedarf
  • Als Schutz gegen einen Ausfall des internen Laufwerks wäre auch eine regelmäßige vollständige Kopie auf ein externes Laufwerk möglich
  • Da bereits Backblaze als Offsite-Backup-Dienst genutzt wird, wurde die Redundanz als ausreichend angesehen

1 Kommentare

 
GN⁺ 2023-06-27
Hacker-News-Kommentare
  • Ich vertraue Time Machine nicht mehr. Vor ein paar Jahren habe ich ein Shell-Skript erstellt, das mit brew und ähnlichen Tools fast die komplette Systemkonfiguration automatisiert, und gelegentlich setze ich das System komplett neu auf und stelle es mit diesem Skript wieder her
    Für Datensicherungen nutze ich restic. Der große Vorteil ist, dass man die Backups auch ohne ein macOS-Gerät lesen kann. Als mein einziges macOS-Gerät ein Hardwareproblem hatte, war das Time-Machine-Backup praktisch nutzlos, bis ich einen neuen Mac hatte
    Das ist nicht für alle der richtige Ansatz, aber Time Machine hat mir mehr als fünfmal Backups beschädigt und ist im Vergleich zu restic viel zu langsam, sodass ich es auch bei neuen macOS-Releases nicht noch einmal versuchen möchte

    • Wenn du etwas Ähnliches suchst, ist auch Arq [1] einen Blick wert. Wie restic erstellt es inkrementelle verschlüsselte Backups zu den meisten Cloud-Anbietern oder auf per SSH erreichbare Maschinen, ist aber eine Mac-App und dadurch einfach einzurichten und zu pflegen. Datenkorruption hatte ich bisher keine
      Ich bin nur ein Nutzer, der es seit 9 Jahren zufrieden verwendet, nicht geschäftlich damit verbunden
      [1] https://www.arqbackup.com
    • Es gab eine Zeit, in der Time Machine ziemlich gut war, aber Apple hat Time-Machine-Backups immer geschlossener gemacht, sodass man sie nicht einmal mit root-Berechtigung aufräumen kann. Das Aufräumen geht nur noch mit der Time-Machine-App auf dem ursprünglichen Rechner, dem die Datei gehört hat, wodurch es unmöglich geworden ist, als Systemadministrator die Backups der Familie zu verwalten
      Ich nutze inzwischen Carbon Copy Cloner, Syncthing und Arq. Dadurch sind die Familien-Backups schneller, nahtloser und sehr viel einfacher zu verwalten geworden
    • Ich wollte am Wochenende Restic über auto-restic ausprobieren und es unbedingt zum Laufen bringen
      Allerdings gibt es auf macOS zwei Benutzerkonten, meines und das meiner Frau, und ich konnte Restic keinen Zugriff auf die Daten des anderen Kontos geben. Ich bin Administrator, habe es als root ausgeführt und auch „Vollzugriff auf die Festplatte“ gewährt, aber es funktioniert trotzdem nicht. Über Tipps würde ich mich freuen
    • Mich würde interessieren, ob du das Skript teilen kannst. Wenn das nicht geht, wäre auch eine verschleierte oder abstrahierte Version hilfreich
      Selbst mit brew und brew cask gibt es viele GUI-Apps, die manuell installiert werden müssen, und ihre Einstellungen liegen an verschiedenen Orten verstreut. Wenn man dann noch selbst installierte CLI- oder Hintergrund-Tools und die Systemeinstellungen einbezieht, weiß ich nicht, wie man all das sinnvoll automatisiert wiederherstellen soll, ohne auf eine Time-Machine-artige Sicherung, also praktisch ein Disk-Image, zurückzugreifen
    • Mich würde interessieren, ob das Time-Machine-Ziel HFS+ auf CoreStorage, APFS oder SMB ist
      Ich würde auch gern wissen, ob du dieselbe Beschädigung mit der APFS-Version erlebt hast
  • Ich betreibe auf einem Raspberry Pi Pi-hole und Time Machine, und es ist vielleicht das Tech-Produkt mit dem besten Preis-Leistungs-Verhältnis, das ich je gekauft habe. Ich habe https://saschaeggi.medium.com/use-a-raspberry-pi-4-for-time-... befolgt

    • Der Raspberry Pi ist großartig für Elektronik-Hobbyprojekte, aber für diesen Einsatzzweck sehe ich keinen Vorteil gegenüber einem Thin Client
      Er ist teurer, braucht ein separates Gehäuse und Netzteil, man kann ohne zusätzliches USB3-Gehäuse keine M.2-SSD verwenden, es gibt eine Vorgeschichte mit beschädigten Flash-Karten, und auch der Stromverbrauch im Leerlauf ist nur geringfügig niedriger
    • Ich nutze jetzt Synology, habe davor aber einige Jahre lang problemlos einen Pi verwendet
      Ich habe ihn meiner Tochter fürs Studium mitgegeben, aber ich bezweifle stark, dass sie ihn wirklich benutzt hat, und bis ich diesen Beitrag gesehen habe, war ich nicht einmal auf die Idee gekommen, danach zu fragen
    • Dieses Setup wirkt fast identisch, nur dass Thin Client und Pi sowie die genaue Linux-Distribution ausgetauscht wurden. Letztlich ist es ein Abwägen je nach genauen Details wie Preis und Stromverbrauch
  • Um seine geistige Gesundheit zu bewahren, würde ich empfehlen, Time Machine nicht mehr zu benutzen und stattdessen Carbon Copy Cloner [0] zu verwenden. Es funktioniert richtig, funktioniert dauerhaft, die Dokumentation zu möglichen Backup- und Wiederherstellungsszenarien ist hervorragend, und es zeigt transparent, was es tut.
    Time Machine läuft eine Weile gut und irgendwann plötzlich nicht mehr. Dass das Backup kaputt ist, erfährt man erst, wenn man eine Wiederherstellung versucht. Die Fehler sind kryptisch, Support gibt es nicht, die Foren helfen nicht, und ein beschädigtes Backup lässt sich nicht reparieren. Time Machine verfolgt einen "Leck-mich-doch"-Ansatz, bei dem es keinerlei Informationen darüber gibt, was es tut, nicht tut oder zu tun versucht.
    Wenn die Daten es wert sind, gesichert zu werden, sollte man Time Machine nicht verwenden.
    [0] https://bombich.com

    • Ich finde, dass "Time Machine läuft eine Weile gut und irgendwann nicht mehr, man merkt erst beim Wiederherstellungsversuch, dass es kaputt ist, die Fehler sind kryptisch und es gibt keinen Support" sowie dieser "Leck-mich-doch"-Ansatz auf praktisch alle Software und Services von Apple zutreffen.
      Bei iCloud hört man überall nur Antworten wie "Ihre Daten werden synchronisiert", "Schalten Sie es aus und wieder ein" oder "Starten Sie neu". Wenn man sieht, mit welcher Selbstverständlichkeit der Apple Support bei kleinen Synchronisationsproblemen empfiehlt, iOS zurückzusetzen oder macOS komplett neu zu installieren, fühlt es sich an, als würde man mit einem kafkaesken Sadismus-Bot sprechen.
      Das ist Apples Playbook. Öffentliche Kritik in sozialen Medien bringt nichts, auf E-Mails kommt keine Antwort, und Kundenanfragen laufen ins Leere. Manchmal habe ich das Gefühl, als würde ich dafür bezahlt, Apple-Produkte zu benutzen.
      Als ein früherer Manager sagte, dass er bei einem Mac für privat oder beruflich immer als Erstes Linux installiert, hielten ihn die Neuen für einen seltsamen GNU/FOSS-Fanatiker. Er lachte nur und sagte, mit der Zeit würden wir es verstehen, und inzwischen verstehe ich, wie hilflos und feindselig das Apple-Ökosystem ist. Wenn man lange genug gegen Wände rennt und frustrierende Einschränkungen erträgt, gerät man in eine Art Geiselzustand, in dem es sich wie der einzige Weg anfühlt.
      An diesem Punkt halte ich es fast für selbstzerstörerisch, bei Time Machine oder anderen Apple-Funktionen, bei denen Datenintegrität und Zuverlässigkeit auf dem Spiel stehen, zu sagen, sie "funktionieren" oder seien "gut genug", oder sich bei Datensicherung und Integrität auf so etwas wie iCloud zu verlassen.
      Ich warte auf den Tag, an dem Dateizugriff unter ausdrücklicher Zustimmung auf iOS einfacher wird oder Android weniger schlecht ist. Letztlich muss man diese glorreiche Duopol-Landschaft wohl dazu zwingen, die Plattformen zu öffnen; freiwillig werden sie es nicht tun.
    • CCC kostet bei jeder Hauptversion erneut eine App-Gebühr von 77.50 AUD; das mag noch okay sein, ist aber ziemlich teuer.
      Time Machine ist kostenlos und für die meisten Menschen für lokale oder lokale Netzwerk-Backups "gut genug". Für Remote-Backups sind BorgBase, Vorta als GUI-App für borg, obwohl furchtbar, und Backblaze einigermaßen tragbare Optionen.
      Außerdem scheint CCC keine schreibgeschützten, nach der Erstellung clientseitig unveränderlichen Backups wie Borg zu haben, und in der Feature-Liste sehe ich auch weder Verschlüsselung noch Deduplizierung. https://bombich.com/features
    • Ich habe über Jahre hinweg sowohl CCC als auch SuperDuper verwendet, um bootfähige Backups zu erstellen, aber immer zusammen mit Time Machine.
      Inzwischen sichere ich per Time Machine sowohl auf einen TrueNAS-Server als auch auf eine lokale Festplatte, allerdings nur, wenn ich daran denke, sie anzuschließen. Mein Home-Verzeichnis sichere ich mit Arq nach B2.
      Für die Familie lasse ich Backblaze verwenden. Das war wirklich der einzige Weg, den man einfach einrichten und dann vergessen konnte. Die Familienmitglieder vergessen immer, das lokale Time-Machine-Laufwerk anzuschließen, und wenn man Time Machine auf einem Netzlaufwerk einrichtet, wird es alle paar Monate merkwürdig, sodass sie die Meldung von Time Machine, dass kein Backup durchgeführt wird, einfach ignorieren.
      Backblaze funktioniert fast einfach so und verschickt auch wöchentliche E-Mail-Berichte. Eine vollständige Wiederherstellung wäre wohl etwas schmerzhaft, aber immer noch besser als gar kein Backup.
    • Die meisten seltsamen Probleme mit Time Machine stammen nach einer Migration zwischen Rechnern von Metadaten-Inkonsistenzen.
      Ich habe ein relativ einfaches Shell-Skript erstellt, um das zu beheben.
      https://github.com/torstenvl/tmutils
      Es ist noch ziemlich beta, also sollte man es mit Vorsicht verwenden. Für größere Änderungen an Metadaten gibt es Bestätigungsschritte, und das Skript dirdedupe läuft standardmäßig im Testmodus. Damit tatsächlich etwas passiert, muss man das Flag --execute verwenden.
    • Ich nutze auch CCC, aber zusammen mit Time Machine auf einer winzigen SD-Karte, die bündig im Laptop sitzt. https://www.bhphotovideo.com/c/product/1687325-REG/transcend...
      CCC ist großartig, macht aber keine Backups nahezu in Echtzeit und verwaltet auch keine Versionen. Es hätte mich also nicht so retten können wie das "eingebaute" Time Machine auf dem SD-Slot letzten Freitag unterwegs.
  • Auffällig ist, dass der Autor für 25 Dollar 16 GB Speicher bekommen hat und dann weitere 70 Dollar ausgegeben hat, um auf 2 TB aufzurüsten
    Für GNU/Linux-Nutzer ist eine Kombination sinnvoll, die natürlich auch mit Microsoft- und Apple-Clients gut funktionieren dürfte: Syncthing auf lokalen und entfernten Mini-Servern und BorgBackup nur serverseitig
    Syncthing bietet eine nahezu sofortige Synchronisierung, und BorgBackup liefert regelmäßige Archive nach dem gewünschten Intervall und der gewünschten Aufbewahrungsrichtlinie
    Zur Isolation gab es für jedes Familienmitglied eine kleine VM, und wirklich wichtige Dinge sollten in den verwalteten Verzeichnissen ~/work/ oder ~/private/ abgelegt werden

    • Solche Geräte bekommt man heute teilweise schon für etwa 10 Dollar, ich habe 2020 noch 25 Dollar bezahlt
      Interessanterweise unterstützt die APU AES-NI und hat auch einen kleinen Krypto-Beschleuniger für SHA. Das steht im Kontrast dazu, dass Raspberry Pi nicht noch 1 Dollar mehr für Armv8 Cryptography Extensions ausgegeben hat
      Bei derselben Leerlaufleistung von 6,5 W und doppelt so vielen Kernen empfehle ich eher den t620 als den t520
      Wenn 2 Kerne ausreichen, ist auch der Fujitsu Futro s520 gut
      https://heap.ovh/tag/thin-client.html
  • Ich bin mir nicht sicher, ob es wirklich richtig ist, AFP über Netatalk zu verwenden. Soweit ich weiß, bevorzugt das aktuelle „native“ Time Machine im Netzwerk eher CIFS/Samba

    • Stimmt
      „Wenn Sie zwischen SMB und AFP wählen können, verwenden Sie SMB für externe Backup-Festplatten“
      https://support.apple.com/guide/mac-help/types-of-disks-you-...
    • Trotz Warnungen zur eingestellten Unterstützung war Netatalk über mehrere Jahre hinweg immer noch die verlässlichere Lösung. Mit der aktuellen Konfiguration aus ZFS und Samba 4.15.13 auf Ubuntu 22.04 nutze ich es ebenfalls ziemlich gut, aber ich denke, dass Netatalk auch weiterhin noch gut funktioniert
    • Ich habe oben im Blogpost eine Warnung ergänzt und will mir das nächstes Wochenende noch einmal ansehen
  • Der Ansatz „Keine Sorge. Ich nutze für automatische externe Backups auch BackBlaze, und alle Projekte liegen zusätzlich auf GitHub und auf mehreren PCs“ ist klug
    In 20 Jahren hatte ich 7 schwerwiegende Laufwerksausfälle, 4 davon in der Zeit, als ich selbst gebaute Backups verwendet habe. Weil ich faul und nachlässig war, habe ich bei 2 davon viele Daten verloren. Selbst gebaute Backup-Lösungen passen für mich nicht

  • Der Artikel wirkt so, als sei er heute geschrieben worden, aber wichtig ist, dass der darin erwähnte Mac ein 5 Jahre altes macOS ausführt. Aus der Sicht von jemandem, der eine ähnliche Konfiguration eine Zeit lang mit einem Raspberry Pi betrieben hat, halte ich das inzwischen nicht mehr für eine gute Idee
    Wenn man Time Machine heute verwendet, sollte auf ein APFS-Volume mit Snapshots gesichert werden. Das ist deutlich schneller und zuverlässiger als eine HFS+-Festplatte. Ich würde es auch deshalb nicht mehr empfehlen, weil macOS die Unterstützung für neue HFS+-Backups irgendwann ganz einstellen könnte
    Das Problem ist, dass es praktisch keinen APFS-Treiber für Linux gibt, dem man genug vertrauen könnte, um sich bei Backups darauf zu verlassen. Daher ist die realistische Wahl, einen Mac dafür zu haben. In meinem Netzwerk hängt ein altes MacBook Pro, eines der letzten Modelle vor der Touch Bar, per Kabel am Backbone. Es ist teuer, aber man kann davon ausgehen, dass diese Konfiguration die gewünschte ist
    Nebenbei gesagt würde ich bei Time Machine über Netzwerkfreigaben empfehlen, zusätzlich ein weiteres Backup für den „schlimmsten Fall“ zu haben, das regelmäßig erneuert wird. Netzlaufwerke sind bequem und gut für regelmäßige Backups und schnellen Zugriff, aber gelegentlich kann Time Machine sich selbst so beschädigen, dass es das nicht mehr selbst reparieren kann

    • Wenn Time Machine über das Netzwerk sichert, erstellt es ein Disk-Image und schreibt dort hinein. Deshalb verstehe ich nicht, warum dafür unter Linux ein APFS-Treiber nötig sein sollte
    • Dieser Artikel wurde auf einem 2012 MacBook Pro mit Mojave geschrieben. Das Ersatz-MacBook-Air 15” kann in einer Woche abgeholt werden
  • Eine weitere günstige Netzwerk-Time-Machine-Lösung ist ein gebrauchter Intel Mac Mini. Ein Modell mit 2,5 GHz Intel i5, 8 GB RAM und 256 GB SSD kostet etwa 120 Dollar, und man muss ihn nur so einrichten, dass er die Time-Machine-Festplatte im Netzwerk bereitstellt
    Es ist nicht nur ein „echtes“ Time Machine, man kann auch Backups auf bestehenden Time-Machine-Festplatten fortsetzen, die früher direkt angeschlossen waren. Man muss nichts Neues lernen

  • Mein primäres Time-Machine-Backup, für mein MBP und das meiner Frau, läuft per SMB auf ZFS RAIDZ2 auf einem NAS. Das funktioniert seit etwa 2 Jahren ziemlich gut
    Die Probleme, die ich hatte, schienen mit Platzmangel durch die gesetzte Quota zusammenzuhängen. Wegen der ZFS-Snapshots hat der automatische Bereinigungsmechanismus von Time Machine den Speicherplatz nicht wie erwartet freigegeben. Zum Glück konnte ich per ZFS-Rollback einen letzten funktionierenden Snapshot finden, alte ZFS-Snapshots manuell löschen, um Platz zu schaffen, dann die Time-Machine-Überprüfung laufen lassen und weiterverwenden. Davor habe ich zusätzlich manuell einen Snapshot zur „Bestätigung der Funktionsfähigkeit“ erstellt
    Kürzlich habe ich die Einstellung ZFS refquota entdeckt, und sie scheint den oben beschriebenen Aufwand zu beseitigen und dafür zu sorgen, dass die Quota so funktioniert, wie Time Machine es erwartet. Natürlich wird durch ZFS-Snapshots zusätzlicher Platz verbraucht, aber die Time-Machine-Daten sind nur ein kleiner Teil des gesamten Speicherplatzes des Arrays, daher ist das in Ordnung
    Ein weiteres Problem waren Kernel-Upgrades und dkms beim Einsatz von ZFS unter Arch, aber seit dem Wechsel zu NixOS ist es stabil. Time-Machine-Backups über Tailscale sind ebenfalls ziemlich gut
    Zusätzlich habe ich ein zweites Time-Machine-Backup auf einem USB-Laufwerk, das an eine AirPort Extreme angeschlossen ist
    Auf demselben NAS nutze ich außerdem restic für plattformübergreifende Backups, und dieses NAS sendet ZFS-Snapshots der Time-Machine- und restic-Daten an einen entfernten Server
    Schließlich habe ich noch ein USB-Laufwerk im Safe und hole es etwa einmal im Monat heraus, um manuell ein lokal angeschlossenes Time-Machine-Backup durchzuführen
    Alle Daten gesichert zu haben, war halb im Scherz, halb im Ernst Teil des Eheversprechens. Es stand viel auf dem Spiel

  • Der Hauptgrund, warum ich den Link geöffnet habe, war zu sehen, welches Thin-Client-Modell der Autor ausgewählt hatte, und es war zufällig ein HP T520, von dem ich selbst eines besitze.
    Zu Time Machine kann ich nichts sagen, aber in Kombination mit Linux war die Hardware ein stabilerer Server als ähnliche Raspberry-Pi- oder Odroid-Einplatinencomputer. Sie verbrauchte auch nicht wesentlich mehr Strom, war nur größer.