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

3-2-1: три копии данных (прод + две backup), два типа носителей, одна копия вне площадки. Два задания Veeam на \\backup.contoso.example\Repo01 — это одна копия на одном носителе. Доведите: primary Daily-VMs на Repo01 (или лучше hardened), backup copy на другой диск/ленту/object, третья линия — другой ЦОД/облако/сейф. Не сносите primary, «чтобы освободить место под 3-2-1».

PBS: локальный datastore + remote sync/S3. WSB: второй target не на том же RAID, что C:.

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

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

  • в презентации «бэкап есть», в инфраструктуре один share;
  • NAS: том iSCSI для VM и папка backup — одни диски;
  • «offsite» = второй шкаф в той же серверной;
  • GFS на том же Repo01, места нет, offsite нет.

Отличия:

ЕстьНет 3-2-1
Реплика VMРеплика — не backup; оба живые диски поражает ПО
Snapshot гипервизораНе копия на другом носителе
RAIDНе второй носитель
Два job, один repoОдна копия

См. нет offsite, если носители разные, но площадка одна.

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

  1. Исторически купили один NAS «на всё».
  2. Backup copy не настроили «потом».
  3. Облако запретили без альтернативы (лента/второй офис).
  4. Путают репликацию Hyper-V/PVE с backup.
  5. Место: держат 40 точек на одном диске вместо 14 локально + 30 copy.
  6. Политика «все яйца под админом ИТ» без бюджета на второй носитель.
  7. WSB только на D: того же сервера.
  8. PBS один диск, GC «экономит» вместо второй ноды.

Диагностика

1. Инвентарь копий Daily-VMs

Таблица: где лежат байты.

КопияГдеНосительПлощадкаКто может стереть
Продdatastore VMSSD RAIDОфис Aгипервизор-админ
Backup1\\backup.contoso.example\Repo01HDD NASОфис ADA
Backup2????

Пустой Backup2 — не соблюдено.

Connect-VBRServer -Server 'VBR01.contoso.example'
Get-VBRJob | Select-Object Name, JobType, IsScheduleEnabled
Get-VBRBackupRepository | Format-Table Name, Type, Path

Ищите JobType backup copy / отдельные repo. PBS: datastore list + remote.

2. Один шпиндель или нет

Серийники дисков, полка, СХД. «Repo01» на LUN той же СХД, что VM — один носитель в смысле пожара/контроллера.

3. RPO copy vs primary

Copy раз в неделю при primary каждый день — третья копия с другим RPO. Зафиксируйте, не притворяйтесь, что 3-2-1 закрывает суточный RPO offsite.

Решение

Сценарий A. Есть только Repo01

  1. Купить/выделить другой носитель (второй NAS, Linux repo, лента, object).
  2. Создать Backup Copy job с Daily-VMs на него, не второй Backup job тех же VM в тот же path.
  3. Дождаться появления точек copy.
  4. Только потом укорачивать retention primary, если цель — место.

Veeam 12: Backup Copy (immediate или periodic) — штатный путь. Не robocopy .vbk вручную как «вторая копия» без понимания цепочки.

Сценарий B. Два тома одного NAS

Это не два носителя. Вынесите copy на другую железку или object. Разделение LUN помогает администрировать, не пожар.

Сценарий C. Реплика «вместо» backup

Оставьте реплику для RTO. Backup всё равно нужен: порча данных реплицируется. 3-2-1 считает backup-копии, не два живых клона.

Сценарий D. PBS

Datastore A локально, sync на PBS-B или S3. Не два mount одного диска. Prune на сторонах независимый, не «удалить локально и надеяться».

Сценарий E. WSB

Второй target: USB/NAS другой, расписание. WSB слабо тянет полноценный 3-2-1 для VM-фермы — планируйте Veeam/PBS как primary.

Сценарий F. Offsite кусок

Когда два носителя на площадке есть — вынос. 3-2-1 без «1» не досчитан.

Не отключайте immutable на copy, «чтобы быстрее залить первичный объём».

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

  • Три строки в таблице заполнены, два разных типа media, одна площадка другая.
  • Тестовый restore с copy-репозитория, не с primary, в изоляции.
  • Отказ primary (стенд: offline Repo01) не мешает увидеть точки copy.
  • Документ RPO primary и RPO copy.
Get-VBRBackup | Select-Object JobName, Repository

Разные Repository для backup и copy.

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

  • Copy job пишет снова в Repo01 — неверный target.
  • Object есть, ключ delete у DA — это не устойчивая третья копия, см. ransomware/immutable.
  • Лента есть, не читали 2 года — носитель «есть» юридически, практически нет; проверка restore.

Не считайте snapshot 3-й копией. Не считайте «два каталога на одном NAS» двумя носителями: контроллер, БП и зал общие. Если после пожара в серверной A не остаётся ни одного байта Daily-VMs, 3-2-1 не выполнен, сколько бы job ни было зелёных.

Перед объявлением победы прогоните отказ: на стенде или в согласованное окно отключите Repo01 (не format) и убедитесь, что copy-репозиторий отдаёт FLR тестового файла. Замерьте минуты — это вход в RTO. Если copy пуст, primary ещё единственная копия: не укорачивайте retention primary «под 3-2-1 на бумаге».

Ленту в сейфе той же комнаты не записывайте как offsite. Кассету, которую не читали год, не записывайте как копию: это непроверенный носитель. Вывоз и last-read — обязательные поля журнала 3-2-1.

Не зовите «вторая СХД» 3-2-1, если обе полки в одном зале и питаются от одного ИБП. Сценарий отказа пишите конкретно: пожар, затопление, ransomware с DA, ошибка админа. Для каждого сценария должна выжить хотя бы одна копия Daily-VMs не на Repo01.

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

  • Любой новый job: строка «куда вторая копия».
  • Бюджет дисков backup отдельно от прод-СХД.
  • Раз в квартал пересмотр: не схлопнулись ли два repo на одну полку после «оптимизации».
  • Связка с RPO: 3-2-1 описывает устойчивость, RPO — свежесть.

FAQ

3-2-1-1-0 и прочие расширения?

Полезны (immutable, verified). Сначала закройте классику: у многих нет даже второй копии.

Достаточно ли RAID6 + реплика?

Нет. Ошибка админа и ransomware проходят сквозь RAID и реплику.

Backup copy нагрузит канал ночью

Periodic copy в окно, bandwidth limit в Veeam. Не отказ от 3-2-1.

Можно ли primary сразу в облако?

Можно как одна из копий; latency restore и счёт за egress — в RTO. Локальная копия всё ещё нужна для быстрого FLR.

Два VBR на один Repo01?

Ещё хуже: два мозга, одна шара. Не путайте с HA.

PBS + vzdump на тот же NFS

Часто один носитель. Считайте честно.