Kurz gesagt: Prüf das Datum der neuesten Datei im Backup, nicht das Datum des Ordners. Der Zeitstempel eines Ordners ändert sich aus Gründen, die nichts mit einem abgeschlossenen Backup zu tun haben.
Wenn die neueste Datei darin älter als gestern ist, lief das Backup nicht, egal was das Tool dir sagt.
Die meisten Backup-Ratschläge drehen sich um die falsche Katastrophe. Sie stellen sich eine dramatische vor: Ein Laufwerk stirbt, ein Laptop wird gestohlen, eine Überschwemmung. Die sind selten, und jeder versteht sie.
Der häufige Fall ist langweilig. Das Laufwerk wurde abgesteckt, um Platz für etwas anderes zu machen, und nie wieder angeschlossen. Das NAS hat nach einem Stromausfall neu gestartet, und die Freigabe wurde nicht wieder eingebunden. Der Laptop war jede Nacht einen Monat lang genau dann zugeklappt, wenn der Job fällig war. Ein Skript ist mit einem Fehler beendet worden, den niemand gelesen hat, weil niemand ein Log liest, das seit einem Jahr in Ordnung ist.
In jedem dieser Fälle ist nichts kaputt. Nirgends, wo ein Mensch hinschaut, erscheint ein Fehler. Der Backup-Ordner ist noch da, noch voller Dateien, noch in der richtigen Größe. Das Einzige, was sich geändert hat: Er wird nicht mehr neuer, und nichts im System hält das für erwähnenswert.
Richte das auf dein Backup-Ziel. Es findet die zuletzt geänderte Datei irgendwo darin und gibt ihr Datum aus:
find /Volumes/Backup -type f -print0 | xargs -0 stat -f '%m %N' | sort -rn | head -5Die erste Spalte ist ein Unix-Zeitstempel. Um ihn direkt zu lesen:
find /Volumes/Backup -type f -newermt '-2 days' | headWenn das nichts ausgibt, wurde seit zwei Tagen nichts geschrieben. Das ist die Antwort, und sie ist vertrauenswürdiger als jede Statusanzeige, weil sie eine Eigenschaft der Dateien selbst ist.
Speziell für Time Machine:
tmutil latestbackupdas den Pfad des neuesten Snapshots ausgibt, mit seinem Datum im Namen, oder einen Fehler, wenn es keinen gibt.
Der Reflex ist, im Finder auf den Backup-Ordner zu schauen und die Spalte „Änderungsdatum“ zu lesen. Diese Zahl ist nicht, was du denkst.
Das Änderungsdatum eines Ordners ändert sich, wenn etwas hinzugefügt oder entfernt wird, nicht wenn sich der Inhalt einer Datei darin ändert. Spotlight-Indizierung, eine neu geschriebene .DS_Store, ein Virenscanner, ein Cloud-Client, der seine eigenen Metadaten anfasst: All das kann einen veralteten Backup-Ordner so aussehen lassen, als sei heute Morgen hineingeschrieben worden.
Die Dateien darin sind der Nachweis. Der Ordner ist es nicht.
launchd-Job mit StartCalendarInterval läuft nicht, während der Mac schläft, und holt es danach nicht nach, außer du hast es verlangt. Ein Laptop, der um Mitternacht zugeklappt wird, hat ein Mitternachts-Backup, das noch nie stattgefunden hat.launchd-Job schreibt seine Beschwerde in eine Datei, und die Datei ist das Einzige, was davon weiß.Wenn du das selbst machst, ist die Lösung ein Totmannschalter: etwas, das sich beschwert, wenn ein Backup nicht stattgefunden hat. Das ist ein anderes Ereignis als ein fehlgeschlagenes, und nur das erste deckt die Fälle oben ab.
Die einfachste Variante ist ein Job, der das Alter der neuesten Datei prüft und Alarm schlägt, wenn sie zu alt ist:
if [ -z "$(find /Volumes/Backup -type f -newermt '-2 days' 2>/dev/null | head -1)" ]; then
osascript -e 'display notification "No backup in two days" with title "Backup"'
fiFühr das nach einem eigenen Zeitplan aus, getrennt vom Backup, damit ein kaputter Backup-Zeitplan nicht auch das kaputt macht, was ihn überwacht. Diesen letzten Punkt machen viele falsch: Eine Prüfung, die im Backup-Job läuft, kann nicht melden, dass der Backup-Job nicht gelaufen ist.
Was du eigentlich willst: Das Ausbleiben soll der Alarm sein, und das Tool soll benennen, was fehlt.
Copy Shelter baut darauf auf. Es verfolgt, wann jedes Ziel zuletzt beschrieben und zuletzt geprüft wurde, und meldet sich nach sieben Tagen ohne funktionierendes Backup. Es nennt den Speicherort, also bekommst du „Das Laufwerk in der Schublade wurde seit dem 14. August nicht gesehen“. Und weil es das Backup zurückliest und jedes Stück mit dem Hash vergleicht, unter dem es gespeichert wurde, wird auch ein Backup erkannt, das läuft, aber unlesbare Daten erzeugt, der Fehler einen Schritt weiter als diese Seite.
Die Punktzahl, die es zeigt, zählt nur, was kürzlich geprüft wurde. Ein Backup, das nicht gelaufen ist, ist kein Backup, das du hast, und die Zahl sagt das.
Das solltest du nicht müssen. Genau darum geht es auf dieser Seite: Eine Prüfung, die du von Hand machst, ist eine Prüfung, mit der du aufhören wirst, meist etwa drei Wochen nach dem Einrichten. Automatisiere den Alarm für das Ausbleiben, und lass die Prüfung von Hand das sein, was du tust, wenn er dich darauf hinweist.
Es hilft, und es ist begrenzt. Time Machine warnt, wenn es zehn Tage lang kein Backup abgeschlossen hat, und die Benachrichtigung lässt sich leicht wegklicken und leicht übersehen. Es kann dir auch nicht sagen, dass das abgeschlossene Backup unlesbar ist, denn auf einem lokalen Laufwerk prüft es das nicht.
Das ist der Berechtigungsfall, und er ist fieser, weil jede Statusanzeige Erfolg meldet. Vergleiche die Anzahl der Dateien am Ziel mit der an der Quelle. Wenn ein Backup, das Zehntausende Dateien enthalten sollte, vierzig enthält, verweigert macOS den Zugriff auf die Ordner, und dem Job wird es nicht gesagt.
Anders, und ja. Sync-Clients melden sich ab, erreichen ihr Kontingent und pausieren sich selbst, und das Symbol, das es dir sagen würde, ist ein kleines Icon in einer Menüleiste, auf die du nicht schaust. Die Dateien bleiben auch genau da, wo sie waren, also sieht nichts falsch aus.
Weitgehend ja. Zwei Ziele, die aus verschiedenen Gründen ausfallen und einzeln geprüft werden, sind mehr wert als jede Menge Überwachung eines einzigen. Überwachung sagt dir, dass die Kopie weg ist, die zweite Kopie heißt, dass es egal war. Siehe die 3-2-1-Regel.
Siehe auch: prüfen, ob ein Backup wirklich lesbar ist und die 3-2-1-Regel.