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

Offsite — копия за пределы площадки (другой адрес, облако, сейф у хранителя), не соседний шкаф. С VBR01 настройте Backup Copy / capacity tier / ленту с вывозом на Daily-VMs. Канал: либо seed (диск курьером), либо лимит, чтобы ночной RPO primary на \\backup.contoso.example\Repo01 не умер из-за saturating WAN. PBS: remote sync на второй PBS/S3. WSB: второй target вне здания слабо автоматизируется — планируйте нормальный copy.

RPO offsite может быть хуже local (раз в сутки vs каждые 4 часа) — запишите это, не молчите.

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

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

  • пожар/затопление серверной = нулевые копии;
  • copy job Created, Last run never;
  • object bucket пустой, ключи есть в заявке с прошлого года;
  • «offsite» = Hyper-V Replica в соседнюю комнату.

Отличия:

ЭтоНе offsite
Другой этаж того же БЦта же площадка для многих страховых случаев
RAID-полка в том же зале3-2-1 носители
Репликаживые данные, не backup

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

  1. Канал 20 Мбит, полный full 8 ТБ, никто не считал seed.
  2. Юридический запрет облака без плана ленты.
  3. Нет бюджета на второй PBS/Veeam repo.
  4. Copy job в том же окне, что Daily-VMs, primary не успевает.
  5. DNS/firewall на object endpoint.
  6. Первая синхронизация оборвалась, job не возобновили.
  7. Ленты пишут, кассеты не вывозят.
  8. Редкий: провайдер «облака» = VM у того же хостера в той же стойке.

Диагностика

1. Где физически байты

Адрес: офис A. Есть ли байты Daily-VMs по другому адресу? Если нет — дыра.

2. Канал vs объём

Оцените размер полного набора + дневной инкремент (из session Daily-VMs: processed vs transferred). WAN: полезный Mbps. Время первой заливки = size/rate. Если недели — seed обязателен, не «попробуем job».

3. Состояние copy

Connect-VBRServer -Server 'VBR01.contoso.example'
Get-VBRJob | Where-Object { $_.Name -match 'Copy|Offsite' } |
  Select-Object Name, IsScheduleEnabled, LastResult

Подставьте свои имена. Пусто — job нет.

PBS:

proxmox-backup-manager sync-job list

(Имя подкоманды сверьте в proxmox-backup-manager help вашей PBS 3, если набор команд отличается — GUI Datacenter/Sync.)

4. RPO факт

Последняя точка на приёмнике. Если local вчера, remote месяц — offsite не закрывает заявленный суточный RPO.

Сверьте часовые пояса: точка на площадке B «вчера 23:00» при local «сегодня 02:00» может быть тем же слотом, а может отставать на сутки — смотрите CreationTime в UTC. WAN copy, оборванный на 90%, часто показывает Success на следующей ночи только для части VM: откройте session copy по объектам, не по галке job.

Канал делите с пользователями явно: QoS/маркировка backup, cap в свойствах copy job Veeam 12. Без cap первая догонка убьёт VoIP и «бизнес скажет выключить offsite». Лучше медленный, но ежедневный инкремент, чем выключенный job.

Решение

Сценарий A. Канал узкий, объём большой

  1. Seed: полный backup на диск, доставка на площадку B, импорт в репозиторий (процедура Veeam seed / вывоз диска).
  2. Дальше copy только инкрементов с лимитом Mbps в рабочее время, без лимита ночью — как позволяет прод-WAN.
  3. Не ставьте copy «immediate» на всём, если primary ещё пишет.

Сценарий B. Есть второй офис/ЦОД

Linux repo или второй VBR/repo там. Backup copy periodic после успеха Daily-VMs. VPN/прямая линк только с VBR01/gateway, не весь домен.

Сценарий C. Object storage

Capacity tier / copy в bucket другого региона. Object Lock. Проверьте, что регион не «тот же DC провайдера». Первая заливка — seed или выходные.

Сценарий D. PBS

Второй PBS за площадкой, sync job после backup window. Не синхронизировать в пик пользовательского VPN.

Сценарий E. Лента

Запись по расписанию, вывоз кассет, журнал где какая. Лента в том же сейфе серверной — не offsite.

Сценарий F. Copy ломает RPO primary

Разнести окна, bandwidth cap, копировать не все VM (ядро бизнеса nightly offsite, остальное 2× в неделю) — явно в политике RPO.

Не используйте robocopy поверх живой цепочки на WAN.

Первый seed диском: шифруйте носитель, ведите акт передачи, после импорта на площадке B уничтожьте или верните диск в сейф. Оставленный «на столе» seed — третья копия только на бумаге. После seed не запускайте полный copy заново «для уверенности»: догоняйте инкрементами, иначе снова убьёте канал.

Проверьте, что имя bucket/регион не совпадает с ЦОД, где стоит VBR01. «Облако того же хостера в той же стойке» не offsite при пожаре зала.

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

  • На площадке B есть точки Daily-VMs не старше согласованного offsite-RPO.
  • Restore-тест с площадки B (хотя бы файл) в изолированную среду.
  • Primary Daily-VMs по-прежнему укладывается в окно (сравните Duration до и после включения copy).
  • Документ: канал, cap, seed-дата.

Отключите (стенд) сеть к Repo01 — точки на B всё ещё видны.

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

  • Copy Success, точек мало: retention copy 1 — бессмысленно для DR; увеличьте keep на приёмнике.
  • WAN всё равно забит: job без cap, или пользовательский трафик в том же QoS — вынесите backup в маркировку QoS, не отключайте copy.
  • Облако пишет, restore не тестировали — для DR это фантазия; см. RTO.
  • Юристы запретили облако, ленту не завели — эскалируйте риск письменно, не «временно без offsite навсегда».

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

  • В паспорте сервиса: local RPO и offsite RPO.
  • Алерт: нет новой точки на remote N часов.
  • Раз в год: полный restore-тест с offsite (узкий scope).
  • Seed-процедура в runbook на случай нового полного набора (новый филиал).

FAQ

Соседнее здание кампуса — offsite?

Для пожара одной серверной — часто да. Для наводнения района / отключения площадки — нет. Определите угрозы.

Можно ли offsite только для DC и 1С?

Да, как этап. Честно напишите, что файловые серверы без offsite.

Immediate copy vs periodic?

Immediate ближе к RPO, жрёт канал. Periodic проще не мешать primary. Считайте.

Шифрование на WAN?

Включайте. Ключ не только на VBR01 в той же серверной без копии ключа offsite — иначе после пожара копии не откроете.

WSB + OneDrive?

Не контролируемый RPO/RTO, не 3-2-1 для серверов.

Отключить Daily-VMs на время первой заливки в облако?

Иногда на выходные для seed. Не на две недели без local backup.