Kort svar: kontrollera datumet på den nyaste filen i säkerhetskopian, inte datumet på mappen. En mapps tidsstämpel ändras av skäl som inte har något att göra med att en säkerhetskopiering blev klar.
Om den nyaste filen i den är äldre än i går har säkerhetskopieringen inte körts, vad verktyget än säger.
De flesta råd om säkerhetskopiering handlar om fel katastrof. De föreställer sig en dramatisk: en disk dör, en bärbar dator blir stulen, en översvämning. Sådant är ovanligt och alla förstår det.
Det vanliga fallet är tråkigt. Enheten kopplades ur för att ge plats åt något annat och kom aldrig tillbaka. Din NAS startade om efter ett strömavbrott och delningen monterades inte om. Den bärbara datorn var stängd i samma stund som jobbet skulle köras, varje natt, i en månad. Ett skript avslutades med ett fel som ingen läste eftersom ingen läser en logg som har varit okej i ett år.
I vart och ett av fallen är inget trasigt. Inget fel visas någonstans där en människa tittar. Säkerhetskopierings- mappen finns kvar, fortfarande full av filer, fortfarande rätt storlek. Det enda som har ändrats är att den slutade bli nyare, och inget i systemet anser att det är värt att nämna.
Peka det här mot målet för din säkerhetskopia. Det hittar den senast ändrade filen var som helst i den och skriver ut dess datum:
find /Volumes/Backup -type f -print0 | xargs -0 stat -f '%m %N' | sort -rn | head -5Den första kolumnen är en Unix-tidsstämpel. För att läsa den direkt:
find /Volumes/Backup -type f -newermt '-2 days' | headOm det inte skriver ut något har inget skrivits på två dagar. Det är svaret, och det är mer pålitligt än någon statusskärm, eftersom det är en egenskap hos filerna själva.
Specifikt för Time Machine:
tmutil latestbackupsom skriver ut sökvägen till den nyaste ögonblicksbilden, med datumet i namnet, eller ett fel om det inte finns någon.
Instinkten är att titta på säkerhetskopieringsmappen i Finder och läsa kolumnen Ändrad. Den siffran är inte vad du tror.
En mapps ändringstid ändras när något läggs till eller tas bort i den, och inte
när innehållet i en fil i den ändras. Spotlight-indexering, en .DS_Store som
skrivs om, en virusskanner, en molnklient som rör sina egna metadata: vad som helst av detta kan få en
inaktuell säkerhetskopieringsmapp att se ut som om den skrevs till i morse.
Filerna inuti är beviset. Mappen är det inte.
launchd-jobb med
StartCalendarInterval körs inte medan Macen är i vila, och tar inte igen det
efteråt om du inte bad om det. En bärbar dator som stängs vid midnatt har en midnattssäkerhetskopiering som
aldrig en enda gång har skett.launchd-jobb skriver sitt klagomål till en fil, och filen är det enda som
vet.Gör du det här själv är lösningen ett dödmansgrepp: något som klagar när en säkerhetskopiering inte har skett. Det är en annan händelse än att en misslyckas, och bara den första täcker fallen ovan.
Den enklaste varianten är ett jobb som kontrollerar åldern på den nyaste filen och larmar om den är för gammal:
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"'
fiKör det enligt ett eget schema, separat från säkerhetskopieringen, så att ett trasigt schema för säkerhetskopieringen inte också slår ut det som bevakar den. Den sista punkten är den folk gör fel: en kontroll som körs inuti säkerhetskopieringsjobbet kan inte rapportera att jobbet inte kördes.
Det du egentligen vill är att frånvaron ska vara larmet, och att verktyget ska namnge det som saknas.
Copy Shelter bygger på det. Den håller koll på när varje mål senast skrevs till och senast kontrollerades, och säger till efter sju dagar utan en säkerhetskopiering som fungerade. Den namnger platsen, så du får "enheten i lådan har inte setts sedan 14 augusti". Och eftersom den läser tillbaka säkerhetskopian och kontrollerar varje del mot den hash den lagrades under fångas också en säkerhetskopiering som körs men ger oläsligt resultat, vilket är felet ett steg bortom den här sidan.
Poängen den visar räknar bara det som har verifierats nyligen. En säkerhetskopia som inte har körts är ingen säkerhetskopia du har, och siffran säger det.
Det ska du inte behöva. Det är hela poängen med sidan: en kontroll du gör för hand är en kontroll du kommer att sluta göra, oftast ungefär tre veckor efter att du började. Automatisera larmet för uteblivna säkerhetskopior, och låt kontrollen för hand vara det du gör när det säger till.
Det hjälper, och det är begränsat. Time Machine varnar när den inte har slutfört en säkerhetskopiering på tio dagar, och meddelandet är lätt att avfärda och lätt att sluta lägga märke till. Den kan inte heller säga att säkerhetskopian den slutförde är oläslig, eftersom den inte kontrollerar på en lokal disk.
Det är behörighetsfallet, och det är elakare eftersom varje statusindikator säger att allt gick bra. Jämför antalet filer i målet med antalet i källan. Om en säkerhetskopia som borde innehålla tiotusentals filer innehåller fyrtio vägrar macOS åtkomst till mapparna och jobbet får inte veta det.
På ett annat sätt, och ja. Synkklienter loggar ut, når sin kvot och pausar sig själva, och symbolen som skulle tala om det är en liten ikon i en menyrad du inte tittar på. Filerna ligger också kvar precis där de var, så inget ser fel ut.
Till stor del, ja. Två mål som går sönder av olika skäl, kontrollerade var för sig, är värda mer än hur mycket övervakning som helst av ett. Övervakning säger att kopian är borta; den andra kopian betyder att det inte spelade någon roll. Se 3-2-1-regeln.
Relaterat: kontrollera att en säkerhetskopia faktiskt går att läsa, och 3-2-1-regeln.