Проблема
Бэкапы (например, rsync, tar, Veeam) не обеспечивают мгновенное восстановление, защиту от атак шифровальщиков в реальном времени и детальный forensic-анализ изменений между состояниями. Snapshots решают эти задачи.

Причины
- Время восстановления (RTO) — бэкапы требуют распаковки/перезаписи данных (минуты–часы). Snapshot восстанавливается за секунды через `zfs rollback`.
- Forensic-фиксация — snapshot создаёт атомарный срез без пауз в работе, пригодный для анализа (сравнение дельт, поиск скрытых модификаций).
- Защита от шифровальщиков — при заражении можно откатить за секунды до snapshot’а, сделанного до инцидента, без полного восстановления из бэкапа.
- Тестирование обновлений/эксплойтов — моментальный откат после пентеста без затрат на повторный бэкап.
- Экономия места — snapshot потребляет только изменённые блоки (COW), бэкап — полные копии каждого файла.

Решение
1. Создавать snapshots с высокой частотой (каждые 5–15 мин) для быстрого rollback.
bash
zfs snapshot pool/data@incident_$(date +%Y%m%d_%H%M)

2. Автоматизировать через `zfs-auto-snapshot` (Linux) или `sanoid` — настройки для частоты и сроков хранения.
3. Бэкапы оставить для долгосрочного хранения (раз в сутки/неделю) на отдельный носитель (офлайн, S3).
4. При инциденте:
- определить точный момент заражения (по логам/системным событиям);
- найти snapshot до этого времени:
bash
zfs list -t snapshot -o name,creation

- откатиться:
bash
zfs rollback pool/data@clean_2024-03-01_1200

- экспортировать snapshot для судебной экспертизы:
bash
zfs send pool/data@forensic_copy > /mnt/evidence/data.raw


Итог: Snapshots — не замена бэкапам, а дополнительный слой для минимизации RTO, forensic-фиксации и быстрого реагирования на атаки. Без них бэкапы не дают оперативного контроля.