Снимки заняли весь объем: retention на tank, не рубить живой dataset

Q: Rollback быстрее destroy?

`zfs rollback` отбрасывает **все данные новее** снимка. Это не «почистить место», это откат прод. Обычно нет.

Q: `.zfs/snapshot` видно пользователям SMB?

Зависит от `snapdir`. Скрытие не освобождает место.

Обновлено 8 сентября 2026 г.5 мин чтенияTrueNAS / TrueNAS SCALE · Ubuntu 22.04 LTS · Ubuntu 24.04 LTS · ZFS on Linux · Windows Server 2022

Короткий ответ

На CoW-ФС удалённый файл не освобождает место, пока жив снимок, в котором он есть. Смотрите zfs list -o space колонку USEDSNAP, не только df. Чистите по политике retention: старые @auto-..., не «все снимки» и не сам tank/share. На TrueNAS — Periodic Snapshot Tasks + TTL, затем destroy истекших. На Windows томе — VSS shadowstorage.

Симптомы и как отличить

Типичная картина:

пользователи удалили терабайт, df не двинулся;
zfs list -t snapshot сотни строк;
replication держит bookmark/snap на источнике;
SQL на zvol, hourly snap, unique writes раздули USED.

Колонка space	Смысл
USEDDS	живые данные
USEDSNAP	уникальное в снимках
USEDREFRESERV	reservation
USEDCHILD	дети

Если USEDSNAP ≈ USED пула — вы в этой статье. Thin 100% без snap — thin. Файл открыт процессом — удаление не освобождает.

Возможные причины

Task «ежечасно, хранить forever».
Вручную @before-patch забыли.
Replication не удаляет source snap.
Windows Previous Versions / VSS без лимита.
TrueNAS «hold» на снимке.
Clone от snap (jails, тестовые dataset).

Диагностика

1. ZFS

zfs list -o space -r tank
zfs list -t snapshot -o name,used,refer,creation -s creation tank
zfs list -t snapshot -o name,used -s used tank | tail

TrueNAS UI: Snapshots, сортировка по used.

zfs holds tank/share@auto-2026-01-01

Hold блокирует destroy.

2. Задачи

SCALE: Tasks → Periodic Snapshot. Сверьте Lifetime vs реальное число snap. Replication Tasks: «Delete stale snapshots» на destination и поведение source.

3. Windows

vssadmin list shadows
vssadmin list shadowstorage

Shadow на D: может быть 10–50% диска.

4. Кто зависит

zfs list -t all -o name,origin -r tank | grep -v '^-'

origin = clone из snap. Destroy snap не пройдёт, пока clone жив.

Решение

Сценарий A. Политика есть, TTL не применяется

Исправьте Lifetime в задаче, запустите prune (TrueNAS сам по TTL при проходе task). Вручную удаляйте пачками старых с проверкой имён.

zfs list -t snapshot -o name,creation tank/share

Затем по одному:

zfs destroy tank/share@auto-2025-03-01

Повторите zpool list. Если busy — holds/clone.

Сценарий B. Нужно много места сразу

Удаляйте снимки с наибольшим USED среди истёкших. Не трогайте вчерашний перед накатом.

Диапазон в man zfs destroy snap1%snap2 — только если понимаете синтаксис и список; ошибка диапазона снесёт нужное.

Сценарий C. Hold / replication

Снимите hold осознанно (zfs release). На реплике не чистите то, что ещё источник. Согласуйте обе стороны.

Сценарий D. Clone

Переведите clone на самостоятельный (promote) или удалите тестовый clone, затем snap.

Сценарий E. VSS

vssadmin resize shadowstorage /for=D: /on=D: /maxsize=10%

Удаление теней — vssadmin delete shadows с пониманием Previous Versions.

Политика retention пишется до аварии: hourly 24, daily 14, weekly 8, monthly 6, плюс ручные снимки только с заявкой. Когда места нет, вы не изобретаете политику, вы её исполняете. Если политики не было — список destroy в тикете, ок владельца данных, затем пачки.

Снимки репликации: hold и bookmark мешают удалить все auto. Сначала статус replication task. На destination prune часто безопаснее для прод-записи, но это может быть единственный offsite — не чистите обе стороны в один день.

Windows VSS на том же iSCSI LUN, что ZFS snap на NAS, даёт двойной CoW. Выберите один слой для пользовательского rollback, второй для DR, и не держите hourly оба.

Как проверить, что проблема устранена

zpool list tank AVAIL вырос соразмерно сумме UNIQUE удалённых snap (не сумме REFER). SMB снова пишет. Число snap ≈ policy (например 24 hourly + 7 daily). Holds пусты на уничтоженных. Replication следующий прогон зелёный.

Если не помогло

AVAIL не вырос: open files / thin mapping, не snap.
Destroy busy: clone/hold/backup mount .zfs/snapshot.
TrueNAS не удаляет: другая задача создаёт с тем же именем-префиксом.
zvol SQL: snap hourly уникален почти на 100% writes — меняйте политику, не только destroy раз.

Профилактика

TTL обязателен: hourly 24–48, daily 7–14, weekly по месту.
Алерт USEDSNAP и числа snap.
Не snapshot весь tank рекурсивно без нужды.
Учитывать снимки в ёмкости.
Документ: какие @manual неприкосновенны.

Снимки «на всякий случай» перед патчем должны иметь владельца и дату автоуничтожения в имени или в тикете. Без этого @before-upgrade живёт годами и становится самым дорогим USED в zfs list -s used. Раз в месяц аудит имён, не только auto-task.

Для zvol SQL hourly snap почти всегда уникален на объём записи журнала: это не backup, это ускоритель заполнения. Для БД используйте dump/backup job на другой репозиторий, а ZFS snap — реже и с понятным TTL.

Перед массовым destroy снимите zfs list -t snapshot -o name,used,creation в файл заявки. Это rollback-артефакт: если удалили лишнее, хотя бы видно, чего больше нет. Без файла через час никто не вспомнит порядок пачек.

FAQ

Rollback быстрее destroy?

zfs rollback отбрасывает все данные новее снимка. Это не «почистить место», это откат прод. Обычно нет.

`.zfs/snapshot` видно пользователям SMB?

Зависит от snapdir. Скрытие не освобождает место.

Можно ли сжатие вместо удаления snap?

Нет, блоки уже уникальны в прошлом.

TrueNAS «VM snapshots» vs ZFS snap?

Разные слои. Смотрите оба, если VM на zvol.

destroy % в одной команде на 200 snap — ок?

Технически да, операционно опасно. Пачки и проверка AVAIL между ними.