APFS: drzewo fsroot jest nieprawidłowe po wykonaniu kopii zapasowej Time Machine - jak odzyskać i uniknąć w przyszłości?

System

MacBook Pro, koniec 2013 r., Dysk SSD 1 TB (nowy, ostatnio zastąpiony przez Apple), APFS (bez rejestrowania, bez rozróżniania wielkości liter), High Sierra 10.13.2, Time Machine do sieciowego dysku twardego.

Co się stało

• Mac przestał działać, no space left on device.
• Ponowne uruchomienie nie powiodło się.
• Próbowano uruchomić tryb odzyskiwania za pomocą Command-R i uruchomić Pierwsza pomoc z Narzędzia dyskowego - nie powiodło się, ponieważ najwyraźniej system odzyskiwania znajduje się również na tym samym dysku, co sprawia, że ​​fsck na APFS jest niemożliwy.
• Próbowałem ręcznie usunąć niektóre pliki przez rm, dostał no space left on device
• Próbowałem ręcznie przyciąć niektóre pliki cat /dev/null > somefile, dostał no space left on device

• Uruchomiony w trybie odzyskiwania za pomocą Shift-Command-R (pobiera system z Internetu) i uruchomił Pierwsza pomoc jeszcze raz. Tym razem z ograniczonym sukcesem:

  ** 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.
  

Najwyraźniej drzewo fsroot jest nieprawidłowe. Szukałem, ale nie byłem w stanie znaleźć żadnej użytecznej porady, jak to naprawić (z wyjątkiem oczywiście ponownego formatowania i przywracania z kopii zapasowej, której chciałbym uniknąć).

Dodatkowe informacje o tle

W systemie jest Parallels Windows VM z wirtualnym dyskiem twardym o pojemności 100 GB (tak, jeden duży plik), który był ostatnio używany (więc potrzebna była kopia zapasowa). Ostatnim razem, gdy korzystałem z komputera, około 20 GB było nadal dostępnych na dysku SSD MacOS. Przez jeden dzień kopie zapasowe Time Machine nie zostały zakończone, ale nie został wyświetlony komunikat o błędzie. Po wystąpieniu problemu pozostawiłem komputer włączony na noc, aby wykonać przyrostową kopię zapasową Time Machine. Jest tu związek, że Time Machine najwyraźniej używa migawek APFS. Podejrzewam, że jest to główna przyczyna tego bałaganu.

pytania

1. Czy można to naprawić (bez ponownego formatowania i przywracania z kopii zapasowej)?
2. Jaki jest najlepszy sposób na uniknięcie tego w przyszłości (szczególnie w odniesieniu do Time Machine)?

Dzięki.

Aktualizacja

Podczas biegu fsck_apfs z flagą debugowania -d, wyjście zawiera trochę więcej informacji:

** 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.

Po prostu wpadłem na podobny problem. Prawdopodobnie odkryłbyś, że problem był w jednym z plików dla maszyny Parallels VM - przynajmniej w moim przypadku był to winowajca. Twój fsck_apfs -d /disk/<disk> czek zwrócony:

obj-id: 23267745 type: Inode

Jeśli otworzyłeś terminal, mógłbyś dostać ścieżkę do pliku (lub plików) używając tego i-węzła, używając następującej komendy:

find / -inum 23267745

Stamtąd wiedziałbyś, które pliki powinny zostać przywrócone zamiast pełnego przywracania.

W moim przypadku plik VM był dostępny tylko w migawce, ponieważ wykluczam moje maszyny wirtualne z TimeMachine. Przywróciłem właśnie ten plik z wcześniejszej migawki i przeszedłem dalej przez fsck_apfs - dostałem się przez dysk, aby sprawdzić migawki, a następnie zbombardowałem ten sam plik w drugiej migawce. Na szczęście migawki są przechowywane tylko przez najwyżej 24 godziny powinien oczyścić po tym punkcie.

Twój przebieg może się jednak różnić, ponieważ może być tak „prosty” jak jeden plik lub tylko wierzchołek góry lodowej.