Проблема

При сбое питания во время записи страдает целостность файловой системы:
- Файл остаётся в состоянии «незавершённой транзакции» (partially written).
- Метаданные (inode, journal) повреждены – ОС видит битый файл, нулевой размер или ошибку ввода-вывода.
- На физическом носителе возможны bad sectors из-за внезапного парковки головок (HDD) / потери питания NAND (SSD).

Причины

1. Незавершённая запись journal’а (ext4, NTFS, APFS) – критично при отключении в момент flush-буфера.
2. B-tree / MFT corruption – сбой при изменении структуры каталогов (список файлов, атрибуты).
3. Кэширование записи без Flush (Write-back cache) – если отключён журнал или диск «слетел» до сброса.
4. SSD-контроллер – потеря питания во время сборки «мусора» (GC) может убить целый блок.

Решение


#### Шаг 1. Аппаратное клонирование (не работаем с оригиналом)
- Используй ddrescue (GNU) для создания побитовой копии:
bash
sudo ddrescue -f -n /dev/sdX /mnt/backup/disk.img /mnt/backup/disk.log

Параметр `-n` – skip bad sectors, не пытаемся читать дефект дважды.
- Для SSD – запрети включение до клонирования, если контроллер вышел из строя. Обращайся к ремонту (PC-3000) – это область аппаратной форензики, не DIY.

#### Шаг 2. Восстановление файловой системы через журнал
- ext4 на Linux:
bash
sudo fsck.ext4 -f /mnt/backup/disk.img

Если journal повреждён – `-b superblock` (бекап суперблока, находишь через `mke2fs -n`).
- NTFS (Windows / Linux):
bash
sudo ntfsfix /dev/loop0

Поверх – chkdsk /f на смонтированном образе (только на копии!).
- XFS:
bash
sudo xfs_repair -v /mnt/backup/disk.img


Если journal содержит частичную запись – fsck откатит незавершённый блок (потеря данных неизбежна для того самого файла, который писался в момент сбоя).

#### Шаг 3. Карвинг (сканирование по сигнатурам) для недоступных файлов
Когда файловая система критически разрушена, применяют восстановление данных после внезапного отключения питания через raw-сканеры:
- PhotoRec (бесплатно, кроссплатформенно):
bash
sudo photorec /log /d /recup /dev/loop0

Ищет JPEG, PDF, DOCX, ZIP, SQLite и т.д. по заголовкам. Не требует метаданных.
- DMDE (условно-бесплатно, Windows/Linux) – для сложных случаев (файлы в «слетевшем» RAID, сильно фрагментированные). Глубокая детекция восстановления из незавершенной транзакции ext4 если journal частично цел.

#### Шаг 4. Восстановление потерянной таблицы разделов
Если сбой привёл к тому, что раздел не виден, используй:
- TestDisk (тот же пакет, что и PhotoRec): `sudo testdisk /dev/sdX` → перестроить MBR/GPT, восстановить геометрию.
- После – запустить шаг 2 или 3 на восстановленном разделе.

Предупреждение

Никогда (!) не пиши новые данные на оригинальный носитель до полного клонирования. Одна запись – и фрагменты «переживших» сбой файлов могут быть затерты. Для систем на ext4 с включённым journal (по умолчанию) шансы потери не пишущегося в момент сбоя файла низкие, но сам файл, на который шла запись, – не спасти без карвинга (если он был единственной копией).