APFS: fsroot tree non è valido dopo il backup di Time Machine: come recuperare ed evitare in futuro?

6

Sistema

MacBook Pro, fine 2013, SSD da 1 TB (nuovo di zecca, recentemente sostituito da Apple), APFS (senza registrazione, senza distinzione tra maiuscole e minuscole), High Sierra 10.13.2, Time Machine per la rete HDD.

Che cosa è successo

  • Mac ha smesso di funzionare, no space left on device .
  • Riavvio non riuscito.
  • Ho provato ad avviare in modalità di ripristino con Command-R ed eseguito First Aid da Utility Disco - non riuscito, perché apparentemente il sistema di recupero risiede anche sullo stesso disco, il che sembra rendere impossibile fsck su APFS.
  • Si è tentato di cancellare manualmente alcuni file tramite rm , ottenuto no space left on device
  • Si è tentato di troncare manualmente alcuni file tramite cat /dev/null > somefile , ottenuto no space left on device
  • È stato avviato in modalità di ripristino con Shift-Command-R (scarica il sistema da Internet) e ha eseguito nuovamente First Aid . Questa volta con un successo limitato:

    ** Checking volume.
    ** Checking the container superblock.
    ** Checking the EFI jumpstart record.
    ** Checking the space manager.
    ** Checking the object map.
    ** Checking the APFS volume superblock.
    ** Checking the object map.
    error: invalid dstream.size (10730881024), is greater than dstream.alloced_size (71151616)
    error: xf : INO_EXT_TYPE_DSTREAM : invalid dstream
    error: inode_val: object (oid 0x16309a1): invalid xfields
    ** Checking the fsroot tree.
       fsroot tree is invalid.
    ** The volume /dev/rdisk2s1 could not be verified completely.
    

Quindi apparentemente l'albero fsroot non è valido. Ho cercato, ma non sono stato in grado di trovare alcun consiglio utilizzabile su come risolvere questo problema (eccetto ovviamente, riformattare e ripristinare dal backup, cosa che vorrei evitare).

Informazioni di background aggiuntive

Sul sistema si trova una macchina virtuale Windows di Parallels con un hard disk virtuale da 100 GB (sì, un grande file), che è stato usato di recente (quindi era necessario un backup). L'ultima volta che ho usato il computer, circa 20 GB erano ancora liberi su macOS SSD. Per circa un giorno, i backup di Time Machine non sono stati completati, ma non è stato visualizzato alcun messaggio di errore. Quando il problema si è verificato, avevo lasciato la macchina accesa tutta la notte per completare un backup incrementale di Time Machine. La connessione qui è che Time Machine apparentemente utilizza snapshot APFS. Sospetto che questa sia la causa principale del perché questo pasticcio sia successo.

Domande

  1. C'è un modo per risolvere questo problema (senza riformattare e ripristinare dal backup)?
  2. Qual è il modo migliore per evitarlo in futuro (soprattutto per quanto riguarda Time Machine)?

Grazie.

Aggiornamento

Quando si esegue fsck_apfs con il flag di debug -d , l'output contiene un po 'più di informazioni:

** Checking volume.
** Checking the container superblock.
** Checking the EFI jumpstart record.
** Checking the space manager.
** Checking the object map.
** Checking the APFS volume superblock.
** Checking the object map.
error: invalid dstream.size (10730881024), is greater than dstream.alloced_size (71151616)
error: xf : INO_EXT_TYPE_DSTREAM : invalid dstream
error: inode_val: object (oid 0x16309a1): invalid xfields
obj-id: 23267745 type: Inode      
private-id: 23267745 parent-id: 12896552 cr/mtime: 1515089959653928186/1515090145416398252 
def-prot-class: 0 
uid/gid/mode: 0/0/0x8180 bsd_flags: 0x0 internal_flags: 0x8280 name: NO-NAME
** Checking the fsroot tree.
   fsroot tree is invalid.
** The volume /dev/disk2 could not be verified completely.
    
posta hendrik 05.01.2018 - 09:59
fonte

1 risposta

3

Mi sono imbattuto in un problema simile. Probabilmente avresti scoperto che il problema era in uno dei file per Parallels VM - almeno questo era il colpevole nel mio caso. Il tuo controllo fsck_apfs -d /disk/<disk> restituito:

obj-id: 23267745 type: Inode

Se avessi aperto il terminale avresti potuto ottenere il percorso del file (o dei file) usando quell'inode usando il seguente comando:

find / -inum 23267745

Da lì avresti saputo quali file devono essere ripristinati invece di eseguire un ripristino completo.

Nel mio caso il file VM era disponibile solo nello snapshot mentre escludo i miei VM da TimeMachine. Ho ripristinato solo quel file da una precedente istantanea e ho ottenuto ulteriori informazioni attraverso fsck_apfs: ha ottenuto attraverso il disco il controllo delle istantanee e poi ha bombardato lo stesso file nella seconda istantanea. Fortunatamente le istantanee vengono conservate per un massimo di 24 ore, quindi dovrebbe svuotare dopo quel punto.

Il tuo chilometraggio può variare comunque in quanto potrebbe essere "semplice" come un file o solo la punta dell'iceberg.

    
risposta data 15.05.2018 - 08:52
fonte

Leggi altre domande sui tag