Я сам ставив собі це питання, і відповіді тут, безумовно, допомогли. Проте є аспект, якого не вистачає, який може бути новим «деталізацією» реалізації, якої не було, коли було дано відповідь на це питання.
tmutil delete
дійсно видаляє резервні копії, але насправді не відновлює простір, який вони взяли, принаймні, не будь-яким гарантованим способом. Я витратив близько 2 цілих днів на видалення резервних копій з & gt; 2-го тому, що відповідно до остаточного повідомлення про завершення склало бл. 400 Гб даних. Я бачив, як увімкнути відповідну позначку про вільний резервний простір один раз , але після чергового резервного копіювання я знову опустився до 7% вільного простору (858Gb замість 450Gb). Це дійсно мене зірвало.
Відповідь на цю таємницю дається тут: http://blog.hawkimedia.com/2012/08/reclaiming-a-timemachine-volumes-disk-space/ Коротше кажучи, ви повинні ущільнити розріджений пакет, який фактично містить резервну копію, якщо він розміщений на мережевому диску, або на диску, який не відформатований у HFS +.
Я не маю резервних копій ТМ, які не розміщені в розрідженому пакеті, тому не можна перевірити, чи використовується tmutil delete
не повертається безкоштовно на них. Це цілком може бути, і те, що він не працює на Time Capsule, може бути просто особливістю розрідженого протоколу розшарування.
Команда для виконання після sudo tmutil delete
є sudo hdiutil compact /Volumes/YourTimeMachineDisk/YourBackupName.sparsebundle
. У моєму випадку це повідомлялося
Starting to compact…
Reclaiming free space…
...................................................................................................................................
Finishing compaction…
Reclaimed 403.2 GB out of 583.5 GB possible.
Хороша новина полягає в тому, що ця команда зайняла лише частину часу, коли tmutil взяв, витрачаючи набагато менше часу на пошук на диску і використовуючи менше оперативної пам'яті (насправді він завершився в той час, коли мені знадобилося написати цю відповідь).