Данные пропали: не чинить вслепую, заморозить запись и не трогать Repo01

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

Первые минуты: остановить запись на поражённый том/VM, не запускать «починить» chkdsk/format/антивирус-лечение вслепую, не дать Daily-VMs снять новую точку с уже гнилых данных, если цель — откатиться назад. Проверить, что \\backup.contoso.example\Repo01 и offsite не монтируются с заражённых ПК. Дальше — выбор точки и restore в чистое по runbook, не original overwrite.

Это не полное расследование IR. Это стоп-кран, чтобы не добить остатки и копии.

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

Типичная потеря:

• пользователь удалил папку, корзины нет;
• шифровальщик, расширения файлов;
• сломалась СХД, том не монтируется;
• админ «восстановил» поверх более новой версии.

Отличия:

Дальнейший restore VM/файла — соседние статьи, после заморозки.

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

1. Хотят «починить за 5 минут» без точки восстановления.
2. Ночной job сам стартует и затирает цепочку инкрементом с зашифрованными данными (на неизменяемом repo инкремент просто станет бесполезным слоем — всё равно остановите, чтобы не грузить диск и не плодить грязь).
3. Антивирус карантин на .vbk.
4. chkdsk / repair-volume на умирающем массиве.
5. Restore original из последней точки, которая уже содержит порчу.
6. Выключение immutability «чтобы удалить грязные точки».
7. Перезагрузка DC/1С циклом.
8. Редкий: вывоз дисков без маркировки, путают прод и backup.

Диагностика

Параллельно, не глубокий разбор VSS:

1. Что пропало: шара, VM, база, одна папка.
2. С какого времени ещё видели good (человек, мониторинг).
3. Жив ли оригинал (можно ли только файл, не всю VM).
4. Идёт ли ещё запись (пользователи, job, реплика).
5. Доступны ли VBR01, Repo01, PBS, offsite с чистого jump, не с заражённого ПК.

Connect-VBRServer -Server 'VBR01.contoso.example'
Get-VBRJob -Name 'Daily-VMs' | Select-Object Name, IsRunning, LastResult
Get-VBRBackup -Name 'Daily-VMs' | Get-VBRRestorePoint |
  Sort-Object CreationTime -Descending | Select-Object -First 8 CreationTime, Type

Если job Running на поражённую VM — готовьтесь Stop после решения «не снимать грязь».

Не открывайте файлы с Repo01 на заражённом рабочем столе.

Решение

1. Заморозить запись на данные

• Отключить шару / перевести VM в паузу / остановить приложение, которое пишет.
• Сообщить пользователям не работать в 1С/файлах.
• Реплику, которая размазывает порчу, остановить (это не backup, но она уничтожит вторую живую копию).

Не выключайте гипервизор целиком без нужды — можете убить то, что ещё в RAM/не дописано, и усложнить IR.

2. Изолировать backup от заразы

• Не ходить на backup.contoso.example с поражённых сессий.
• Проверить, не открыт ли Repo01 с клиентских VLAN — если да, режьте SMB срочно (сетевой ACL).
• Не запускать лечение ransomware «на всём VLAN включая backup».

См. копии и ransomware.

3. Остановить грязный backup job

Stop-VBRJob -Job (Get-VBRJob -Name 'Daily-VMs')

Только если job сейчас снимает пострадавшие объекты. Дождитесь Stopped, snapshot hypervisor не бросайте Kill. PBS: не стартовать ручной backup этой VM.

WSB: не Backup Once «на всякий» на тот же target поверх здравого смысла.

4. Не чинить носитель вслепую

Подозрение на диск: снимок состояния, вендор СХД, не chkdsk /f первым движением на единственном томе. RAID foreign — не initialize.

5. Выбрать стратегию restore, не «последняя точка»

Если ransomware с 02:00, точка 02:30 уже грязная. Идите назад. Verify/открытие файла в RestoreTest. Файл, VM в изоляции.

6. Люди и документ

Открыть runbook, позвать владельца, не обещать «уже восстанавливаем original». Зафиксировать запрет: format, delete points, disable immutable, overwrite.

7. Когда можно снова писать на прод

Только после: чистая точка выбрана, restore в песочнице ок или осознанный риск владельца, malware не пишет, DNS/IP не split brain.

PBS/PVE: не qmrestore в тот же VMID в первые минуты.

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

• Запись на поражённые данные остановлена.
• Repo01/offsite не смонтированы с грязных ПК.
• Daily-VMs не Running по жертве.
• Есть список точек со временем, выбрана гипотеза good.
• Никто не format и не delete chain.
• Тикет с хронологией.

Дальше начинается штатный restore и IR, не эта памятка.

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

• Уже overwrite original: остановитесь, не второй overwrite. Смотрите, живы ли более старые точки и тени тома.
• Уже chkdsk: не повторять, оценить ущерб, restore в новое.
• Уже пустили IR в прод-сеть: выключить NIC restore, разбирать IP.
• Уже disable immutable: считать копии под угрозой, срочно offsite/IR изоляция, ротация учёток.

Не «ещё раз то же, вдруг прокатит».

Если уже успели запустить Daily-VMs по зашифрованным дискам — не удаляйте эту грязную точку: она маркирует время атаки. Откатывайтесь на более раннюю verified. Если уже открыли Repo01 с заражённого ПК — считайте online-копию под вопросом и ищите offsite/immutable, не «ещё один FLR с той же шары тем же сеансом».

Запись хронологии в тикет в первые пятнадцать минут экономит часы спора «когда началось». UTC плюс локальное время — оба.

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

• Памятка этой статьи — первая ссылка в runbook.
• Job не должен быть единственным, кто имеет write на данные и на repo с тех же учёток.
• Учения «удалили папку» 15 минут по чеклисту.
• Мониторинг ransomware-расширений и Failed job ночью.

FAQ

Нужно ли выключать всех из VPN?

Если ransomware расползается — да по IR. Если удалили один файл — избыточно. Классифицируйте за минуту.

Делать ли snapshot VM сейчас?

Если том ещё не зашифрован и это случайное удаление — snapshot/реплика могут помочь на живом. Если ransomware — snapshot на том же datastore часто тоже умрёт; не вместо Repo01. Не снимок вместо изоляции.

Антивирус full-scan прямо сейчас?

На живых данных может добить I/O. На backup-хосте — не с заражённого сканера с write. IR решает. Не карантин .vbk.

Пользователь просит «вернуть как было» original path сразу

Сначала копия в inbox. Original path — когда уверенность.

Job Success в 03:00, атака с 01:00

Точка 03:00 грязная. Не она.

Кто принимает решение stop 1С?

Владелец сервиса. ИТ описывает риск продолжения записи. Не молча три часа «пока разберёмся».