Kort antwoord: controleer de datum van het nieuwste bestand in de backup, niet de datum van de map. De tijdstempel van een map verandert om redenen die niets te maken hebben met een voltooide backup.
Is het nieuwste bestand erin ouder dan gisteren, dan heeft de backup niet gedraaid, wat de tool je ook vertelt.
Het meeste backupadvies gaat over de verkeerde ramp. Het stelt zich een dramatische voor: een schijf gaat kapot, een laptop wordt gestolen, een overstroming. Die zijn zeldzaam en iedereen begrijpt ze.
De gewone is saai. De schijf werd losgekoppeld om ruimte te maken voor iets anders en kwam nooit terug. De NAS herstartte na een stroomstoring en de share werd niet opnieuw gekoppeld. De laptop was dicht op het moment dat de taak moest draaien, elke nacht, een maand lang. Een script stopte met een fout die niemand las, omdat niemand een log leest dat al een jaar in orde is.
In al die gevallen is niets kapot. Nergens waar iemand kijkt, verschijnt een fout. De backupmap is er nog, nog steeds vol bestanden, nog steeds de juiste grootte. Het enige dat veranderd is, is dat hij niet meer nieuwer werd, en niets in het systeem vindt dat het vermelden waard.
Richt dit op je backupbestemming. Het vindt het meest recent gewijzigde bestand ergens daarin en toont de datum:
find /Volumes/Backup -type f -print0 | xargs -0 stat -f '%m %N' | sort -rn | head -5De eerste kolom is een Unix-tijdstempel. Om hem direct te lezen:
find /Volumes/Backup -type f -newermt '-2 days' | headToont dat niets, dan is er in twee dagen niets geschreven. Dat is het antwoord, en het is betrouwbaarder dan elk statusscherm, want het is een eigenschap van de bestanden zelf.
Specifiek voor Time Machine:
tmutil latestbackupen dat toont het pad van de nieuwste snapshot, met de datum in de naam, of een fout als er geen is.
De neiging is om in Finder naar de backupmap te kijken en de kolom Wijzigingsdatum te lezen. Dat getal is niet wat je denkt.
De wijzigingstijd van een map verandert als er iets aan wordt toegevoegd of uit wordt verwijderd, en niet als de inhoud van een bestand erin verandert. Spotlight-indexering, een .DS_Store die opnieuw wordt geschreven, een virusscanner, een cloudprogramma dat zijn eigen metadata aanraakt: elk daarvan kan een verouderde backupmap eruit laten zien alsof er vanochtend naar is geschreven.
De bestanden erin zijn het bewijs. De map niet.
launchd-taak met StartCalendarInterval draait niet terwijl de Mac slaapt, en haalt het daarna niet in tenzij je daarom vroeg. Een laptop die om middernacht dicht is, heeft een middernachtbackup die nog nooit is gebeurd.launchd-taak schrijft de klacht naar een bestand, en dat bestand is het enige dat het weet.Doe je dit zelf, dan is de oplossing een dodemansknop: iets dat klaagt als een backup niet is gebeurd. Dat is iets anders dan een backup die mislukt, en alleen het eerste dekt de gevallen hierboven.
De eenvoudigste versie is een taak die de leeftijd van het nieuwste bestand controleert en alarm slaat als het te oud is:
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"'
fiDraai dat volgens een eigen schema, los van de backup, zodat een kapot backupschema niet ook kapotmaakt wat erover waakt. Dat laatste punt doen mensen fout: een controle die binnen de backuptaak draait, kan niet melden dat de backuptaak niet draaide.
Wat je echt wilt, is dat de afwezigheid het alarm is, en dat de tool noemt wat er ontbreekt.
Copy Shelter is daarop gebouwd. Het houdt bij wanneer naar elke bestemming voor het laatst is geschreven en wanneer die voor het laatst is gecontroleerd, en het meldt zich na zeven dagen zonder een geslaagde backup. Het noemt de locatie, dus je krijgt "de schijf in de la is sinds 14 augustus niet gezien". En omdat het de backup terugleest en elk stuk controleert tegen de hash waaronder het is opgeslagen, wordt ook een backup die draait maar onleesbare uitvoer maakt opgemerkt, en dat is het defect één stap verder dan deze pagina.
De score die het toont, telt alleen wat recent is gecontroleerd. Een backup die niet heeft gedraaid, is geen backup die je hebt, en het getal zegt dat ook.
Dat zou niet nodig moeten zijn. Daar gaat deze pagina over: een controle die je met de hand doet, is een controle waarmee je stopt, meestal zo'n drie weken nadat je hem instelde. Automatiseer het alarm bij afwezigheid, en controleer met de hand wanneer dat alarm het je zegt.
Het helpt, en het is begrensd. Time Machine waarschuwt pas als het tien dagen geen backup heeft voltooid, en de melding is makkelijk weg te klikken en makkelijk om niet meer op te merken. Het kan je ook niet vertellen dat de backup die het wel voltooide onleesbaar is, want op een lokale schijf controleert het niet.
Dat is het geval met de toestemmingen, en dat is venijniger omdat elke statusindicator succes meldt. Vergelijk het aantal bestanden op de bestemming met het aantal in de bron. Bevat een backup die tienduizenden bestanden zou moeten hebben er veertig, dan weigert macOS toegang tot de mappen en hoort de taak dat niet.
Anders, en ja. Syncprogramma's loggen uit, lopen tegen hun quotum aan en pauzeren zichzelf, en het badge dat het je zou vertellen, is een klein icoontje in een menubalk waar je niet naar kijkt. De bestanden blijven ook precies waar ze waren, dus niets lijkt mis.
Grotendeels wel. Twee bestemmingen die om verschillende redenen falen en apart worden gecontroleerd, zijn meer waard dan elke hoeveelheid bewaking op één. Bewaking vertelt je dat de kopie weg is; de tweede kopie betekent dat het niet uitmaakte. Zie de 3-2-1-regel.
Verwant: controleren of een backup echt leesbaar is, en de 3-2-1-regel.