• Головна ►
  • Статті ►
  • Шанси на відновлення даних в залежності від файлової системи

Шанси на відновлення даних в залежності від файлової системи

Як вже згадувалося у статті про шанси на відновлення даних за різних сценаріїв їх втрати, файлова система (ФС) є одним із основних факторів, що визначають ймовірність успіху цієї операції. Вона слугує механізмом, який дозволяє операційній системі впорядковувати та отримувати дані з накопичувача. При цьому кожна ФС не тільки визначає, як саме інформація має зберігатися на носії, але й виконує видалення файлів і форматування сховища у свій власний спосіб. Через те, що різні операційні системи використовують різні файлові системи, шанси на відновлення даних значною мірою залежать від конкретної ФС накопичувача. Наступна інформація допоможе вам оцінити перспективи відновлення після випадкового видалення файлу або форматування в залежності від застосованої у вашому сховищі файлової системи.

Разом з тим, якщо як операційна система, так і пристрій зберігання даних підтримують TRIM, можливість успішного відновлення інформації може бути практично виключена, незалежно від типу застосованої файлової системи. Більше про вплив TRIM на процедуру відновлення можна прочитати в розділі про Перешкоди для відновлення даних, спричинені TRIM.

Підказка: Найтиповіші випадки втрати даних, згадані у цій статті, більш детально розглядаються у засадах відновлення даних.

Зміст:

Файлові системи Windows

Основними файловими системами сімейства ОС Windows є FAT (FAT32), exFAT і NTFS. Хоча вони зазвичай використовуються у настільних системах загального призначення, файлова система нового покоління ReFS була розроблена для ширшого кола застосувань та її можна зустріти на деяких серверах під керуванням Windows, а також на комп'ютерах із професійними версіями Windows (починаючи з Windows 10).

Важливо зазначити, що успішному відновленню даних із цих файлових систем може перешкоджати значний ступінь фрагментації файлів, і таке відновлення взагалі можливе лише за умови, що пошкоджені файли ще не були перезаписані.

FAT/FAT32

У ФС FAT/FAT32 простір для зберігання даних розділений на одиниці однакового розміру, які називаються кластерами. Файл може займати один або декілька з цих кластерів. При цьому кластери, що містять дані того самого файлу, можуть і не бути розташовані поруч один з одним. Такі файли називають фрагментованими.

Таблиця розподілу файлів (File Allocation Table чи FAT) відображає розподіл кластерів на носії даних, вказуючи, які кластери призначені для яких файлів. У цій ФС зазвичай зберігаються дві копії таблиці FAT на випадок, якщо одна з них зазнає пошкодження. У згаданій таблиці є запис для кожного кластера у файловій системі. Якщо кластер зайнятий, його запис у FAT може містити посилання на наступний кластер, зайнятий тим самим файлом, або ж вказівку на те, що цей кластер є останнім у низці кластерів файлу.

Кореневий каталог (Root Directory) містить записи для всіх файлів і папок, що зберігаються в корені пристрою зберігання даних. Кожен запис, у свою чергу, містить важливу інформацію про файл, як-от його початковий кластер, назву, розмір та інші властивості. Він також вказує на перший кластер, що належить цьому файлу.

Видалення файлів з FAT32

Запис файлу у каталозі позначається як видалений. Перший знак у назві файлу замінюється на спеціальний символ, що має вказувати на його видалений стан. У FAT32 початковий кластер також може бути оновлений. Записи у таблиці FAT, які відповідають кластерам файлу, позначаються як "вільні", що руйнує ланцюжок кластерів, з яких складається видалений файл.

  • Відновлення нефрагментованих файлів: Якщо кластери файлу розташовані поруч один за одним, відновити дані відносно легко. У цьому разі назва, розмір і початковий кластер файлу все ще наявні у відповідному записі каталогу. Це суттєво збільшує шанси на його відновлення, які можуть сягати аж 100%.

  • Відновлення фрагментованих файлів: Ланцюжок кластерів файлу, що зберігається в записі таблиці FAT, знищується, тож не залишається інформації про розміщення проміжних та кінцевого кластерів. Проте запис каталогу залишається без змін, тож ім'я, розмір і місце розташування початку файлу все ще відомі. Можна спробувати передбачити розташування інших фрагментів файлу за допомогою евристики (методу спроб і помилок), проте успіх у цьому разі не гарантований.

Форматування FAT

Обидві копії таблиці FAT стираються, що руйнує зіставлення (mapping) між кластерами файлу. Записи Кореневого каталогу також очищаються. Однак вміст файлів залишатиметься на диску, доки не буде перезаписаний.

  • Відновлення нефрагментованих файлів: Форматування очищає записи каталогу, тож імена, розміри та початкові кластери файлів стають невідомі. Проте алгоритми відновлення на основі відомих підписів (сигнатур) файлів (метод відновлення за відомим вмістом о RAW-відновлення) здатні розпізнати вміст файлів і успішно витягнути їх зі сховища. Проте імена файлів, каталоги та інші властивості однаково втрачаються.

  • Відновлення фрагментованих файлів: Ланцюжки кластерів, що їх раніше містили таблиці FAT, втрачаються, а через фрагментацію передбачити можливі місця розташування вмісту файлу стає надзвичайно важко. Більшість файлів, ймовірно, будуть пошкоджені.

exFAT

Наступниця FAT/FAT32, ця ФС дуже схожа на неї за своєю структурою та роботою. exFAT також покладається на Таблицю розподілу файлів (File Allocation Table), але використовує її для відстеження послідовностей кластерів лише для фрагментованих файлів. При цьому зберігається лише одна копія цієї таблиці.

На додаток ця ФС має окрему структуру для керування використанням кластерів. Замість того, щоб робити це безпосередньо в записах таблиці FAT, exFAT використовує для цього Бітову мапу розподілу (Allocation Bitmap). Мапа зберігається в області даних і відображає статус кожного кластера – чи він зайнятий, чи доступний для запису нових даних. Цей підхід допомагає exFAT оптимізувати розміщення даних і зменшити ступінь фрагментації.

Видалення файлів з exFAT

exFAT оновлює Бітову мапу розподілу, щоб кластери, які використовує файл, відображалися у ній як вільні для збереження інших даних. Проте записи у таблиці FAT не оновлюються негайно та все ще можуть містити посилання на кластери, які належать видаленому файлу. Вміст файлу також залишатиметься у сховищі, доки не буде заміщений новими файлами.

  • Відновлення файлу: За умови, що записи FAT залишилися незмінними, послідовність кластерів фрагментованого файлу можна легко відновити та використати для того, щоб отримати повний файл. Проте якщо вони вже перезаписались, інформація про розташування фрагментів файлу буде недоступна. Однак з огляду на нижчий ступінь фрагментації у exFAT метод відновлення RAW, швидше за все, дасть гарні результати.

NTFS

Основним компонентом NTFS є Головна файлова таблиця (Master File Table чи MFT). У ній містяться детальні записи для кожного файлу та папки, що зберігається у файловій системі. Атрибут Bitmap у MFT позначає, які записи в цій таблиці наразі використовуються, а які – вільні. У записі MFT можуть знаходитися різні атрибути (властивості) файлу, зокрема його розташування, назва, розмір і дата/час створення та останньої зміни.

Фактичний вміст невеликих за розміром файлів зберігається безпосередньо в записі MFT. Більші файли, на відміну від малих, зберігаються поза MFT, а записи MFT у цьому разі містять вказівники на їхні фізичні місця розташування на диску. Великі атрибути файлу також можуть зберігатися за межами MFT, і тоді відповідний запис у MFT міститиме їхні адреси.

Каталоги в NTFS представлені спеціальними файлами. Такий файл містить список записів для всіх файлів і підкаталогів у певному каталозі з посиланнями на їхні записи у MFT.

Окрім атрибута Bitmap у MFT, NTFS також має окремий файл Bitmap (Бітову мапу) для всієї файлової системи. За допомогою цього файлу ФС відстежує, які області на носії зайняті, а які – вільні.

Видалення файлів з NTFS

Запис файлу у MFT не стирається, але позначається як "невикористаний", що означає, що незабаром він може бути перезаписаний. Простір, зайнятий вмістом файлу, позначається у Бітовій мапі як вільний і тепер його можна використати для збереження інших даних. Запис файлу у каталозі також видаляється.

  • Відновлення файлу: Якщо ім'я, розмір і місце розташування файлу все ще наявні в записі MFT, програмне забезпечення для відновлення даних матиме змогу повністю відновити видалений файл. За умови, що його фактичний вміст ще не був перезаписаний, шанси на відновлення у цьому разі майже стовідсоткові.

Форматування NTFS

NTFS створює нову Головну файлову таблицю. Ця нова MFT перезаписує початок попередньої MFT, але решта таблиці залишається недоторканою.

  • Відновлення файлу: Інформація про перші 256 файлів втрачається через часткове перезаписування таблиці MFT. Ці файли можна відновити лише за допомогою методу RAW-відновлення та без їхніх початкових імен, каталогів та інших атрибутів. Усі файли, що йдуть після них, можна успішно відновити з майже стовідсотковою вірогідністю, якщо їхній фактичний вміст ще не був перезаписаний.

ReFS

На відміну від своїх попередниць, ReFS організовує дані за допомогою B+-дерев, які працюють подібно до баз даних. Таке дерево складається з кореня, внутрішніх вузлів і листя. Кожен вузол містить упорядкований список ключів, які використовуються для пошуку, а також вказівники на вузли нижчого рівня або на фактичні дані у вузлах найнижчого рівня (листя). B+-дерева використовуються для упорядкування майже всіх елементів ФС, включно з вмістом файлів і метаданими.

Каталог (Directory) є основним компонентом ReFS і також представлений у вигляді B+-дерева. Він використовує ключі, що відповідають номерам папок-об'єктів, тоді як файли в ньому зберігаються як покажчики, а не як записи каталогу.

ReFS використовує копіювання при записуванні (Copy-on-Write чи CoW), яке гарантує, що вихідні записи файлової системи ніколи не змінюються у прямий спосіб. Натомість дані копіюються, а зміни записуються до нових місць, тож вихідна інформація зберігається.

Видалення файлів з ReFS

ReFS використовує техніку Copy-on-Write (CoW), яка створює нову копію метаданих файлу, вносить всі необхідні зміни для відображення видалення файлу та оновлює структуру сховища лише після успішного запису нових метаданих.

  • Відновлення файлів: Завдяки копіюванню при записуванні (CoW) початкова (вихідна) версія метаданих зберігається у сховищі. Якщо ці метадані ще не були перезаписані новою інформацією, ймовірність повного відновлення файлу сягає 100%.

Підказка: Зверніться до відповідних інструкцій, якщо вам потрібно відновити дані з файлових систем Windows.

File systems of macOS

Усі сучасні комп'ютери Mac, що працюють на ОС, починаючи з macOS 10.14 (Mojave), використовують APFS як файлову систему за замовчуванням. Цей формат також застосовується у всій лінійці продуктів Apple, включно з пристроями під iOS, iPadOS, tvOS і watchOS. Хоча APFS є сучасним стандартом, Apple продовжує підтримувати старішу файлову систему HFS+, головним чином для забезпечення зворотної сумісності із застарілими версіями macOS. До того ж на портативних пристроях Apple, які зазвичай підключаються до різних операційних систем, широко використовується файлова система exFAT від Microsoft.

Важливо підкреслити, що відновлення даних з файлових систем macOS можливе лише доти, доки файли не будуть перезаписані.

HFS+

В HFS+ простір для зберігання даних поділений на блоки розподілу однакового розміру, які можуть бути згруповані, щоб зменшити фрагментацію. Файл розподілу (Allocation File) відстежує статус кожного блоку розподілу – вільний він чи зайнятий.

Вміст файлів організований за допомогою так званих потоків (fork): поток даних (data fork) містить фактичні дані, тоді як уся додаткова інформація (метадані) знаходиться у потоці ресурсів (resource fork). Кожен з цих потоків займає кілька блоків розподілу. Діапазон безперервно розташованих блоків розподілу, призначених певному потоку, називається екстентом (extent). Екстент, у свою чергу, представлений початковим блоком і кількістю блоків, яку він займає.

Керування більшістю метаданих ФС здійснюється за допомогою спеціальних файлів, організованих як B-дерева. Особливо важливим є Файл каталогу (Catalog File) – він описує ієрархію каталогів файлової системи і зберігає ключові властивості кожного файлу та папки, включно з їхніми іменами, а також перші вісім екстентів даних файлу та потоки ресурсів. Якщо поток має більше екстентів, вони записуються у Файл переповнення екстентів (Extents Overflow File). Будь-які додаткові властивості файлу, наприклад, розширені метадані, знаходяться у Файлі атрибутів (Attributes File).

HFS+ підтримує жорсткі посилання, завдяки чому один файл може з'являтися в кількох каталогах без дублювання. Фактичні дані файлу зберігаються в одному місці на диску, а численні записи жорстких посилань у Файлі каталогу (Catalog File) просто посилаються на них.

Зміни, внесені у файлову систему, занотовуються у журналі. Однак журнал має обмежений розмір, тому, коли він заповнюється, старі записи циклічно перезаписуються новими.

Видалення файлів з HFS+

HFS+ оновлює Файл каталогу шляхом реорганізації B-дерева та прибирання посилань на видалений файл. У разі жорсткого посилання вказівка на файл видаляється з відповідного каталогу. Блоки, зайняті файлом, позначаються у Файлі розподілу як вільні та можуть бути повторно використані для запису інших даних. Однак фактичний вміст не видаляється одразу. Інформація також залишається в журналі протягом певного часу.

  • Відновлення файлів: Журнал все ще може містити інформацію про видалений файл, але ймовірність цього залежить від того, скільки часу минуло з моменту видалення. Якщо записи журналу вже були перезаписані, можна скористатися методом RAW-відновлення, хоча він ефективний лише у разі нефрагментованих файлів і не дозволяє відновити оригінальні імена файлів, каталоги та інші властивості.

Форматування HFS+

Файл каталогу скидається до стану за замовчуванням, через що всі записи про попередні файли стираються. Однак журнал і фактичний вміст файлів залишаються незмінними.

  • Відновлення файлів: Деякі метадані можна відновити за допомогою журналу. Решта відсутніх файлів будуть реконструйовані за допомогою техніки RAW-відновлення. Успіх цієї процедури залежатиме від ступеня фрагментації файлової системи.

APFS

Том APFS знаходиться в Контейнері (Container), що може містити кілька файлових систем, які спільно використовують доступний простір для зберігання даних. Усі зайняті та вільні блоки зберігання даних в Контейнері відстежуються за допомогою загальної Бітової мапи (Bitmap). Проте кожна файлова система відповідає за управління своєю власною ієрархією каталогів, файловим вмістом та метаданими.

Розподіл файлів і папок організований як B-дерево, подібне до Файлу каталогу в HFS+. Файли складаються з екстентів, які визначають блок, з якого починається вміст файлу, а також його довжину в блоках. На додаток є окреме B-дерево для керування екстентами у межах файлової системи.

Замість того, щоб модифікувати наявні об'єкти файлової системи під час внесення будь-яких змін, APFS створює копію даних і зберігає нову версію до іншого місця на сховищі. Цей підхід відомий як копіювання при записуванні (Copy-on-Write чи CoW).

Видалення файлів з APFS

APFS прибирає посилання на видалений файл, стираючи відповідні вузли у B-дереві розподілу.

  • Відновлення файлів: Старіші версії метаданих видаленого файлу все ще можуть залишатися у сховищі, що дає змогу реконструювати вміст файлу. Втім невід'ємною частиною архітектури APFS є шифрування, яке настійно рекомендується до активації та часто ввімкнене за замовчуванням на пристроях Apple. У зашифрованому вигляді ця файлова система захищає не лише дані користувача, але й критично важливі структури метаданих. Таке широке застосування шифрування суттєво ускладнює відновлення даних.

Підказка: За допомогою наступної інструкції ви матимете змогу відновити дані з файлових систем macOS.

Файлові системи Linux

Linux – це багатогранний проєкт з відкритим вихідним кодом, який має численні версії, відомі як "дистрибутиви", кожна зі своїми особливостями та налаштуваннями. Тож не дивно, що файлові системи цих дистрибутивів також можуть суттєво відрізнятися. Загалом, ядро ​​всіх цих операційних систем (відоме як Linux kernel) підтримує широкий діапазон форматів. Проте найпоширенішими файловими системами Linux є ті, що належать до сімейства Ext (Ext2, Ext3, Ext4), а також XFS, Btrfs, F2FS, JFS і ReiserFS.

Слід зазначити, що відновлення даних із цих файлових систем можливе лише допоки вихідні дані залишатимуться на носії й не будуть перезаписані.

XFS

XFS розділяє том на однакові за розміром області, які називаються Групами розподілу (Allocation Groups). Кожна з груп функціонує як незалежна файлова система, управляючи власним простором для зберігання даних та структурами.

Вільний простір у XFS контролюється за допомогою двох B+-дерев: перше фіксує початковий блок безперервної області вільного простору, а друге – кількість блоків у ній. Аналогічний механізм використовується для відстеження блоків, призначених для файлів. Вміст файлів зберігається в безперервних послідовностях блоків, які називаються екстентами (extent).

Кожен файл і каталог представлений індексним дескриптором (inode чи інодом), спеціальною структурою, яка містить їхні метадані, як-от розмір, дозволи тощо. У разі невеликих за розміром файлів, інод зберігає інформацію про виділені файлу екстенти. А у разі великих або фрагментованих, індексний дескриптор вказує на окреме B+-дерево, яке відстежує екстенти, пов'язані з файлом. Проте іноди не містять імена файлів. Ці імена знаходяться в записах каталогу, за допомогою яких вони зіставляються з відповідними інодами. У кожній Групі розподілу також є спеціальне B+-дерево, яке використовується для керування розподілом і скасуванням розподілу індексних дескрипторів.

На додаток XFS використовує журнал для операцій з метаданими. Усі зміни в ФС перед записом на диск спочатку фіксуються в журналі.

Видалення файлів з XFS

Інод, прив'язаний до видаленого файлу, прибирається з B+-дерева в Групі розподілу та стає доступним для повторного використання. B+-дерева вільних блоків оновлюються для відображення звільненого простору. Запис каталогу, який зіставляє назву файлу з відповідним інодом, стирається. Проте інформація екстента часто залишається незмінною.

  • Відновлення нефрагментованих файлів: Якщо інформація екстента ще не була перезаписана, шанси на відновлення вмісту файлу наближені до 100%. Відновити ім'я файлу складніше, оскільки імена зберігаються в каталозі, який більше не має посилань на видалений файл. Однак у разі нещодавно видалених файлів, журнал все ще може містити метадані про файл, що дає змогу отримати його правильну назву та каталог.

  • Відновлення фрагментованих файлів: Хоча самі екстенти можуть залишатися недоторканими, інод більше не прив'язаний до даних файлу, що ускладнює процес відновлення. Не маючи жодних відомостей про зв'язки між екстентами, повністю реконструювати їх послідовність може бути важко.

Форматування XFS

B+-дерева, відповідальні за контроль над розподілом простору для зберігання даних, видаляються. Створюється новий кореневий каталог на заміну попередньому.

  • Відновлення нефрагментованих файлів: У той час як структури файлової системи скидаються, блоки з фактичними даними файлів можуть залишатися на накопичувачі, доки не будуть перезаписані. Шанси на відновлення загалом високі для нефрагментованих файлів.

  • Відновлення фрагментованих файлів: Оскільки їхні блоки даних не зберігаються поруч один з одним, перспективи відновлення цих файлів нижчі порівняно з нефрагментованими.

Підказка: Перегляньте відповідну статтю, якщо вам потрібно відновити дані з файлових систем Linux.

Ext2

Ext2 використовує блок як найменшу одиницю зберігання даних. Потім блоки збираються в Групи блоків (Block Group). Кожна Група блоків має Бітову мапу блоків (Block Bitmap), яка веде облік зайнятих та вільних блоків всередині групи.

Для зберігання метаданих про всі файли та каталоги, включно з їхніми розмірами та розташуванням блоків, що містять їхні фактичні дані, використовуються індексні дескриптори (inodes чи іноди). Іноди, що належать кожній Групі блоків, зберігаються в її Таблиці індексних дескрипторів (Inode Table), а у Бітовій мапі індексних дескрипторів (Inode Bitmap) фіксується, які з інодів розподілені.

Однак імена файлів не належать до метаданих і не зберігаються безпосередньо в інодах. Натомість вони знаходяться у файлах-каталогах, які насправді є звичайними файлами, що містять записи каталогу.

Видалення файлів з Ext2

Ext2 позначає інод, який описує видалений файл, як вільний у Бітовій мапі індексних дескрипторів. Блоки, які використовувалися для зберігання фактичних даних файлу, також позначаються як вільні в Бітовій мапі блоків та стають доступними для повторного використання. Ім'я файлу видаляється із запису каталогу, що руйнує зв'язок між ім'ям і номером іноду.

  • Відновлення нефрагментованих файлів: Індексний дескриптор все ще зберігає важливу інформацію про файл, включно з його розміром і розташуванням його блоків даних. Тож за умови, що вміст ще не був перезаписаний, шанси відновити файл досить високі. Проте оскільки ім'я файлу не зберігається в іноді, а посилання на інод з каталогу вже відсутнє, ім'я файлу буде назавжди втрачене.

  • Відновлення фрагментованих файлів: Інформацію, необхідну для визначення місцезнаходження блоків файлу, можна знайти в індексному дескрипторі, тож шанси на відновлення більш-менш такі самі, як і у разі нефрагментованих файлів, хоча фрагментація збільшує ризик часткового перезапису даних.

Форматування Ext2

Файлова система скидається, що стирає вміст усіх Груп блоків, включно з інодами.

  • Відновлення нефрагментованих файлів: Через те, що всі критично важливі структури, що описують файлову систему, відсутні, можна застосувати лише метод відновлення RAW, щоб спробувати відновити хоч щось. Вихідні імена файлів і каталоги однаково будуть втрачені.

  • Відновлення фрагментованих файлів: Без належних метаданих файлової системи зібрати разом фрагменти таких файлів важко, тому фрагментовані файли, ймовірно, будуть пошкоджені.

Ext3/Ext4

Ext3 розширює Ext2, додаючи до вже наявних структур файл журналу. У цьому журналі занотовуються всі зміни до того, як вони будуть застосовані до файлової системи. Тобто будь-яка зміна спочатку записується в журнал, що підвищує надійність файлової системи.

Ext4 була створена на базі Ext3, до якої додали екстенти (extent). Екстенти пропонують більш ефективний механізм розміщення даних порівняно з блоковим, який використовується системами Ext2 і Ext3. Вони дозволяють розподіляти більші області суцільного простору зберігання, що описуються адресою початкового блоку та загальною кількістю блоків у екстенті. У випадку малих файлів екстенти зберігаються безпосередньо в іноді файлу. Якщо файл має більше чотирьох екстентів, Ext4 зберігає їх в окремій ієрархічній B+-деревоподібній структурі.

Іншою особливістю Ext4 є так званий відкладений розподіл, що також допомагає мінімізувати фрагментацію. Замість того, щоб записувати дані одразу, Ext4 накопичує їх у пам'яті та виділяє для них місце лише тоді, коли вже накопичила їх у достатньому обсязі, або ж коли файл закривається.

Видалення файлів з Ext3/Ext4

Ext3/Ext4 реєструє операцію шляхом створення відповідного запису в журналі. Після цього інод файлу позначається як доступний для повторного використання в Бітовій мапі індексних дескрипторів. Екстенти, які використовувалися для зберігання його вмісту, також позначаються як вільні. Запис каталогу, який пов'язує ім'я файлу з відповідним інодом, не видаляється повністю, але змінюється порядок читання каталогу.

  • Відновлення нефрагментованих файлів: Зв'язок між ім'ям файлу та інодом порушується, але в журналі все ще можуть зберігатися метадані про нещодавно видалені файли. Якщо журнал ще містить записи, пов'язані з файлом, їх можна проаналізувати, щоб відновити як вміст файлу, так і його ім'я. Якість результату відновлення залежатиме від того, як довго файлова система була активною після видалення файлу.

  • Відновлення фрагментованих файлів: В Ext3/Ext4 такі файли мають менші шанси на відновлення, оскільки розрізнені блоки/екстенти набагато важче знайти та об'єднати. Однак журнал може покращити ці шанси для нещодавно видалених файлів, дозволяючи їх відновити навіть з оригінальними назвами.

Форматування Ext3/Ext4

Ця операція передбачає очищення всіх Груп блоків і видалення індексних дескрипторів. Журнал зазвичай скидається, тож всі попередні записи втрачаються. Втім залежно від накопичувача, він все ще може містити інформацію про нещодавно створені або змінені файли.

  • Відновлення нефрагментованих файлів: Метод відновлення RAW зазвичай дозволяє відновлювати непошкоджені файли. Однак у більшості випадків відновити початкові імена файлів неможливо. Відновити можна лише імена дуже "свіжих" файлів і те за умови, що журнал не був очищений під час форматування.

  • Відновлення фрагментованих файлів: Для таких файлів шанси на успішне відновлення низькі через розпорошене розміщення їхнього вмісту.

ReiserFS

Том ReiserFS розділений на блоки фіксованого розміру, які є основною одиницею зберігання даних у цій ФС. Спеціальна бітова мапа стежить за тим, які блоки файлової системи наразі використовуються, а які – вільні.

А для організації всіх файлів, каталогів і метаданих ReiserFS використовує S+-дерево. Воно складається з елементів чотирьох основних типів: непрямих та прямих, а також елементів каталогу та елементів статистики. Прямі елементи містять фактичні дані; непрямі вказують на розташування блоків даних; елементи каталогу представляють записи каталогу; а у елементах статистики розміщені метадані про файли та каталоги. Кожен елемент у S+-дереві має ключ, який є його унікальним ідентифікатором.

ReiserFS зменшує обсяги намарно витраченого простору зберігання за допомогою спеціальної техніки, яка називається tail-packing ("пакування хвостів"). Якщо файли або фрагменти файлів менші за повний блок, вони "пакуються" разом і зберігаються в невикористаній частині блоку, що покращує ефективність використання простору сховища.

Замість того, щоб записувати зміни безпосередньо до S+-дерева, ReiserFS спочатку реєструє їх у журналі. Після цього змінені блоки копіюються з журналу до фактичних місць розташування на диску.

Видалення файлів з ReiserFS

ReiserFS оновлює S+-дерево, прибираючи вузли, які відповідають видаленому файлу. Блоки, які використовував файл, позначаються в бітовій мапі як вільні.

  • Відновлення нефрагментованих файлів: ReiserFS зберігає копії S+-дерева і реєструє зміни у файловій системі у своєму журналі, тому старіші версії вузлів S+-дерева, пов'язані з видаленим файлом, можуть усе ще залишатися у файловій системі. У цьому разі ймовірність відновлення файлу, навіть разом з його початковим ім'ям, сягає 100%.

  • Відновлення фрагментованих файлів: Через особливості архітектури ReiserFS перспективи відновлення фрагментованих файлів збігаються з перспективами відновлення нефрагментованих.

Форматування ReiserFS

ReiserFS створює нове S+-дерево, яке перезаписує попередню структуру.

  • Відновлення нефрагментованих файлів: Файлова система зберігає копії S+-дерева на різних етапах, даючи змогу відновити попереднє S+-дерево та отримати потрібні файли з їхніми оригінальними іменами. Проте ймовірність відновлення цих файлів нижча, якщо перед форматуванням том був заповнений.

  • Відновлення фрагментованих файлів: Шанси на відновлення фрагментованих файлів не відрізняються від шансів на відновлення нефрагментованих.

JFS (JFS2)

JFS складається з областей, відомих як Групи розподілу (Allocation Groups). Групи розподілу, у свою чергу, складаються з блоків даних і блоків метаданих, статуси використання яких відстежуються за допомогою бітової мапи.

Для організації логічної структури файлів і каталогів використовуються Набори файлів (FileSets). Кожен файл та каталог у JFS прив'язаний до індексного дескриптору (inode чи іноду), який не лише описує його, але й вказує на місце у сховищі, де розміщений його фактичний вміст. Маленькі каталоги зберігаються просто в своїх інодах, тоді як великі представлені окремими структурами у вигляді B+-дерев.

Фактичні дані файлу розміщені у послідовностях суміжних блоків, які називаються екстентами (extent). Усі екстенти проіндексовані у спеціальному B+-дереві.

Керування вільним простором здійснюється за допомогою двох B+-дерев: одне фіксує початкові блоки вільних екстентів, а інше – кількість доступних екстентів.

Задля забезпечення узгодженості даних, JFS створює спеціальну область журналювання (log area) та записує всі зміни своїх метаданих у журнал.

Видалення файлів з JFS

Файлова система оновлює B+-дерево, яке відстежує вільний простір, позначає інод файлу як вільний, а потім перебудовує структуру каталогів, щоб відобразити видалення файлу.

  • Відновлення нефрагментованих файлів: Допоки інод, що належить видаленому файлу, не був перезаписаний, шанси на відновлення файлу часто близькі до 100%. Однак відновлення оригінального ім'я файлу малоймовірне через брак у каталозі зв'язку між інодом та цим ім'ям.

  • Відновлення фрагментованих файлів: Перспективи відновлення такі самі, що і у разі нефрагментованих файлів.

Форматування JFS

JFS створює нове B+-дерево. Спочатку воно мале, але зростає в міру використання файлової системи.

  • Відновлення нефрагментованих файлів: Шанси на відновлення доволі високі, зокрема через малий розмір нового B+-дерева. Втім у міру того, як на диск записуються нові дані, інформація про старі файли може бути перезаписана.

  • Відновлення фрагментованих файлів: Шанси зазвичай аналогічні шансам відновити нефрагментовані файли.

Btrfs

Btrfs повністю покладається на B-дерева у тому, що стосується керування даними та структурами. Як пояснюється нижче, кожне B-дерево у цій ФС має своє призначення.

Ця файлова система може бути застосована одразу до декількох пристроїв навіть без допомоги додаткових технологій. Простір для зберігання цих пристроїв об'єднується в єдиний логічний пул, і кожному блоку в цьому пулі призначається віртуальна адреса. У цій ФС такі віртуальні адреси використовуються замість реальних фізичних адрес. B-дерево фрагментів (Chunk B-tree) відстежує зіставлення віртуальних адрес з фактичними фізичними розташуваннями. У ньому також фіксується, які пристрої належать пулу зберігання. B-дерево пристроїв (Device B-tree), у свою чергу, зіставляє фізичні блоки на пристроях з їхніми віртуальними адресами.

Уся інформація про файли та каталоги зберігається в B-дереві файлової системи (File System B-tree). Невеликі файли зберігаються безпосередньо в цьому B-дереві як елементи-екстенти. Якщо ж файл великий, його вміст зберігається поза B-деревом файлової системи, тоді як елементи-екстенти в цьому дереві вказують на всі екстенти, з яких складається файл (безперервні області зайнятого простору для зберігання). Елементи каталогу в цьому B-дереві зберігають вміст каталогів, включно з іменами файлів і посиланнями на елементи-іноди, які їм відповідають. Елементи-іноди містять метадані, зокрема розміри, дозволи та інші атрибути файлів.

Розміщення екстентів у Btrfs дуже динамічне. Вони призначаються відповідно до вимог для виконання різних завдань і розміщуються по всьому доступному простору для зберігання у непослідовний спосіб. Окреме B-дерево екстентів (Extent B-tree) використовується для керування розподілом всіх екстентів у файловій системі.

Коли будь-які дані або метадані змінюються, Btrfs записує їх у нове місце, а не перезаписує наявну інформацію. Цей підхід, відомий під назвою копіювання при записуванні (Copy-on-Write чи CoW), допомагає підтримувати цілісність файлової системи та полегшує відновлення даних після збоїв.

Видалення файлів з Btrfs

Btrfs перебудовує B-дерево файлової системи, щоб прибрати вузли, пов'язані з видаленим файлом, включно з його інодами, записами каталогу та фактичним вмістом. B-дерево екстентів також оновлюється, щоб вивільнити екстенти, раніше виділені для цього файлу. Однак завдяки підходу Copy-on-Write, який використовує ця ФС, посилання на дані та метадані видаленого файлу залишаються в старих копіях.

  • Відновлення файлів: Проаналізувавши попередні копії, можна знайти як дані, так і метадані видаленого файлу. У більшості випадків відновлення даних може бути успішним. Однак у разі масового видалення, перебудова розподілу простору для зберігання ускладнює відновлення через нелінійний характер розміщення даних.

Форматування Btrfs

Btrfs скидає свої первинні структури метаданих, включно з B-деревами файлової системи та екстентів.

  • Відновлення файлів: Старі копії даних і метаданих все ще можуть залишатися у сховищі. Проте розподіл простору сховища скидається, що ускладнює пошук посилань на цю інформацію. У поєднанні з непослідовним розміщенням даних це становить справжній виклик для відновлення.

F2FS

F2FS ділить весь простір зберігання на сегменти фіксованого розміру. Потім ці сегменти групуються в секції, а кілька секцій утворюють зону.

Розміщення даних у F2FS контролюється за допомогою вузлів. Вони можуть бути трьох типів: прямі вузли зберігають адреси блоків фактичних даних; у непрямих знаходяться посилання на блоки в інших вузлах; а індексні дескриптори (inodes чи іноди) містять метадані файлів і каталогів, зокрема імена, розміри та інші атрибути. Зіставлення цих вузлів із фізичними розташуваннями у сховищі виконується за допомогою Таблиці адрес вузлів (Node Address Table чи NIT).

Фактичний вміст файлів і каталогів зберігається в основній області (Main Area). Остання розділена на секції, що відокремлюють блоки даних від блоків вузлів. Таблиця інформації про сегмент (Segment Information Table або SIT) допомагає відстежувати статус кожного блоку. Блоки позначаються як дійсні (valid), коли зайняті, і як недійсні (invalid), якщо вони містять видалені дані. У Області зведення сегментів (Segment Summary Area чи SSA) занотовується, які блоки належать до якого вузла.

F2FS має власну версію записів каталогу, які називаються dentries. Вони зіставляють імена файлів з інодами, які містять решту метаданих файлів.

Якщо файловій системі бракує вільного місця для розміщення нових даних, F2FS виконує очищення у фоновому режимі, зазвичай коли система перебуває у режимі очікування (не активна). Сегменти-жертви обираються за кількістю використаних ними блоків або ж за "віком".

Стабільність файлової системи забезпечується за допомогою Блоків контрольних точок (Checkpoint blocks). Такі блоки зберігають інформацію про стан ключових елементів файлової системи в певні моменти часу, слугуючи точками відновлення у разі збою.

Видалення файлів з F2FS

F2FS оновлює таблиці NAT і SIT, щоб показати, що блоки файлу більше не використовуються. Зміни зберігаються в пам'яті, доки не буде створена нова контрольна точка, яка зафіксує поточний стан файлової системи. Фактичний вміст файлів залишається на місці до остаточного очищення.

  • Відновлення файлу: Для визначення місцезнаходження вузлів і блоків даних файлу можна звернутися до найновішої контрольної точки. Якщо файл не був стертий під час очищення, шанси на його успішне відновлення доволі високі.

Файлові системи BSD, Solaris, Unix

Сімейство операційних систем Unix, до якого належать зокрема BSD і Solaris, історично покладалося на UFS (Unix File System або Файлову систему Unix). Згодом на зміну UFS прийшла UFS2, яка запропонувала деякі покращення, зокрема підтримку більших за розміром файлів і вищу загальну продуктивність. Пізніше для ОС Solaris була розроблена файлова система нового покоління під назвою ZFS. Відтоді ZFS з'явилася і в інших операційних системах, як-от FreeBSD, та наразі набула широкого застосування у середовищах, які вимагають більш просунутих сучасних функцій, високої продуктивності та надійності.

Слід підкреслити, що відновлення даних з файлових систем BSD, Solaris і Unix можливе лише доти, доки вихідна інформація на носії даних не була перезаписана.

UFS/UFS2

Том UFS складається з однієї або кількох Груп циліндрів (Cylinder Groups). Кожна Група циліндрів має власний набір індексних дескрипторів (inodes чи інодів), призначених для зберігання інформації про файли та блоки даних, у яких розміщується їхній фактичний вміст. Бітова мапа (bitmap) використовується для відстеження того, які з блоків та інодів у Групі циліндрів вже зайняті.

Файл в UFS складається з блоків даних та іноду. Іноди містять метадані файлів, такі як їхні розміри, дозволи тощо, а також прямі вказівники на перші 12 блоків даних. Якщо файл великий, його інод вказує на непрямий блок, який, у свою чергу, містить адреси наступних блоків даних. Проте іноди не містять імен файлів – вони зберігаються в каталогах.

Каталоги в UFS мають вигляд списків записів. Кожен запис каталогу містить назву файлу та номер іноду, що йому відповідає. Один файл зазвичай пов'язаний з одним інодом. Однак коли йдеться про жорстке посилання, той самий файл може мати кілька імен з різними записами каталогу, що вказуватимуть на той самий інод. У цьому разі останній веде облік того, скільки жорстких посилань вказують на нього.

Видалення файлів з UFS

UFS очищає інод файлу, який описує його розмір і вказує на розташування його перших 12 блоків даних. Відповідні блоки даних та іноди позначаються як вільні у бітовій мапі. Запис у каталозі, який пов'язує ім'я файлу з його інодом, також видаляється.

  • Відновлення нефрагментованих файлів: Через те, що інод файлу відсутній, інформація про його розмір та розташування його перших 12 блоків даних недоступна. Зв'язок між назвою файлу та відповідним інодом також остаточно втрачається. Використовуючи метод RAW-відновлення, можна відновити нефрагментований файл, але без оригінального імені та каталогу. При цьому зустріти нефрагментований файл в UFS можна доволі рідко через особливості алгоритму Soft Updates цієї ФС.

  • Відновлення фрагментованих файлів: У цьому разі шанси на відновлення дуже низькі через те, що не залишається інформації про те, які блоки даних належать видаленому файлу.

Форматування UFS

Ця операція скидає Групи циліндрів, що стирає існуючі іноди та записи каталогу. Тож усі посилання на файли та їхні назви знищуються. Проте блоки даних залишаються незмінними, допоки не будуть перезаписані.

  • Відновлення нефрагментованих файлів: Нефрагментовані файли можна відновити за допомогою методу RAW-відновлення, але вони у будь-якому разі втратять свої початкові імена та каталоги.

  • Відновлення фрагментованих файлів: Такі файли майже неможливо відновити через відсутність інодів, які могли б допомогти поєднати їхні фрагменти.

ZFS

ZFS відрізняється від більшості файлових систем своєю здатністю об'єднувати декілька фізичних накопичувачів у єдиний спільний пул зберігання. Пул містить один або кілька віртуальних пристроїв, які називаються vdev. Кожен vdev має мітку з Уберблоком (Uberblock), що є основною структурою метаданих пулу.

ZFS розподіляє простір зберігання блоками змінного розміру. Блоки організовані як об'єкти різних типів. Кожен об'єкт описується dnode, структурою, яка реєструє такі деталі, як тип об'єкта, його розмір тощо, і містить до трьох вказівників на блоки. Вказівник може посилатися на блок із фактичними даними (блок-лист) або на непрямий блок, який посилається на інший блок.

Усі пов'язані між собою об'єкти групуються в набори об'єктів. Кожному об'єкту в наборі присвоюється унікальний ідентифікатор, який називається номером об'єкта. Метадані цих об'єктів також організовані як об'єкт, для посилання на який використовується спеціальна структура, відома як metadnode. Спеціальний набір об'єктів під назвою Набір мета-об'єктів (Meta Object Set чи MOS) містить метадані для всього пулу зберігання.

Під час запису даних ZFS дотримується принципу копіювання при записуванні (Copy-on-Write чи CoW). Замість того, щоб перезаписувати існуючі блоки, вона зберігає оновлені дані до нових блоків у вільному просторі сховища. Після успішного запису нових даних, метадані файлової системи оновлюються, щоб вказувати на ці щойно записані блоки, тоді як старі блоки залишаються незмінними.

Видалення файлів з ZFS

Зв'язок між dnode, що описує видалений файл, і блоками, що містять його фактичні дані, руйнується. Номер об'єкта, прив'язаний до файлу, позначається як доступний для повторного використання. Посилання на файл видаляється з об'єкта каталогу. Для відображення оновленого стану файлової системи створюється новий Уберблок. Однак усі ці зміни виконуються із застосуванням копіювання при записуванні (Copy-on-Write чи COW).

  • Відновлення файлів: Залежно від використання файлової системи та заповненості пулу, старіші версії даних і метаданих файлів можуть залишатися в пулі зберігання протягом досить тривалого часу і їх можна використати для повного відновлення файлів із правильними назвами. Однак спроби відновити файли можуть бути ускладнені тим фактом, що дані розміщені у блоках різного розміру на декількох накопичувачах. Без метаданих пулу (Уберблоку, Набору мета-об'єктів тощо) майже неможливо зібрати сховище та реконструювати його побудову. Тому успіх також залежатиме від наявності та повноти цих метаданих.

Підказка: Скористайтеся відповідною інструкцією, якщо вам потрібно відновити дані з файлових систем Unix, Solaris або BSD.

Щоб мати найкращі шанси на відновлення даних із вищеописаних файлових систем, рекомендуємо скористатись UFS Explorer і Recovery Explorer, надійними та ефективними програмними рішеннями з широкою сумісністю. Ці програми працюють з різними операційними системами та відмінно справляються з відновленням видалених, втрачених або недоступних даних із різних пристроїв, відформатованих у файлових системах, що використовуються у Windows, Linux, macOS, BSD і Solaris.

Перешкоди для відновлення даних, спричинені TRIM

Більшість сучасних твердотільних накопичувачів (SSD) і все більше нових накопичувачів SMR оснащені транслятором (translator), що підтримує TRIM. Коли команда TRIM активована, файлова система надсилає її на пристрій зберігання даних, інформуючи його про те, що певні блоки більше не використовуються та мають бути підготовлені до видалення. Ці блоки позначаються як вільні у таблицях зіставлення (mapping) пристрою та очікують на фізичне видалення, відоме як "збір сміття". Такі заходи спрямовані на оптимізацію продуктивності накопичувача та продовження його терміну служби. Однак вони також створюють значні, часто нездоланні перешкоди для відновлення даних після видалення або форматування.

Після виконання команди TRIM відповідні блоки розглядаються пристроєм як порожні. Хоча дані як такі все ще можуть зберігатися у них, посилання на ці блоки фактично видаляються на рівні внутрішнього розподілення (mapping) накопичувача. Тож згадані блоки стають невидимими не лише для файлової системи, але й для будь-якого програмного забезпечення для відновлення даних. А після "збору сміття", блоки стираються на рівні апаратного забезпечення, що не залишає жодного шансу на відновлення даних у будь-який спосіб.

"Збирання сміття" може розпочатися не відразу після надсилання команди TRIM, і це відносно повільний процес, швидкість якого залежить від виробника накопичувача, його моделі та типу пам'яті. Оновлення транслятора, навпаки, виконується швидко, майже миттєво. Після цього оновлення накопичувач почне відображати нулі в "очищених" областях, але може статися, що фактичні дані ще не були стерті.

Видалення файлів

Файлова система позначає простір для зберігання як вільний для повторного використання і незабаром після цього запускається команда TRIM. Транслятор оновлюється, а видалені дані позначаються як непотрібні. Блоки, зайняті цими даними, ставляться у чергу на обробку у межах "збору сміття". Процес очищення може розпочатися одразу або ж відкластися на період від декількох секунд до тижня.

Відновлення файлів: Є дуже короткий проміжок часу, зазвичай близько 5 секунд, щоб вимкнути пристрій, перш ніж транслятор оновиться. Після виконання команди TRIM отримати доступ до даних у стандартні способи буде неможливо. З іншого боку, спеціалісти з відновлення даних все ще можуть отримати їх за допомогою спеціального обладнання, що дозволяє обійти рівень транслятора накопичувача. Вони можуть перевести диск у режим налагодження (debugging mode) та скопіювати необроблений вміст з його мікросхем пам'яті. У цьому разі успіх не гарантований і залежатиме від багатьох технічних факторів. Проте якщо диск залишатиметься увімкненим протягом певного часу, видалені дані поступово знищуватимуться у процесі "збирання сміття".

Форматування

Ця операція скидає структуру файлової системи. Тим часом активується команда TRIM, яка повідомляє накопичувачу, що раніше зайняті блоки наразі "вільні". Транслятор накопичувача оновлює його внутрішній розподіл (mapping). Залежно від навантаження диска, операція "збору сміття" може бути запущена одразу або ж відкладена на певний час.

Відновлення файлів: Як і у випадку з видаленням, якщо диск від'єднати до того, як відбудеться "збирання сміття", фахівці з відновлення даних матимуть змогу отримати необроблені дані з блоків, позначених транслятором як невикористані. Однак після завершення "збирання сміття" стерті дані зникають назавжди і не можуть бути відновлені.

Пошкодження метаданих

У разі пошкодження даних або метаданих файлова система не в змозі ідентифікувати уражені блоки та опрацювати їх належним чином, тож команду TRIM їй також не вдається виконати. Без неї пристрій для зберігання даних не може оновити статус цих блоків. Отже, блоки не очищаються у межах "збору сміття" та залишаються незмінними, доки пристрій не отримає інші інструкції.

Відновлення файлів: Оскільки TRIM не виконується, дані всередині блоків залишаються фізично недоторканими, хоча й стають недоступні через операційну систему. Програмне забезпечення для відновлення даних може отримати доступ до цих файлів і відновити їх. Ймовірність успіху залежатиме від ступеня пошкодження та специфіки відповідної файлової системи.

Останнє оновлення: 04 грудня 2024

Якщо вам сподобалася ця стаття, поділіться нею у соцмережах: