Сегодня для вас — перевод статьи Игоря Архангельского про политики хранения резервных копий (проще говоря, ретеншен) в Veeam Backup for Microsoft Office 365.
Сейчас Игорь — инженер команды техподдержки, а до этого он занимался сетевыми технологиями, работая на крупнейших интернет-провайдеров. Там он получил опыт работы с оборудованием от популярных производителей — Cisco, Juniper, Huawei. Эти знания и навыки очень пригодились ему в его нынешней специализации, ведь очень многое (если не все) в решении Veeam Backup for Microsoft Office 365 (VBO365) завязано на передачу данных с использованием интернет-протоколов.
Итак, добро пожаловать под кат.
К инженерам техподдержки поступают самые разнообразные вопросы о ретеншене, начиная со стандартных “Как это работает?” и “Что будет, если…?” и до негодующих вроде “Я поменял настройки ретеншена, и куда теперь делись мои бэкапы?!”
В самом деле, настройки ретеншена (т.е. политики хранения) не прощают ошибок, и любое неверное решение угрожает сохранности вашего бэкапа. А самые частые проблемы — какие-то данные удаляются раньше, чем вы могли этого ожидать, или бэкапятся почему-то не тогда, когда вы этого ожидали. Поэтому я решил подробно разъяснить различия между типами ретеншена в VBO365 и на примерах показать, как его настройки применяются в ходе работы задания бэкапа.
Ретеншен бывает 2 типов: на основе снапошота и на уровне item-а.
Ретеншен на основе снапшота очень похож на политики хранения в Veeam Backup & Replication и Veeam Agents. То, как будут храниться точки восстановления, вы определяете в свойствах репозитория, указывая число дней (или лет):
Есть несколько отличий, связанных с файловой структурой исходных данных, но принцип практически такой же: в каждой точке восстановления должна храниться полная копия всех объектов, добавленных в задание бэкапа. Эта копия никак не изменяется за всё время хранения.
Такой тип ретеншена рекомендуется использовать, если вам нужно создать точную копию всех данных из Office 365 — и сохранять ее без изменений, работая с ней как с единым объектом (с точки зрения бэкапа и политик хранения).
Ретеншен на уровне item-а работает аналогично политикам хранения в Exchange Online:
Все данные в почтовом ящике Office 365 хранятся указанное количество дней (это настраивается в Exchange admin center). Если данные в течение этого срока не менялись, то они удаляются либо помещаются в архивную часть ящика (согласно настройкам).
Допустим, вы настроили ретеншен такого типа, указав срок хранения 7 дней — тогда в бэкап попадут только данные, которые за последние 7 дней были хоть раз изменены (считается, что раз с ними что-то произошло, то они, очевидно, нужны для работы, и их надо забэкапить).
Все остальные данные — те, у которых в поле Date Modified стоит более старая дата, чем 7 дней назад — не попадут в бэкап.
Важно! Эта логика будет применена не только в ходе работы задания, когда создается новая точка восстановления — но и при проверке уже созданных точек. То есть будут выявляться файлы, чья Date Modified старее, чем 7 дней назад. Об этом мы еще поговорим.
Такой тип ретеншена можно настроить, например, если вы хотите реплицировать не только данные Office 365, но и облачные политики хранения. Как правило, это сценарии, подпадающие под действие требований законодательства, которые гласят, что данные старше определенного возраста необходимо удалять. Второй вариант — когда нужно минимизировать место на диске под полный бэкап.
Хотя этот тип ретеншена изначально был разработан для Office 365 Exchange Mailbox (и Archive), в работе Veeam Backup for Microsoft Office 365 его можно применить и для бэкапов OneDrive, SharePoint или Teams.
Теперь посмотрим, как эти типы ретеншена сработают на отрезке в несколько дней, а попутно выясним, на какие особенности надо обратить внимание при их использовании.
Возьмем простой сценарий: у пользователя есть мейлбокс с 3 сообщениями, а также 3 файла в хранилище OneDrive for Business.
Настройки примем такие:
При первом запуске каждое задание бэкапа создает полную резервную копию.
22.08.2019 00:01 am: Время применить настройки ретеншена, но репозиторий пока еще пуст, поэтому ничего не происходит.
Ретеншен на основе снапшота
Задание при каждом запуске должно бэкапить все айтемы из продакшена.
22.08.2019 01:00 am: Задание для OneDrive стартует и бэкапит все файлы.
22.08.2019 02:00 am: Задание для Exchange стартует и бэкапит все файлы.
Ретеншен на уровне айтема
Задание при каждом запуске должно бэкапить лишь айтемы, у которых дата последнего изменения свежее, чем 3 дня назад.
22.08.2019 01:00 am: Задание OneDrive стартует и бэкапит только айтем “4.log”, ибо дата последнего изменения для остальных айтемов более давняя, чем 3 дня назад.
22.08.2019 02:00 am: Задание Exchange стартует и бэкапит айтемы “2.msg” и “3.msg”, ибо эти сообщения были получены в течение последних 3 дней.
Посмотрим, что произойдет при следующем запуске для сценария, когда в Office 365 никакие файлы не изменились.
Ретеншен на основе снапшота
23.08.2019 01:00 am: Задание OneDrive стартует и использует фичу Veeam change tracking (отслеживание изменений), чтобы убедиться, что в ходе предыдущего запуска все айтемы были забэкаплены и никак не изменились между запусками. После этого в новую точку восстановления попадают не те же самые айтемы из Office 365 — нет нужды еще раз их скачивать, раз они не изменились — а создается ссылка на исходные айтемы.
23.08.2019 02:00 am: Задание Exchange стартует и использует фичу Exchange Web Services change tracking (отслеживание изменений), чтобы убедиться, что в ходе предыдущего запуска все айтемы были забэкаплены и никак не изменились между запусками. После этого все аналогично — в новую точку восстановления включается ссылка на исходные айтемы.
Ретеншен на уровне айтема
23.08.2019 01:00 am: Задание OneDrive стартует и использует фичу Veeam change tracking, чтобы убедиться, что в ходе предыдущего запуска айтем “4.log” был забэкаплен и никак не изменился между запусками. После этого в новую точку восстановления попадает не тот же самый айтем целиком, а создается ссылка на него.
23.08.2019 02:00 am: Задание Exchange стартует и использует фичу Exchange Web Services change tracking feature, чтобы убедиться, что в ходе предыдущего запуска айтемы “2.msg” and “3.msg” были забэкаплены и никак не изменились между запусками. После этого все аналогично — в новую точку восстановления включается ссылка на исходные айтемы.
Если файл был создан или изменен, задание должно, соответственно, создать новую запись или обновить существующую. Например, если в ящик упало новое письмо, то для него задание создаст новую запись в репозитории.
Ретеншен на основе снапшота
23.08.2019 02:20 pm: Наш пользователь получает новое письмо в свой мейлбокс
24.08.2019 02:00 am: Задание Exchange стартует и использует фичу Exchange Web Services change tracking (отслеживание изменений), чтобы убедиться, что в ходе предыдущего запуска все айтемы были забэкаплены и никак не изменились между запусками. После этого в новую точку восстановления включается ссылка на исходные айтемы.
Ретеншен на уровне айтема
23.08.2019 02:20 pm: Наш пользователь получает новое письмо в свой мейлбокс
24.08.2019 01:00 am: Задание OneDrive стартует и использует фичу Veeam change tracking feature, чтобы убедиться, что в ходе предыдущего запуска айтем “4.log” был забэкаплен и никак не изменился между запусками. После этого в новую точку восстановления попадает не тот же самый айтем целиком, а создается ссылка на него. Задание также забэкапит файл “1.docx”, ибо дата последнего изменения для него теперь более свежая, чем 3 дня тому назад.
24.08.2019 02:00 am: Задание Exchange стартует и использует фичу Exchange Web Services change tracking, чтобы что в ходе предыдущего запуска айтемы “2.msg” and “3.msg” были забэкаплены и никак не изменились между запусками. После этого в новую точку восстановления включается ссылка на исходные айтемы.
Теперь посмотрим, как будут применены обе настройки. Перейдем на сутки вперед, на 25.08.2019 — я специально сфокусируюсь на этом моменте, поскольку именно в это время будет происходить самое важное (до этого наши задания ничего не удаляли, только проверяли наличие изменений).
Ретеншен на основе снапшота
25.08.2019 00:01 am: Применяется политика хранения. Согласно ей, удаляются все бэкапы, созданные до 23.08.2019 00:01 — поскольку теперь с момента их создания прошло больше 48 часов. (Помните, в самом начале мы постановили: ретеншен для данных на основе снапшота (snapshot-based) — 2 дня.)
Ретеншен на уровне айтема
25.08.2019 00:01 am: Применяется политика хранения. Согласно ей, удаляются файлы “4.log”, “2.msg” и “3.msg” из всех точек восстановления — поскольку дата их последнего изменения теперь старее, чем 3 дня (В самом начале мы постановили: ретеншен для данных на уровне айтема (item-level) — 3 дня.)
Что случится, если заданию не удастся создать новую точку восстановления для объекта?
В таком случае применение политики хранения будет отложено до тех пор, пока создание новой точки не увенчается успехом. Такая логика работает для обоих типов ретеншена, так что для примера мы рассмотрим только сценарий с данными на основе снапшота.
25.08.2019 01:00 am: Задание OneDrive стартует и тут же завершается с ошибкой, не обработав ни одного объекта (причиной, допустим, стало отключение сервера от интернета).
25.08.2019 02:00 am: То же самое происходит и с заданием Exchange.
26.08.2019 00:01 am: Применяется политика хранения. Согласно ей, удаляются все бэкапы, созданные до 24.08.2019 00:01 am — поскольку теперь с момента их создания прошло больше 48 часов.
26.08.2019 01:00 am: Задание OneDrive стартует и снова завершается с ошибкой по той же причине.
26.08.2019 02:00 am:То же самое происходит и с заданием Exchange.
26.08.2019 11:00 am: Проблема с интернетом устранена.
27.08.2019 00:01 am: Применяется политика хранения. Она не удаляет никакие файлы из репозитория — хотя дата и время бэкапа и не подпадают под условия политики хранения (48 часов). Так происходит потому, что политика сохраняет последний успешно созданный бэкап всё то время, пока происходят неуспешные попытки. Этот бэкап будет храниться до тех пор, пока не будет успешно создан новый.
27.08.2019 01:00 am: Задание OneDrive стартует и успешно создает новую точку восстановления. Затем оно удаляет старую точку, созданную 24.08, поскольку она не подлежит хранению согласно политике, и при этом уже есть успешно созданная новая точка.
27.08.2019 02:00 am: Аналогично отрабатывает и задание Exchange.
Важно понимать, что эта логика применяется только в случае неуспешной отработки задания. Если задание просто деактивировано галочкой в UI, никаких ожиданий точек не будет, ретеншен отработает как обычно.
Если вы когда-нибудь заглядывали в локальный репозиторий Veeam, то вы, возможно, помните, что там нет резервных копий писем или документов как отдельных файлов. А имеется там структура наподобие вот такой:
В каждой папке лежит контейнер БД — это файл repository.adb, куда и складываются все бэкапы. Когда программа решает, куда положить конкретный файл, она смотрит на дату последнего изменения (то самое поле Date modified в Office 365).
Когда же согласно ретеншену приходит время удалить данные из репозитория, то чаще всего это не физическое удаление — а просто блок данных в repository.adb помечается как пустой. Сам контейнер repository.adb удаляется только после того, как все данные внутри него были удалены по ретеншену. Но мы позаботились об эффективности использования места: блоки, помеченные как пустые, будут переиспользованы для хранения новых бэкапов.
Важно! Все вышеописанное не относится к объектным хранилищам (object storage repositories), поскольку их архитектура кардинально отличается и заслуживает отдельного разговора.
Сейчас Игорь — инженер команды техподдержки, а до этого он занимался сетевыми технологиями, работая на крупнейших интернет-провайдеров. Там он получил опыт работы с оборудованием от популярных производителей — Cisco, Juniper, Huawei. Эти знания и навыки очень пригодились ему в его нынешней специализации, ведь очень многое (если не все) в решении Veeam Backup for Microsoft Office 365 (VBO365) завязано на передачу данных с использованием интернет-протоколов.
Итак, добро пожаловать под кат.
К инженерам техподдержки поступают самые разнообразные вопросы о ретеншене, начиная со стандартных “Как это работает?” и “Что будет, если…?” и до негодующих вроде “Я поменял настройки ретеншена, и куда теперь делись мои бэкапы?!”
В самом деле, настройки ретеншена (т.е. политики хранения) не прощают ошибок, и любое неверное решение угрожает сохранности вашего бэкапа. А самые частые проблемы — какие-то данные удаляются раньше, чем вы могли этого ожидать, или бэкапятся почему-то не тогда, когда вы этого ожидали. Поэтому я решил подробно разъяснить различия между типами ретеншена в VBO365 и на примерах показать, как его настройки применяются в ходе работы задания бэкапа.
Ретеншен бывает 2 типов: на основе снапошота и на уровне item-а.
Ретеншен на основе снапшота очень похож на политики хранения в Veeam Backup & Replication и Veeam Agents. То, как будут храниться точки восстановления, вы определяете в свойствах репозитория, указывая число дней (или лет):
Есть несколько отличий, связанных с файловой структурой исходных данных, но принцип практически такой же: в каждой точке восстановления должна храниться полная копия всех объектов, добавленных в задание бэкапа. Эта копия никак не изменяется за всё время хранения.
Такой тип ретеншена рекомендуется использовать, если вам нужно создать точную копию всех данных из Office 365 — и сохранять ее без изменений, работая с ней как с единым объектом (с точки зрения бэкапа и политик хранения).
Ретеншен на уровне item-а работает аналогично политикам хранения в Exchange Online:
Все данные в почтовом ящике Office 365 хранятся указанное количество дней (это настраивается в Exchange admin center). Если данные в течение этого срока не менялись, то они удаляются либо помещаются в архивную часть ящика (согласно настройкам).
Допустим, вы настроили ретеншен такого типа, указав срок хранения 7 дней — тогда в бэкап попадут только данные, которые за последние 7 дней были хоть раз изменены (считается, что раз с ними что-то произошло, то они, очевидно, нужны для работы, и их надо забэкапить).
Все остальные данные — те, у которых в поле Date Modified стоит более старая дата, чем 7 дней назад — не попадут в бэкап.
Важно! Эта логика будет применена не только в ходе работы задания, когда создается новая точка восстановления — но и при проверке уже созданных точек. То есть будут выявляться файлы, чья Date Modified старее, чем 7 дней назад. Об этом мы еще поговорим.
Такой тип ретеншена можно настроить, например, если вы хотите реплицировать не только данные Office 365, но и облачные политики хранения. Как правило, это сценарии, подпадающие под действие требований законодательства, которые гласят, что данные старше определенного возраста необходимо удалять. Второй вариант — когда нужно минимизировать место на диске под полный бэкап.
Хотя этот тип ретеншена изначально был разработан для Office 365 Exchange Mailbox (и Archive), в работе Veeam Backup for Microsoft Office 365 его можно применить и для бэкапов OneDrive, SharePoint или Teams.
Примеры в картинках
Теперь посмотрим, как эти типы ретеншена сработают на отрезке в несколько дней, а попутно выясним, на какие особенности надо обратить внимание при их использовании.
Возьмем простой сценарий: у пользователя есть мейлбокс с 3 сообщениями, а также 3 файла в хранилище OneDrive for Business.
Настройки примем такие:
- Для бэкапа данных OneDrive и Exchange используются отдельные задания:
- Бэкап OneDrive запускается ежедневно в 01:00 ночи (далее и на иллюстрациях будем писать AM — после полуночи)
- Бэкап Exchange запускается ежедневно в 02:00 ночи
- Для одного репозитория задан ретеншен на уровне айтема (item-level) — 3 дня
- Для другого репозитория задан ретеншен на основе снапшота (snapshot-based) — 2 дня
- Настройки ретеншена применяются к обоим репозиториям в ежедневно в 00:01 АМ.
Полный бэкап
При первом запуске каждое задание бэкапа создает полную резервную копию.
22.08.2019 00:01 am: Время применить настройки ретеншена, но репозиторий пока еще пуст, поэтому ничего не происходит.
Ретеншен на основе снапшота
Задание при каждом запуске должно бэкапить все айтемы из продакшена.
22.08.2019 01:00 am: Задание для OneDrive стартует и бэкапит все файлы.
22.08.2019 02:00 am: Задание для Exchange стартует и бэкапит все файлы.
Ретеншен на уровне айтема
Задание при каждом запуске должно бэкапить лишь айтемы, у которых дата последнего изменения свежее, чем 3 дня назад.
22.08.2019 01:00 am: Задание OneDrive стартует и бэкапит только айтем “4.log”, ибо дата последнего изменения для остальных айтемов более давняя, чем 3 дня назад.
22.08.2019 02:00 am: Задание Exchange стартует и бэкапит айтемы “2.msg” и “3.msg”, ибо эти сообщения были получены в течение последних 3 дней.
Инкрементальный бэкап неизмененного файла
Посмотрим, что произойдет при следующем запуске для сценария, когда в Office 365 никакие файлы не изменились.
Ретеншен на основе снапшота
23.08.2019 01:00 am: Задание OneDrive стартует и использует фичу Veeam change tracking (отслеживание изменений), чтобы убедиться, что в ходе предыдущего запуска все айтемы были забэкаплены и никак не изменились между запусками. После этого в новую точку восстановления попадают не те же самые айтемы из Office 365 — нет нужды еще раз их скачивать, раз они не изменились — а создается ссылка на исходные айтемы.
23.08.2019 02:00 am: Задание Exchange стартует и использует фичу Exchange Web Services change tracking (отслеживание изменений), чтобы убедиться, что в ходе предыдущего запуска все айтемы были забэкаплены и никак не изменились между запусками. После этого все аналогично — в новую точку восстановления включается ссылка на исходные айтемы.
Ретеншен на уровне айтема
23.08.2019 01:00 am: Задание OneDrive стартует и использует фичу Veeam change tracking, чтобы убедиться, что в ходе предыдущего запуска айтем “4.log” был забэкаплен и никак не изменился между запусками. После этого в новую точку восстановления попадает не тот же самый айтем целиком, а создается ссылка на него.
23.08.2019 02:00 am: Задание Exchange стартует и использует фичу Exchange Web Services change tracking feature, чтобы убедиться, что в ходе предыдущего запуска айтемы “2.msg” and “3.msg” были забэкаплены и никак не изменились между запусками. После этого все аналогично — в новую точку восстановления включается ссылка на исходные айтемы.
Инкрементальный бэкап новых или измененных файлов
Если файл был создан или изменен, задание должно, соответственно, создать новую запись или обновить существующую. Например, если в ящик упало новое письмо, то для него задание создаст новую запись в репозитории.
Ретеншен на основе снапшота
23.08.2019 02:20 pm: Наш пользователь получает новое письмо в свой мейлбокс
24.08.2019 02:00 am: Задание Exchange стартует и использует фичу Exchange Web Services change tracking (отслеживание изменений), чтобы убедиться, что в ходе предыдущего запуска все айтемы были забэкаплены и никак не изменились между запусками. После этого в новую точку восстановления включается ссылка на исходные айтемы.
Ретеншен на уровне айтема
23.08.2019 02:20 pm: Наш пользователь получает новое письмо в свой мейлбокс
24.08.2019 01:00 am: Задание OneDrive стартует и использует фичу Veeam change tracking feature, чтобы убедиться, что в ходе предыдущего запуска айтем “4.log” был забэкаплен и никак не изменился между запусками. После этого в новую точку восстановления попадает не тот же самый айтем целиком, а создается ссылка на него. Задание также забэкапит файл “1.docx”, ибо дата последнего изменения для него теперь более свежая, чем 3 дня тому назад.
24.08.2019 02:00 am: Задание Exchange стартует и использует фичу Exchange Web Services change tracking, чтобы что в ходе предыдущего запуска айтемы “2.msg” and “3.msg” были забэкаплены и никак не изменились между запусками. После этого в новую точку восстановления включается ссылка на исходные айтемы.
Применение политики хранения
Теперь посмотрим, как будут применены обе настройки. Перейдем на сутки вперед, на 25.08.2019 — я специально сфокусируюсь на этом моменте, поскольку именно в это время будет происходить самое важное (до этого наши задания ничего не удаляли, только проверяли наличие изменений).
Ретеншен на основе снапшота
25.08.2019 00:01 am: Применяется политика хранения. Согласно ей, удаляются все бэкапы, созданные до 23.08.2019 00:01 — поскольку теперь с момента их создания прошло больше 48 часов. (Помните, в самом начале мы постановили: ретеншен для данных на основе снапшота (snapshot-based) — 2 дня.)
Ретеншен на уровне айтема
25.08.2019 00:01 am: Применяется политика хранения. Согласно ей, удаляются файлы “4.log”, “2.msg” и “3.msg” из всех точек восстановления — поскольку дата их последнего изменения теперь старее, чем 3 дня (В самом начале мы постановили: ретеншен для данных на уровне айтема (item-level) — 3 дня.)
Что случится, если заданию не удастся создать новую точку восстановления для объекта?
В таком случае применение политики хранения будет отложено до тех пор, пока создание новой точки не увенчается успехом. Такая логика работает для обоих типов ретеншена, так что для примера мы рассмотрим только сценарий с данными на основе снапшота.
25.08.2019 01:00 am: Задание OneDrive стартует и тут же завершается с ошибкой, не обработав ни одного объекта (причиной, допустим, стало отключение сервера от интернета).
25.08.2019 02:00 am: То же самое происходит и с заданием Exchange.
26.08.2019 00:01 am: Применяется политика хранения. Согласно ей, удаляются все бэкапы, созданные до 24.08.2019 00:01 am — поскольку теперь с момента их создания прошло больше 48 часов.
26.08.2019 01:00 am: Задание OneDrive стартует и снова завершается с ошибкой по той же причине.
26.08.2019 02:00 am:То же самое происходит и с заданием Exchange.
26.08.2019 11:00 am: Проблема с интернетом устранена.
27.08.2019 00:01 am: Применяется политика хранения. Она не удаляет никакие файлы из репозитория — хотя дата и время бэкапа и не подпадают под условия политики хранения (48 часов). Так происходит потому, что политика сохраняет последний успешно созданный бэкап всё то время, пока происходят неуспешные попытки. Этот бэкап будет храниться до тех пор, пока не будет успешно создан новый.
27.08.2019 01:00 am: Задание OneDrive стартует и успешно создает новую точку восстановления. Затем оно удаляет старую точку, созданную 24.08, поскольку она не подлежит хранению согласно политике, и при этом уже есть успешно созданная новая точка.
27.08.2019 02:00 am: Аналогично отрабатывает и задание Exchange.
Важно понимать, что эта логика применяется только в случае неуспешной отработки задания. Если задание просто деактивировано галочкой в UI, никаких ожиданий точек не будет, ретеншен отработает как обычно.
Что происходит на сторадже?
Если вы когда-нибудь заглядывали в локальный репозиторий Veeam, то вы, возможно, помните, что там нет резервных копий писем или документов как отдельных файлов. А имеется там структура наподобие вот такой:
В каждой папке лежит контейнер БД — это файл repository.adb, куда и складываются все бэкапы. Когда программа решает, куда положить конкретный файл, она смотрит на дату последнего изменения (то самое поле Date modified в Office 365).
Когда же согласно ретеншену приходит время удалить данные из репозитория, то чаще всего это не физическое удаление — а просто блок данных в repository.adb помечается как пустой. Сам контейнер repository.adb удаляется только после того, как все данные внутри него были удалены по ретеншену. Но мы позаботились об эффективности использования места: блоки, помеченные как пустые, будут переиспользованы для хранения новых бэкапов.
Важно! Все вышеописанное не относится к объектным хранилищам (object storage repositories), поскольку их архитектура кардинально отличается и заслуживает отдельного разговора.
В заключение
- Оба типа ретеншена эффективны, но каждый в своем роде — поэтому до того, как остановить свой выбор на одном из них, проанализируйте требования к резервному копированию и хранению данных в вашей организации.
- Если не выбрать опцию “Keep forever” (хранить вечно), то оба варианта ретеншена будут выполнять удаление данных. А ретеншен на уровне айтема будет сам определять, какие данные нужно бэкапить.
- Если вы используете локальный репозиторий, то физически место на диске может оставаться занятым, пока данные не будут удалены согласно ретеншену.
- Если у вас остались вопросы, пишите в комментариях, будем разбираться.