Як безпечно виправити пошкоджені файлові системи XFS і BTRFS в Unraid, не ризикуючи втратою даних

Диск фізично присутній, SMART не показує помилок, і масив Unraid запустився без проблем — але одна загальна папка (share) зникла, а WebGUI показує диск як Неможливо змонтувати. Це подія пошкодження файлової системи, яка відрізняється від апаратної відмови.

Паритет тут не допоможе. Паритетний диск зберігає побітову дзеркальну копію секторів даних, а не інформацію про цілісність метаданих файлової системи. Якщо журнал або суперблок на диску даних пошкоджені, паритет точно збереже це пошкодження. Відновлення з такого стану потребує безпосередньої роботи з інструментами відновлення файлової системи — xfs_repair для томів XFS та btrfs check для BTRFS — з терміналу Unraid.

Ситуація	Файлова система	Дія	Очікуваний результат
Диск не монтується, SMART без помилок	XFS	Режим обслуговування → `xfs_repair /dev/sdXp1` → перезавантаження	✅ Диск монтується, дані збережені
`xfs_repair` не вдається: помилка “dirty log”	XFS	`xfs_repair -L /dev/sdXp1` (обнуляє журнал)	⚠️ Диск монтується; файли, відкриті під час збою, можуть бути частковими або порожніми
Диск не монтується, SMART без помилок	BTRFS	`btrfs scrub` (змонтовано) → `btrfs check /dev/sdXp1` (тільки для читання) → оцінити помилки	✅ Незначні помилки: диск монтується після перевірки
`btrfs check` повідомляє про помилки дерева extent або chunk	BTRFS	Не використовуйте `--repair` → спочатку RS RAID Retrieve для відновлення на рівні файлів	⚠️ Часткове відновлення; структурний ремонт може спричинити додаткові втрати
Диск не монтується, SMART показує погані сектори	XFS / BTRFS	RS RAID Retrieve → Повний аналіз → відновлення на окремий диск → план заміни диска	⚠️ Файли можна відновити; апаратне забезпечення виходить з ладу — ремонт не буде надійним
Інструменти в терміналі не можуть змонтувати диск; після ремонту файли відсутні	XFS / BTRFS	Підключити диски до Windows-PC → RS RAID Retrieve → Fast Scan або Full Analysis	✅ Відновлення на рівні файлів без монтування файлової системи
На незмонтованому диску натиснуто “Format”	Будь-яка	Немає шляху для відновлення — паритет тепер відображає порожній диск	❌ Дані втрачені назавжди

Як Unraid використовує окремі файлові системи на кожному диску

У разі логічної відмови архітектура Unraid стає ключовим фактором для розуміння того, що пошкоджено, а що — ні.

На відміну від RAID 5 або RAID 6, де стріп (stripe) охоплює кілька фізичних дисків, Unraid записує файли цілком на окремі диски. Кожний диск з даними — це автономний том — відформатований як XFS або BTRFS — і монтується ОС незалежно. Верхній шар масиву Unraid займається агрегацією шейрів (shares) та оновленням парності, тоді як шар файлової системи під ним є стандартним для Linux.

⚡

XFS

За замовчуванням у Unraid

Характеристики, важливі для відновлення:

Відновлення метаданих на основі журналу
Для відновлення диск має бути відмонтований
У Unraid: вимагає режиму обслуговування
Основний інструмент: xfs_repair
Пошкодження журналу потребує ключа -L (руйнівна операція)

🌿

BTRFS

Необов’язково в Unraid

Характеристики, важливі для відновлення:

Копіювання-при-записі (copy-on-write); вбудовані контрольні суми для даних і метаданих
Перевірка може виконуватися на змонтованому томі
Режим відновлення (--repair) — агресивний, використовуйте з обережністю
Основні інструменти: btrfs check, btrfs scrub
Можливе відновлення субтомів навіть при частковій корупції

Практичний наслідок такої архітектури: пошкодження файлової системи на Диску 3 не впливає на файлові системи Диска 1, Диска 2 або будь-якого іншого диска. Дані кожного диска ізольовані. Ви відновлюєте один том, а не весь масив. Виняток — диск парності: у нього немає файлової системи, і його ніколи не слід піддавати інструментам відновлення файлових систем.

Диск парності не має файлової системи — ніколи не запускайте xfs_repair або btrfs check на ньому.

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

Що спричиняє пошкодження файлової системи в Unraid

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

🔌

Аварійне завершення роботи

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

🧠

Несправна оперативна пам’ять (RAM)

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

💾

Помилки секторів диска

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

Перед запуском будь-якого інструмента відновлення — спочатку перевірте SMART:

Відкрийте веб-інтерфейс Unraid → вкладка Main → виберіть уражений диск → звіт SMART.
Якщо Reallocated_Sector_Ct, Current_Pending_Sector або Offline_Uncorrectable не дорівнюють нулю, відновлення файлової системи може тимчасово спрацювати, але апаратна частина виходить з ладу. Плануйте заміну диска незалежно від результату відновлення.
Якщо SMART чистий, пошкодження найімовірніше було одиничним випадком через проблему з живленням або програмним забезпеченням, і відновлення має більші шанси залишитись ефективним у довгостроковій перспективі.

Кнопка Форматування: що вона насправді робить і чому її не слід натискати

Коли диск стає незмонтованим (Unmountable), у WebGUI Unraid поруч із кнопками діагностики з’являється опція «Формат». Для користувачів, які не знайомі з тим, як Unraid працює з парністю, це створює небезпечне хибне уявлення: нібито натискання «Формат» якимось чином відновить диск до робочого стану, а парність відтворить втрачені файли.

☠️

Форматування не відновлює дані. Воно їх назавжди знищує.

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

Це найпоширеніший сценарій втрати даних в Unraid, окрім апаратних відмов, і він повністю ініційований користувачем. Дані, що були на диску до натискання «Формат», у більшості випадків можна відновити за допомогою інструментів, описаних у цій статті.

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

Відновлення незмонтованого XFS-диска в Unraid: `xfs_repair` — крок за кроком

xfs_repair вимагає, щоб цільова файлова система була повністю відмонтована перед запуском. У працюючому масиві Unraid усі диски з даними змонтовані. Щоб відмонтрувати конкретний диск для відновлення без повної зупинки шарів (shares), Unraid потрібно перевести в режим обслуговування (Maintenance Mode) — режим запуску, який піднімає масив без змонтованих шарів і без активного використання дисків.

Крок 1: Запустіть масив у режимі обслуговування

У WebGUI Unraid перейдіть на вкладку Main. Перед натисканням кнопки Start встановіть позначку в чекбоксі Maintenance Mode, що з’являється під елементами керування запуском масиву. Натисніть Start. Масив запуститься, але жоден диск не буде змонтований до шарів (shares). Це необхідний стан для xfs_repair.

Unraid 7.0 і новіші: спочатку використовуйте кнопки відновлення у WebGUI.

Починаючи з Unraid 7.0, у перегляді дисків WebGUI відображає кнопки CHECK і FIX безпосередньо. Вони запускають xfs_repair з відповідними прапорцями автоматично. Якщо ваша версія це підтримує, спробуйте спочатку шлях через графічний інтерфейс перед відкриттям терміналу — результат буде ідентичним, але інтерфейс сам виконає перехід у Maintenance Mode та вибір шляху до пристрою за вас.

Крок 2: Визначте правильний шлях до пристрою

Цей крок запобігає поширеній і серйозній помилці. В Unraid кожен диск даних має два шляхи до пристрою:

/dev/mdXp1 — MD-пристрій (масив), яким керує рівень масиву Unraid. Не використовуйте цей шлях для xfs_repair.
/dev/sdXp1 — необроблений розділ диска, прямий апаратний шлях. Використовуйте цей шлях.

Щоб визначити, який /dev/sdX відповідає диску, який ви хочете відремонтувати, відкрийте термінал (у WebGUI: Tools → Terminal, або підключіться по SSH) і виконайте:

	# List disks with their Unraid slot assignments
	ls -la /dev/disk/by-id/

Зіставте серійний номер, показаний у SMART‑звіті WebGUI, із символічним посиланням у /dev/disk/by-id/, щоб підтвердити шлях до пристрою перед продовженням.

Крок 3: Запустіть xfs_repair — стандартний прохід

	# Replace sdX with your actual device identifier (e.g. sdb, sdc)
	xfs_repair
	/dev/sdXp1

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

Крок 4: Якщо xfs_repair завершується помилкою через «dirty log» — параметр -L

Якщо програма відновлення завершується повідомленням на кшталт “ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed” і відмовляється продовжувати, журнал неможливо прочитати. У такому випадку єдиний варіант — обнулити журнал за допомогою параметра -L.

Прапорець -L відкидає журнал — зрозумійте, що це означає

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

Використовуйте -L тільки після того, як стандартна спроба відновлення не дала результату. Не застосовуйте його як перший крок.

	# Примусове відновлення шляхом обнулення журналу
	# Використовувати лише після невдалої стандартної спроби xfs_repair
	xfs_repair
	-L
	/dev/sdXp1

Крок 5: Перевірка відновлення

Після успішного відновлення запустіть xfs_repair ще раз у режимі лише перевірки (-n) щоб переконатися, що більше немає невідповідностей:

	# Перевірка в режимі dry-run — не вносить змін, повідомляє про залишкові проблеми
	xfs_repair
	-n
	/dev/sdXp1

Якщо dry-run показує, що все чисто, перезавантажтеся в звичайному режимі (без режиму обслуговування). Диск має змонтуватися, а його шар повинен знову з’явитися. Після цього виконайте перевірку парності без виправлення помилок, щоб підтвердити коректність парності.

✓ Очікуваний вивід після успішного відновлення

xfs_repair виводитиме рядки завершення фаз (фази 1–7) і завершить роботу з повідомленням: “done”. У фазах 3–7 не повинно бути помилок. Будь-які файли, переміщені під час відновлення до /lost+found, будуть доступні там після монтування диска — їх можна перенести назад у початкові місця, якщо ви знаєте, куди вони належать.

Відновлення пошкодженого тому BTRFS в Unraid

Пошкодження BTRFS в Unraid трапляються рідше, ніж у XFS — частково через те, що BTRFS використовує семантику копіювання під час запису (copy-on-write, COW). Файлова система ніколи не перезаписує існуючі дані, а спочатку записує нові версії блоків у вільні області, що підвищує стійкість до неповних записів. Проте пошкодження метаданих все одно може статися, а процедури відновлення відрізняються від XFS у кількох важливих аспектах.

Крок 1: Почніть з btrfs scrub — а не btrfs check

Перед будь-яким ремонтом запустіть scrub на змонтованому томі. На відміну від xfs_repair, BTRFS scrub можна виконувати, поки файлова система змонтована. Він перевіряє контрольні суми всіх блоків даних і метаданих та повідомляє про будь-які невідповідності. На однодисковому томі Unraid без BTRFS RAID scrub не може автоматично виправляти помилки — немає надлишкових копій — але він точно виявить, які блоки пошкоджені, що є корисною інформацією перед вибором стратегії ремонту. Запустіть масив у звичайному режимі (не в режимі обслуговування) і відкрийте термінал:

	# Replace /mnt/diskX with the actual Unraid disk mount path
	btrfs scrub start
	/mnt/diskX
	# Monitor progress
	btrfs scrub status
	/mnt/diskX

Якщо scrub завершується без помилок, диск у доброму стані, і статус Unmountable міг бути тимчасовим. Перезавантажте систему та перевірте, чи диск змонтувався нормально.

Крок 2: Запустіть btrfs check у режимі лише для читання

Якщо scrub повідомляє про помилки або диск залишається немонтованим після спроби scrub, переходьте до btrfs check. Спочатку зупиніть масив, щоб відмонтувати диск, потім запустіть у режимі лише для читання, щоб оцінити масштаб пошкоджень перед будь‑яким відновленням:

	# Stop array first, then check without making changes
	btrfs check
	/dev/sdXp1

Уважно перегляньте вивід. btrfs check перераховує конкретні помилки в деревах і «сирітські» елементи. Невеликі невідповідності — сирітські іноди, неправильні зворотні посилання на корінь — зазвичай можна безпечно виправити. Помилки в extent‑дереві або chunk‑дереві свідчать про глибші структурні пошкодження, і відновлення в режимі ремонту може виявитися неповним.

Крок 3: Режим відновлення — застосовуйте з обережністю

btrfs check –repair може спричинити додаткову втрату даних

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

Якщо перевірка в режимі тільки для читання виявляє помилки дерева extent і на диску є незамінні дані, не запускайте режим відновлення — спочатку переходьте до RS RAID Retrieve для відновлення на рівні файлів, а вже потім пробуйте будь-які структурні виправлення.

Для незначних, добре окреслених пошкоджень — помилок кешу вільного простору, сирітських інодів, некоректних зворотних посилань кореня — режим відновлення зазвичай безпечний:

	# Only for minor, well-scoped corruption
	# Image the disk first if data is critical
	btrfs check
	--repair
	/dev/sdXp1

Крок 4: Відновлення окремих підтомів

Якщо верхній (топ‑рівневий) BTRFS‑дерево пошкоджене, але підтоми з даними залишилися цілими, інколи можливо змонтувати певний підтом без відновлення всього дерева та скопіювати з нього дані:

	# List subvolumes on a partially readable volume
	btrfs subvolume list
	/mnt/diskX
	# Mount a specific subvolume by ID if the default mount fails
	mount
	-o subvolid=256
	/dev/sdXp1 /mnt/recovery_point

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

Коли інструменти терміналу не допомагають: відновлення файлів з пошкодженого диска Unraid за допомогою RS RAID Retrieve

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

Саме тут працює RS RAID Retrieve. Програма читає дані секторів безпосередньо, обходячи пошкоджені структури файлової системи, і відтворює дерева каталогів та вміст файлів з основних таблиць розподілу. Вона підтримує як XFS, так і BTRFS — файлові системи, які Windows не може змонтувати напряму, тому стандартним робочим процесом є робота з Windows ПК із зовні підключеним диском.

Що робить RS RAID Retrieve з пошкодженим диском Unraid

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

RS Raid Retrieve

Автоматичне відновлення усіх типів RAID масивів

Спробувати Безкоштовно

Доступно для: Windows, macOS, Linux

Зупиніть сервер Unraid і вилучіть пошкоджений диск

Коректно вимкніть систему, якщо вона ще доступна. Підключіть пошкоджений диск до ПК з Windows — за можливості використовуйте пряме SATA-з’єднання. Також підключіть решту дисків масиву та паритетний диск: RS RAID Retrieve використовує їх для відновлення повної конфігурації масиву та для коректного визначення ролі кожного диска в структурі Unraid.

Запуск RS RAID Retrieve — автоматичне виявлення масиву

Під час запуску програма сканує всі підключені диски, читає метадані Unraid з кожного та автоматично відтворює конфігурацію масиву. Пошкоджений диск відображається в списку дисків поряд зі справними учасниками масиву. Windows не призначає літери дисків томам XFS або BTRFS; це очікувана поведінка й не свідчить про проблему з підключенням.

Виберіть тип сканування залежно від ступеня пошкодження

Клацніть правою кнопкою миші по реконструйованому масиву або по окремому диску в Drive Manager і виберіть Відкрити. У разі пошкодження файлової системи, коли таблиця розділів і суперблок залишилися цілими, достатньо Швидкого сканування — воно покаже дерево каталогів із підсвіченими для відновлення файлами. Якщо сам суперблок пошкоджений або Швидке сканування повертає порожнє дерево файлів, запустіть Повний аналіз — це виконує посекторне сканування за сигнатурами і може відновити файли навіть за відсутності метаданих каталогів, хоча імена файлів та шляхи можуть не зберегтися.

Перегляньте файли перед підтвердженням відновлення

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

Копіювання відновлених файлів на справний носій

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

Результати відшкодування за типом корупції

✅

Пошкодження журналу / некоректне завершення роботи

Найбільш піддається відновленню. Структури розподілу файлів зазвичай залишаються цілими. RS RAID Retrieve може відтворити повне дерево каталогів і відновити файли з початковими іменами та шляхами. Зазвичай достатньо швидкого сканування (Fast Scan).

⚠️

Часткове пошкодження метаданих

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

❌

Суперблок і дерево extent-ів зруйновано

Якщо диск було відформатовано після того, як він став Unmountable, або якщо фізичне пошкодження секторів знищило первинні та резервні суперблоки, відновлення на рівні файлів неможливе. Такий результат є рідкісним у чисто логічних збоях, але поширений, коли була натиснута кнопка «Format» або коли диск мав значне апаратне зношення.

Пошкодження файлової системи в Unraid у більшості випадків відновлюване — за умови дотримання правильної послідовності дій і якщо кнопку «Format» ніколи не натискали до того, як дані були збережені. Шлях прийняття рішення простий:

Логічна помилка не означає, що парність недійсна — але й не довіряйте їй беззастережно.

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

Поширені запитання

Зазвичай це означає, що апаратне забезпечення записує пошкоджені дані швидше, ніж їх встигає виправити засіб відновлення. xfs_repair виправив невідповідності в метаданих, які виявив під час запуску, але якщо на диску є сектори, що очікують переназначення або вже переназначені, нові записи під час перезавантаження — відтворення журналу, ініціалізація при монтуванні — могли потрапити на несправні блоки й знову спричинити корупцію. Успішний вивід xfs_repair не означає, що диск у хорошому стані; він лише свідчить, що файлова система була консистентною в момент виконання. Якщо це сталося, не запускайте xfs_repair вдруге. Вийміть диск, підключіть його до ПК з Windows і скористайтеся RS RAID Retrieve для вилучення даних, поки стан диска не погіршився далі. Після цього замініть апаратне забезпечення.

Це побічний ефект копіювання при записі (copy-on-write, COW) за певних умов. BTRFS не перезаписує існуючі блоки — він записує нові версії у вільний простір, а потім оновлює дерево метаданих, щоб вказувати на них. Якщо живлення перервалося між записом даних і фіксацією метаданих, нові дані можуть фізично існувати на диску, тоді як дерево каталогів все ще вказує на старе місце — яке могло бути частково перезаписане або взагалі не записане до кінця. Файли відображаються як порожні (0 байт), оскільки метадані не були оновлені. Запуск btrfs check у режимі тільки для читання зазвичай виявляє в цих областях осиротілі іноди. Модуль «Full Analysis» програми RS RAID Retrieve може знаходити фактичні блоки даних за їхніми контрольними сумами BTRFS навіть коли дерево каталогів більше не посилається на них правильно.

Так, і для будь‑якого диска з ненульовими SMART‑помилками це має вважатися обов’язковим, а не опціональним. Використовуйте ddrescue з map‑файлом, щоб перервані сеанси можна було відновити: ddrescue -d -r3 /dev/sdXp1 /path/to/image.img /path/to/map.log. Після отримання образу запускайте xfs_repair по файлу образу, а не по «живому» диску — xfs_repair /path/to/image.img. Якщо результат відновлення виявиться гіршим, ніж очікувалося, у вас усе одно залишиться оригінальна побітова (секторна) копія. Одне обмеження: диск‑призначення для образу має бути достатньо великим, щоб вмістити повний raw‑розмір вихідного розділу, а не лише використаний об’єм.

Частково. xfs_repair переміщує файли, чиї записи в каталозі були втрачені, до /lost+found і іменує їх за номером inode. Якщо ви пам’ятаєте приблизний розмір файлів, дати створення або типи вмісту, можна звузити коло кандидатів за допомогою stat для перевірки метаданих inode та file для визначення типу вмісту за бінарним заголовком — file /mnt/diskX/lost+found/123456789 покаже, чи містить інод JPEG, відеоконтейнер, стиснутий архів тощо. Для медіафайлів більшість можна ідентифікувати й перейменувати за вмістом. Для баз даних або даних додатків без читабельного заголовка ідентифікація складніша і може вимагати порівняння розмірів файлів з відомо справними резервними копіями або логами додатка, які зберегли оригінальні імена файлів.