Як перетворити NTFS на ReFS?

Неможливо перетворити том NTFS на ReFS без втрати даних. Якщо ви хочете змінити файлову систему, вам потрібно буде переформатувати том.

Як перетворити ReFS на NTFS?

Якщо ви хочете перейти з ReFS на NTFS, то вам потрібно скопіювати дані в інше місце і відформатувати потрібний том у NTFS.

Як переформатувати том NTFS у ReFs за допомогою командного рядка (CMD) у Windows 10?

Для початку необхідно виконати підготовчі дії: Відкрийте редактор реєстру командою regedit та перейдіть наступним шляхом: HKEY_LOCAL_MACHINE-SYSTEM-CurrentControlSet-Control. Створіть в останньому підрозділі іще один підрозділ MiniNT, а в ньому створіть 32-бітовий параметр AllowRefsFormatOverNonmirrorVolume, і встановіть його значення як 1. Не закриваючи редактор реєстру, відкрийте у режимі адміністратора командний рядок та відформатуйте потрібний вам розділ такою командою, де S – буква форматованого розділу або диска: format S: /u /fs:refs /i:enable (Перед виконанням цієї команди вам необхідно створити резервну копію даних, оскільки форматування видаляє всі дані на диску. ). У разі успішного виконання команди, поверніться в редактор реєстру та видаліть створений раніше ключ MiniNT. У іншому випадку Windows 10 буде «думати», що працює в середовищі попередньої установки.

Як використовувати можливості ReFS щодо розподілу даних, дзеркального відображення та інших форм RAID? Чи забезпечує ReFS швидкість читання даних, яка потрібна, наприклад, для відеофайлів?

Система ReFS застосовує наявні в просторі зберігання можливості надмірності даних, у тому числі розподілені дзеркала та парність. Швидкість читання в системі ReFS буде приблизно на тому ж рівні, що і в системі NTFS, з якою вони мають багато спільного коду.

У яких випадках ReFS видаляє файли?

ReFS виявляє пошкодження метаданих, і виправити це неможливо. Це означає, що ReFS не знаходиться на надмірному томі Storage Spaces, де є інші копії даних на інших хостах, тому може виправити пошкоджену копію. ReFS виявляє пошкодження даних, і потоки цілісності увімкнені, і це неможливо виправити. Це означає, що якщо Integrity Stream не увімкнено, то файл буде доступний незалежно від того, пошкоджені дані чи ні. Якщо ReFS працює на дзеркальному томі з використанням дискових просторів, то копія буде автоматично виправлена.

Будова файлової системи ReFS та алгоритм відновлення даних

«ReFS» або «Resilient File System» – це нова файлова система, яка створена з використанням коду файлової системи «NTFS». Вона має свої переваги та недоліки. Ця файлова система призначена для вирішення основних проблем NTFS. Вона стійкіша до пошкодження даних, краще справляється з підвищеним навантаженням і легко масштабується для дуже великих файлових систем.

Зміст

Вступ

Файлова система ReFS є подальшим розвитком NTFS. підтримує точки повторної обробки (reparse points) – технологію, яка раніше містилася лише у файловій системі NTFS. Через точки повторної обробки реалізовано підтримку символьних посилань та точок монтування у Windows.

Основні функції:

Цілісність метаданих з контрольними сумами.
Integrity streams: метод запису даних на диск для додаткового захисту даних при пошкодженні частини диска.
Транзакційна модель «allocate on write» (copy on write).
Великі ліміти на розмір розділів, файлів та директорій.
Організація пулів та віртуалізація для більш простого створення розділів та керування файловою системою.
Сегментація послідовних даних data sriping для підвищення продуктивності, надлишковий запис для відмовостійкості.
Підтримка техніки чищення диска у фоновому режимі «disk scrubbing» для виявлення прихованих помилок.
Порятунок даних навколо пошкодженої ділянки на диску.
Загальні пули зберігання даних між машинами для додаткової відмовостійкості та балансування навантаження.
Сумісна з набором широко використовуваних функцій «NTFS».
Верифікація та автовиправлення даних.
Максимальна масштабованість.
Неможливість повного відключення файлової системи шляхом ізоляції помилкових ділянок.
Гнучка архітектура з використанням функції «Storage Spaces», яка задумана та реалізована спеціально для «ReFS».

«ReFS» успадкувала багато функцій та семантики «NTFS», включаючи шифрування «BitLocker», списки контролю доступу «ACL», журнал «USN», повідомлення про зміни, символьні посилання, точки з’єднання «junction points», точки монтування «mount points», точки повторної обробки «reparse points», знімки тома, «ID» файлів та «oplock».

Звичайно ж, дані з ReFS будуть доступні для клієнтів через ті ж API, які використовуються сьогодні в усіх операційних системах для доступу до розділів «NTFS».

Особливості

Перейти до перегляду

Программный RAID в Windows 10, функция Дисковое пространство и восстановление данных с RAID 💻⚕️🤔

Особливості файлової системи «ReFS»:

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

При виявленні пошкоджених даних, які не мають альтернативної копії відновлення, такі дані відразу ж будуть видалені з диска. Перезавантаження або вимкнення пристрою в такому випадку не потрібне, як у випадку з «NTFS».

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

Вища надійність зберігання даних. Для метаданих та вмісту файлів «ReFS» використовує B+ дерева. Розміри файлів, томів, кількість файлів у каталозі обмежені 64-бітним числом. А вільне місце на диску описується 3 окремими ієрархічними таблицями для малих, середніх та великих фрагментів вільного простору. Імена файлів та довжина шляху обмежена 32 кібібайтами, для зберігання яких використовується «Unicode».

Нова файлова система також стійка до пошкодження даних іншими способами. Наприклад, коли ви оновлюєте метадані файлу – наприклад, назва файлу – файлова система «NTFS» безпосередньо змінюватиме метадані файлу. Якщо комп’ютер вийде з ладу або вимикається живлення під час цього процесу, може статися пошкодження даних. Коли ви оновлюєте метадані файлу, файлова система ReFS створить нову копію метаданих. І надасть файлу оновлені метадані тільки після того, як будуть записані повністю нові. Немає небезпеки, що метадані файлу будуть пошкоджені. Це називається копіювання на запис «Copy-on-write».

«ReFS» інтегрується з технологією віртуалізації носіїв даних «Storage Spaces», яка дозволяє застосовувати відзеркалювання та об’єднувати кілька фізичних носіїв одного ПК або кількох по мережі.

Система не підтримує іменовані потоки файлів, короткі імена, стиснення та шифрування на рівні файлів «Encrypting File System», а також транзакції «NTFS», жорсткі посилання, «extended attributes», та дискові квоти.

Відмінності від NTFS

ReFS більш сучасна, ніж NTFS, і підтримує набагато більші обсяги та довші імена файлів. У довгостроковій перспективі – це важливі покращення.

У файловій системі «NTFS» шлях до файлу обмежений 255 символами. З «ReFS» Ім’я файлу може містити понад 30 тисяч символів (32768).

«NTFS» має теоретичний максимальний обсяг 16 ексабайт, а у «ReFS» теоретичний максимальний обсяг – понад двісті тисяч (262144) екзабайт. Наразі це великого значення не має і розраховане на майбутнє.

В «ReFS» відсутні деякі функції з NTFS, включаючи стиснення і шифрування файлової системи, жорсткі посилання, розширені атрибути, дедуплікацію даних і дискові квоти. Однак, «ReFS» сумісна з різними функціями. Наприклад, якщо ви не можете виконувати шифрування певних даних на рівні файлової системи, «ReFS» буде сумісна з повним типом шифрування «BitLocker».

Windows 10 не дозволить вам форматувати будь-який старий розділ як ReFS. Нині можна використовувати «ReFS» тільки для простору зберігання, де її функції допомагають захистити дані від пошкоджень. У Windows Server 2016 можна форматувати томи за допомогою ReFS замість NTFS. Використовувати «ReFS» для завантажувального тома не можна, тому що Windows може завантажуватися тільки з диска «NTFS».

На цей час тип файлової системи використовується тільки на серверних версіях Windows та у версії Windows Enterprise (LTSC).

Архітектура файлової системи

Попри часті згадки про схожість «ReFS» і «NTFS», на високому рівні йдеться лише про сумісність деяких структур метаданих. Дискова реалізація структури ReFS кардинально відрізняється від інших файлових систем Microsoft.

Основними структурними елементами цієї файлової системи є B+ дерева. Всі елементи структури файлової системи можуть бути однорівневими (листя) або багаторівневими (дерева). Такий підхід дозволяє масштабувати практично будь-який елемент файлової системи. Поряд із реальною 64-бітною адресацією всіх елементів системи це виключає появу «вузьких місць» при її подальшому масштабуванні.

Крім кореневого запису B+ дерева, всі інші записи мають розмір блоку метаданих – 16 КБ. Проміжні (адресні) вузли мають невеликий розмір близько 60 байтів. Тому зазвичай для опису дуже великих структур потрібна невелика кількість рівнів дерева. Такий підхід збільшує загальну продуктивність системи.

Основним структурним елементом файлової системи є «Каталог», представлений у вигляді B+ дерева, з ключем у вигляді номера об’єкта папки. На відміну від інших подібних файлових систем, файл у «ReFS» не є окремим ключовим елементом «Каталогу», а існує тільки як запис. Можливо, через цю архітектурну особливість «ReFS» не підтримує «жорсткі посилання».

«Листові» каталоги – це типізовані записи. Існує три основні типи записів для об’єкта папки: дескриптор каталогу, індексний запис та дескриптор вкладеного об’єкта. Всі записи упаковуються в окреме дерево з ідентифікатором папки. Його корінь – «лист» цього дерева. Це дозволяє записувати практично будь-яку кількість записів. На нижньому рівні в листі знаходиться запис дескриптора каталогу, який містить основну інформацію про каталог, таку як ім’я, стандартну інформацію, атрибут імені файлу і т.д.

Далі у каталозі перебувають записи покажчика: короткі структури з даними елементів каталога. У порівнянні з NTFS ці записи значно коротші, що меншою мірою перевантажує том метаданими. Останніми йдуть записи елементів каталогу. Для папок ці елементи містять ім’я папки, а також ідентифікатор папки в «Каталогу» та структуру «стандартної інформації». Для файлу ідентифікатор відсутній, але замість нього структура містить усі основні дані про файл, включаючи фрагменти файлу кореня – дерева. Тому файл може складатися практично з будь-якої кількості фрагментів.

Файли на диску розміщуються блоками по 64 КБ. Адресуються так само як блоки метаданих у кластерах по 16 КБ. «Резидентність» файлових даних у «ReFS» не підтримується, тому файл розміром 1 байт на диску займе весь блок розміром 64 КБ, що призводить до значної надмірності зберігання для невеликих файлів. З іншого боку, це спрощує керування вільним простором, і процес розподілу під нові файли виконується набагато швидше.

Розмір метаданих порожньої файлової системи становить близько 0,1% від розміру самої файлової системи (тобто близько 2 ГБ на томі в 2 ТБ). Деякі базові метадані дублюються, що підвищує стійкість від збоїв.

Структура файлової системи ReFS

Файлову систему «ReFS» можна визначити за наступною сигнатурою на самому початку розділу:

00 00 00 52 65 46 53 00 00 00 00 00 00 00 00 00 ...ReFS......... 46 53 52 53 XX XX XX XX XX XX XX XX XX XX XX XX FSRS

Сторінки ReFS мають довжину 0x4000 байт.

У всіх перевірених системах номер першої сторінки дорівнює 0x1e (0x78000 байт після завантажувального розділу, що містить файлову систему). Це вбудована документація Microsoft, в якій зазначено, що перший каталог метаданих знаходиться за фіксованим зміщенням на диску.

Інші сторінки містять різні структури і таблиці системи, каталогів і томів, а також версії кожної сторінки.

Перший байт кожної сторінки – її номер.

Перші 0x30 байтів кожної сторінки метаданих це Заголовок сторінки, які мають такий вигляд:

byte 0: XX XX 00 00 00 00 00 00 YY 00 00 00 00 00 00 00 byte 16: 00 00 00 00 00 00 00 00 ZZ ZZ 00 00 00 00 00 00 byte 32: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

dword 0 (XX XX) - номер сторінки, який є послідовним та відповідає зміщенню сторінки 0x4000;

dword 2 (YY) - номер журналу чи порядковий номер;

dword 6 (ZZ ZZ) - це «віртуальний номер сторінки», який не є послідовним.

Таблиця об'єкта Object Table, віртуальний номер сторінки 0x02 – пов'язує ідентифікатори об'єктів зі сторінками, на яких вони розташовані. Тут ми бачимо «AttributeList», що складається із записів «Key / Value pairs».

За якими можна знайти «ID» об'єкта кореневого каталогу та отримати сторінку, на якій він знаходиться:

50 00 00 00 10 00 10 00 00 00 20 00 30 00 00 00 – загальна довжина / межі ключів та значень 00 00 00 00 00 00 00 00 00 06 00 00 00 00 00 00 – ідентифікатор об'єкта F4 0A 00 00 00 00 00 00 00 00 02 08 08 00 00 00 – ідентифікатор сторінки/мітки CE 0F 85 14 83 01 DC 39 00 00 00 00 00 00 00 00 – контрольна сума 08 00 00 00 08 00 00 00 04 00 00 00 00 00 00 00

Запис таблиці об'єктів для кореневого каталогу, що містить його сторінку (0xAF4).

При отриманні сторінок за ID або віртуальним номером, шукайте ті, у яких найвищий порядковий номер, оскільки це останні копії механізму «shadow-write».

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

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

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

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

Структури у списку каталогів мають один із наступних форматів:

Базовий атрибут (Base Attribute)

Найпростіший базовий атрибут складається з блоку, довжина якого вказана на самому початку.

Нижче наведено приклад типового атрибуту:

a8 00 00 00 28 00 01 00 00 00 00 00 10 01 00 00 10 01 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a9 d3 a4 c3 27 dd d2 01 5f a0 58 f3 27 dd d2 01 5f a0 58 f3 27 dd d2 01 a9 d3 a4 c3 27 dd d2 01 20 00 00 00 00 00 00 00 00 06 00 00 00 00 00 00 03 00 00 00 00 00 00 00 5c 9a 07 ac 01 00 00 00 19 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Тут розділ довжиною 0xA8 містить чотири мітки часу файлу. Докладніше це можна побачити нижче:

a9 d3 a4 c3 27 dd d2 01 - 2017-06-04 07:43:20 5f a0 58 f3 27 dd d2 01 - 2017-06-04 07:44:40 5f a0 58 f3 27 dd d2 01 - 2017-06-04 07:44:40 a9 d3 a4 c3 27 dd d2 01 - 2017-06-04 07:43:20

Можна з упевненістю припустити, що:

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

Записи

«Key / Value pairs» – їх значення вказані у перших 0x20 байтах атрибута. Вони використовуються для пов'язаних розділів метаданих із файлами, імена яких записуються в ключах, а вміст – у значення.

Нижче наведено приклад типового запису:

40 04 00 00 10 00 1A 00 08 00 30 00 10 04 00 00 @.........0..... 30 00 01 00 6D 00 6F 00 66 00 69 00 6C 00 65 00 0...m.o.f.i.l.e. 31 00 2E 00 74 00 78 00 74 00 00 00 00 00 00 00 1...t.x.t....... A8 00 00 00 28 00 01 00 00 00 00 00 10 01 00 00 ¨...(........... 10 01 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 A9 D3 A4 C3 27 DD D2 01 ........©Ó¤Ã'ÝÒ. 5F A0 58 F3 27 DD D2 01 5F A0 58 F3 27 DD D2 01 _ Xó'ÝÒ._ Xó'ÝÒ. A9 D3 A4 C3 27 DD D2 01 20 00 00 00 00 00 00 00 ©Ó¤Ã'ÝÒ. ....... 00 06 00 00 00 00 00 00 03 00 00 00 00 00 00 00 ................ 5C 9A 07 AC 01 00 00 00 19 00 00 00 00 00 00 00 ..¬............ 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 20 00 00 00 A0 01 00 00 ........ ... ... D4 00 00 00 00 02 00 00 74 02 00 00 01 00 00 00 Ô.......t....... 78 02 00 00 00 00 00 00 ...(cutoff) x.......

Тут ми бачимо параметри запису, задані у першому рядку:

загальна довжина - 4 байта = 0x440
зміщення ключа - 2 байта = 0x10
довжина ключа - 2 байта = 0x1A
мітки / ідентифікатор - 2 байта = 0x08
зміщення значення - 2 байта = 0x30
довжина значення - 2 байта = 0x410

Запис закінчується після значення, 0x410 байтів з початку та після значення 0x30 або 0x440 (що збігається із загальною довжиною).

Запис відповідає файлу, створеному на диску.

Тут першим атрибутом у значенні запису є простий атрибут, який обговорювався вище, що містить часові мітки файлу. Потім слідує «File Reference Attribute List Header».

По мітках ми шукаємо записи зі значеннями «w/flag» '0' або '8'. Часто зустрічаються '4' що вказує на історичний запис або запис, який був змінений.

Оскільки записи мають префікс їхньої загальної довжини, їх можна розглядати як підклас «Attribute».

«AttributeList» (заголовок списку) – містить блок атрибутів.

На перший погляд, це прості атрибути довжиною 0x20, але при подальшому розгляді ми можемо бачити, що він містить довжину великого блоку атрибутів. Після аналізу «AttributeList», залишилося прочитати залишки заповнення байтів в списку, перш ніж перейти до наступного атрибуту.

20 00 00 00 A0 01 00 00 D4 00 00 00 00 02 00 00 - заголовок списку із зазначенням загальної довжини (0x1A0) та заповнення (0xD4) 74 02 00 00 01 00 00 00 78 02 00 00 00 00 00 00 80 01 00 00 10 00 0E 00 08 00 20 00 60 01 00 00 60 01 00 00 00 00 00 00 80 00 00 00 00 00 00 00 88 00 00 00 ... (розріз)

Directory Tree Branches (Гілки дерева каталогів)

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

При виявленні заголовка «AttributeList» зі значенням мітки «0x301» ми повинні:

перебрати атрибути у списку;
проаналізувати їх записи;
використовувати «dword» у кожному значенні в якості сторінки для повторення процесу обходу каталогу.

Додаткові файли та підкаталоги, знайдені на вказаних сторінках, мають бути додані до списку вмісту поточного каталогу.

SubDirectories

«SubDirectories» - це записи у списку атрибутів каталогу, ключ яких містить мітку метаданих каталогу (0x20030), а також ім'я підкаталогу.

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

Типовий підкаталог «Record»:

70 00 00 00 10 00 12 00 00 00 28 00 48 00 00 00 30 00 02 00 73 00 75 00 62 00 64 00 69 00 72 00 - тут ми бачимо ключ, який містить мітку (30 00 02 00), за яким слідує ім'я каталогу ("subdir2") 32 00 00 00 00 00 00 00 03 07 00 00 00 00 00 00 - тут ми бачимо ідентифікатор об'єкта та перше значення qword (0x730) 00 00 00 00 00 00 00 00 14 69 60 05 28 dd d2 01 - тут ми бачимо тимчасові мітки каталогу cc 87 ce 52 28 dd d2 01 cc 87 ce 52 28 dd d2 01 cc 87 ce 52 28 dd d2 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00

Подібні каталоги - це записи, ключ яких містить мітку (0x10030), за яким слідує ім'я файлу.

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

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

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

Другий атрибут є заголовком списку атрибутів, що містить «Посилання на файл».

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

---------------------------------------- | ... | ---------------------------------------- | File Entry Record | | Key: 0x10030 [FileName] | | Value: | | Attribute1: Timestamps | | Attribute2: | | File Reference List Header | | File Reference List Body(Record) | | Record Key: ? | | Record Value: | | File Length Attribute | | File Content List Header | | File Content Record(s) | | Padding | ---------------------------------------- | ... | ----------------------------------------

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

Що стосується фактичних значень, довжину файлу завжди видно з фіксованим зміщенням в межах його атрибуту (0x3c) і покажчик вмісту знаходиться у другому значенні «qword» файлу запису. Цей покажчик є простим посиланням на сторінку, вміст файлу якої можна прочитати дослівно.

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

Алгоритм пошуку програми для відновлення даних Hetman Partition Recovery

Перейти до перегляду

Вирішенням цієї проблеми буде спеціальна утиліта для швидкого відновлення даних.

Hetman Partition Recovery дозволяє проаналізувати дисковий простір під керуванням файлової системи ReFS за допомогою алгоритму сигнатурного аналізу. Аналізуючи пристрій сектор за сектором, програма знаходить певні послідовності байт та відображає їх користувачеві. Відновлення даних із дискового простору «ReFS» не відрізняється від роботи з файловою системою «NTFS».

Partition Recovery™ 4.9

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

Завантажити

При швидкому аналізі програма шукає заголовок тома «Volume Header» (у нульовому секторі), його копія лежить в останньому секторі. У заголовку знаходиться потрібна інформація для подальшого аналізу, а саме кількість байтів у секторі та кількість секторів у кластері. Потім, визначивши ці параметри, знаходить «Superblock», які лежать у 30-му блоці. Суперблок має 2 копії, одна знаходиться в третьому блоці з кінця, а друга в другому блоці. З суперблоку програма визначає посилання на чекпоїнти, є 2 чекпоїнти, вони знаходяться за вказаними адресами, що лежать у суперблоці. Перейшовши за цими двома адресами, програма знаходить Virtual Allocated Clock, за цим параметром визначає який з чекпоінтів наразі актуальний. Як відомо, Windows змінює спочатку 1 чекпоінт і тільки при успішному записі дублює інформацію в другий.

У чекпоінті (Checkpoint) знаходяться основні таблиці. З нього вичитується заголовок сторінки Page Header і потім блок з даними. По блоку з даними ми отримуємо поінтери (Pointers) кожної таблиці (посилання на всі основні таблиці).

Щоб переводити віртуальні адреси у фізичні, потрібно знайти «Container Table». І потім за віртуальною адресою йде пошук «Object ID Table» для того, щоб отримати всі таблиці.

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

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

Майбутнє нової файлової системи є досить туманним. Microsoft може допрацювати ReFS для заміни, застарілої NTFS у всіх версіях Windows. Тепер «ReFS» не може використовуватися повсюдно і служить лише для певних завдань.