Нужного файла нет вчерашней точке: шаг назад по Daily-VMs до живой копии

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

Пользователь просит «вчерашний файл», а вчерашняя точка Daily-VMs уже содержит удаление, порчу или пустой VSS. Задача — найти последнюю точку, где объект ещё читается, и выгрузить его в другой каталог. Идите назад по restore points: вчера, позавчера, last full. Сверяйте путь, том, скрытые потоки, не тот диск в job.

Не restore поверх исходного файла, пока не сравнили хеш/открытие в песочнице. Мастер не стартует — сначала restore не запускается. Вся VM — VM restore.

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

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

• FLR: папка есть, файла нет;
• файл на месте, Excel/PDF не открывается — битый контент в этой точке;
• пользователь путает DFS-путь и реальный том;
• WSB: том не входил в backup;
• PBS: restore конкретного файлa из guest-index, путь не тот guest FS.

Отличия:

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

1. Файл создан/изменён после RPO точки.
2. Удалён до snapshot; в точке его уже нет.
3. Job не включает том/диск (D: не в Daily-VMs, WSB только C:).
4. Guest processing/VSS снял неконсистентный срез: файл открыт эксклюзивно, в копии 0 байт.
5. Неверный путь: профиль пользователя, DFS, junction, OneDrive redirect.
6. Индекс FLR устарел, файл на диске VM в точке есть (редко — проверяйте Entire VM disk browse).
7. Повреждение объекта в этой точке при целой VM.
8. Регистр/кодировка имени, путь длиннее лимита Windows при restore.

Диагностика

Плейсхолдеры: VBR01, Daily-VMs, \\backup.contoso.example\Repo01, файл например \\fs01.contoso.example\share\contracts\2026-Q3.xlsx.

1. Зафиксировать, что ищем

В заявке: полный UNC, сервер-владелец, том, время последнего известного good, кто удалил. Без этого FLR превращается в блуждание.

2. Список точек назад

Connect-VBRServer -Server 'VBR01.contoso.example'
Get-VBRBackup -Name 'Daily-VMs' | Get-VBRRestorePoint |
  Where-Object { $_.Name -match 'FS01' } |
  Sort-Object CreationTime -Descending |
  Format-Table Name, CreationTime, Type

Подставьте имя VM/машины, как в job. WSB:

wbadmin get versions -backupTarget:\\backup.contoso.example\Repo01

PBS: список snapshot VM, не «последний» автоматически.

3. FLR в тестовый каталог

Монтируйте точку, ищите файл. Не нашли — следующая более старая точка, не «пересоздать job».

Проверьте, входит ли диск:

• Veeam: Job → Storage / Objects, диск D: включён?
• WSB: Get-WBPolicy volumes.
• Гость: буква диска внутри VM vs том на гипервизоре.

4. Нулевой или битый файл

Если файл есть, но не открывается — это контент этой точки (или приложение). Скачайте в C:\RestoreTest\ и откройте там. Сравните с более старой точкой. Если все свежие битые, а точка недели давности целая — берите её и фиксируйте RPO.

Повреждение всего диска точки — копии повреждены.

5. VSS-исключения

SQL/PST/открытые базы могли не войти в файловый срез. Тогда нужен application-aware restore или restore VM на момент, не «файл из папки данных SQL».

Решение

Сценарий A. Файл есть в более старой точке

Выгрузите в \\fs01.contoso.example\restore-inbox\ или локальный RestoreTest. Отдайте владельцу сравнить. Не подменяйте оригинал без его «да».

Сценарий B. Файла нет ни в одной точке job

Том не бэкапился. Ищите другой job, WSB этой машины, снимок файлового сервера, теневые копии тома (это не замена backup, но иногда спасает, если том ещё жив):

vssadmin list shadows

Теневые копии на том же поражённом томе при ransomware часто уже бесполезны.

Сценарий C. Файл появился после backup

Честная потеря внутри RPO. Объясните владельцу временем точки. Дальше — RPO, не «магия restore».

Сценарий D. 0 байт из-за открытого файла

Ищите точку в простое (выходные) или application-aware / VM restore. Для будущего — VSS writers, не копирование открытого PST файловым job без обработки.

Сценарий E. PBS file restore

Путь внутри архива гостя: /drive-scsi0/path. Не Windows UNC. Список snapshot назад — тот же алгоритм «последняя годная».

Когда файл у вас в песочнице — антивирусная проверка перед выдачей в прод, если инцидент был malware.

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

• Файл открывается в тестовом каталоге.
• Размер и дата внутри точки понятны владельцу (не «как вчера в Excel», а как на момент backup).
• Контрольная сумма, если владелец её вёл.
• В заявке: какая точка (дата/время CreationTime), не «восстановили из backup».

Повторный FLR той же точки должен давать тот же байтовый результат.

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

• Индекс FLR пустой, Entire VM disk видит файл — обход через restore диска/VM в изолированную среду и копирование файла оттуда.
• Имя с спецсимволами — копируйте родительскую папку.
• DFS: бэкапили не тот target сервер.
• Все точки после даты X шифрованные файлы — остановите прод, первые минуты, offsite.

Не отключайте immutability. Не чистите точки «кроме одной».

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

• Application-aware для серверов с открытыми базами.
• Включение всех томов с пользовательскими данными в Daily-VMs.
• Регулярный тест FLR случайного файла — нет проверки.
• Пользователям: корзина/версионность share не заменяет backup, но снижает мелкие заявки.
• Документировать UNC → VM → job.

FAQ

Почему вчерашняя копия без файла, который «точно был»?

Удалён до 02:00, или смотрите не тот сервер DFS, или файл жил в профиле, а бэкапится только D:\share.

Можно ли restore папки целиком «на всякий случай»?

В тестовый каталог — да. На прод-share — получите коллизии имён и жалобы «пропали новые файлы».

Volume Shadow Copy на FS01 вместо Veeam?

Если том жив и тени не уничтожены — быстрый шанс. Это не репозиторий Repo01 и не 3-2-1.

FLR видит диск raw, без NTFS

Гостевой FS не смонтировался: шифрование диска, нестандартный раздел. Тогда restore VM/диска, не файл.

PBS: файла нет, хотя в госте был

Индекс мог не включать путь; restore всего диска в новый VMID и копируйте. Или snapshot старше.

Нужно ли останавливать Daily-VMs на время FLR?

Желательно не писать ту же цепочку тяжёлым job во время P1 restore; не обязательно Stop, если репозиторий тянет.