«Худшие практики» работы с продуктами резервного копирования на примере Veeam Backup & Replication

Автор оригинала: Cristian-Antonio Puricica
  • Перевод
Про “лучшие практики” слышали многие – это рекомендации, которым стоит следовать при развертывании системы для ее оптимальной работы. Однако сегодня я хочу рассказать о “худших практиках” или о распространенных ошибках администраторов в области задач резервного копирования. Поскольку пользователям продуктов не всегда хватает времени, чтобы прочитать множество статей с “лучшими практиками”, а также ресурсов, чтобы внедрить их все, я решил обобщить информацию о том, чего точно следует избегать при работе с продуктами резервного копирования. За “вредными советами” добро пожаловать под кат.

image

Запуск заданий бэкапа с настройками, не учитывающими конкретную конфигурацию


Отсутствие планирования резервного копирования и оценки характеристик хранилища резервных копий – самая распространенная “худшая практика”. Многие пользователи устанавливают продукт резервного копирования со стандартными настройками, просто последовательно нажимая кнопку «Далее» в мастерах продукта. Более того, многие оставляют стандартные настройки и для заданий резервного копирования, не учитывая особенностей инфраструктуры, политик удаления старых копий и других важных аспектов. В результате возникают ошибки при запуске и выполнении заданий, преждевременное заполнение репозитория и, как следствие, приятное, но времязатратное общение со службой техподдержки.

А как правильно? На примере продуктов Veeam: во избежание подобных сценариев перед установкой Veeam Backup & Replication рекомендуется использовать, например, Veeam ONE – инструмент для мониторинга и создания отчетов о работе инфраструктуры. Так, открыв отчет VM Configuration Assessment (проверка конфигурации виртуальных машин), вы поймете, готовы ли ваши виртуальные машины к резервному копированию, и, если нет, – то по какой причине. Отчет VM Change Rate Estimation (оценка частоты изменения ВМ) строится на основе статистики по изменению блоков виртуальных машин и позволяет правильно рассчитать необходимый размер репозитория.

image

Подробнее о полезных для планирования отчетах можно почитать, например, здесь.

Еще один инструмент от Veeam – онлайн-калькулятор размера точек восстановления – также поможет при планировании среды резервного копирования.

Объедините все задания в цепочки


Хотите завалить все задания резервного копирования из-за ошибки в одном из них? Тогда скорее объединяйте их в цепочки зависимых заданий, чтобы при завершении одного задания сразу начиналось другое. В этом случае вы гарантированно получите увеличение окон резервного копирования, задержку старта заданий и прочие неприятные последствия.

А как правильно? На самом деле, объединять задачи следует только в определенных случаях. Например, если вы не хотите бэкапить два приложения одновременно, то вы можете настроить старт бэкапа одного из них только после завершения бэкапа другого приложения. В случае Veeam вам лучше доверить продукту спланировать ресурсы за вас. Планировщик Veeam Backup & Replication умеет запускать несколько заданий одновременно для оптимизации окон резервного копирования, применяя “умные алгоритмы” для распределения нагрузки на компоненты инфраструктуры, выбирая оптимальный режим передачи данных и работая в установленных пределах пропускной способности канала до репозитория.

Никогда не верифицируйте бэкапы


Жизненный опыт показывает, что часто компании “экономят” на тестировании резервных копий. Это может быть связано как с недостаточной осведомленностью в отношении возможных проблем на фазе восстановления, так и с экономическими факторами, так как полноценный процесс тестирования восстановления системы из резервной копии, если проводить его вручную, — очень трудоемкая операция. Такая ситуация чревата негативными последствиями, ведь в случае сбоя критические данные могут быть не восстановлены в заданное время или, что еще хуже, могут быть частично или полностью потеряны.

Что случилось в 1998 году в реальном случае студии Pixar, когда едва не были потеряны все рабочие материалы мультфильма “История Игрушек 2”, можете прочитать в нашем посте “Случай в Pixar или еще раз о важности тестирования резервных копий”.

А как правильно? Тестирование восстановления из резервных копий необходимо производить регулярно. Следует различать тестирование целостности самой резервной копии и тестирование восстановления из резервной копии. В первом случае вы проверяете только целостность копии по контрольным суммам блоков данных. Во втором вы проводите тестирование, отражающее тот или иной моделируемый сценарий отдельного сбоя или полномасштабной “катастрофы” продуктивной сети. Крайне важно делать не только первое, но и второе, потому что в конечном счете вас интересует именно реальное восстановление данных в случае сбоя, и даже если целостность самой резервной копии не нарушена, восстановление может пройти неудачно.

Вероятных причин неудачного восстановления может быть много, приведу только некоторые из них:

  • при восстановлении системы могут требоваться дополнительные шаги, которые автоматически не выполняет продукт резервного копирования (скажем, перенастройка удаленных сервисов, взаимодействующих с восстанавливаемой системой),
  • может произойти отказ в доступе к репозиторию резервных копий с нового ноутбука админа (просто потому что это будет первая попытка такого доступа – и на это уйдет лишнее драгоценное время),
  • низкая пропускная способность канала “подвесит” процесс off-site восстановления (когда резервную копию нужно подтянуть из другого офиса),
  • вдруг выяснится, что ежедневный бэкап последние полгода постоянно увеличивался в размере (практически все исходные системы постоянно растут в размере) – и в какой-то момент не поместился на ленту, а ошибка осталась незамеченной (вышеупомянутый пример с Pixar),
  • старая резервная копия может не восстановиться на новом железе,
  • при восстановлении может выясниться, что не все файлы или машины попали в область задания резервного копирования.

Как эти проблемы можно решить? Например, технология Veeam SureBackup позволяет автоматически протестировать виртуальные машины из резервных копий и удостовериться в возможности их восстановления. Задание SureBackup (см. пост “SureBackup – автоматическая проверка возможности восстановления данных из резервной копии”) автоматически запускает все машины, с учетом их зависимостей (например, сначала контроллер домена и только потом Exchange сервер), в изолированной виртуальной лаборатории, проверяет их работоспособность (в том числе с помощью скриптов, написанных пользователем) и отправляет соответствующие отчеты по электронной почте.

Не завершайте процесс моментального восстановления машины (Instant VM recovery)


И, наконец, худший совет по сегодняшней теме конкретно по Veeam: запустите виртуальную машину с помощью Instant VM recovery и забудьте про нее. Совсем забудьте. В этом случае вам гарантирована целая тонна проблем. Работа машины прямо из репозитория приведет к блокировке точки восстановления, поэтому другие задания (например, SureBackup или BackupCopy) просто не запустятся. Происходит это из-за того, что машина запускается прямо из файла резервной копии в режиме чтения, то есть без записи каких-либо изменений в сам файл. При этом создается отдельный файл на диске C: сервера резервного копирования Veeam, который разрастется до невероятных размеров, если оставить машину работающей хотя бы на несколько дней.

image

А как правильно? Чтобы избежать этого, сразу после завершения Instant VM recovery обязательно переносите машину в продакшен-среду. Подробнее об этом процессе можно узнать в руководстве пользователя Veeam.

Заключение


Надеюсь, эта статья поможет сэкономить время, деньги и избавит от головной боли от описанных проблем. Есть что добавить к списку «худших практик»? Тогда поделитесь этим в комментариях!

А в заключение привожу ссылки на наши лучшие посты про лучшие практики резервного копирования, какой бы продукт вы не использовали:

Veeam Software
Продукты для резервного копирования информации

Комментарии 19

    0
    Объедините все задания в цепочки

    а можно ссылочку на kb или ман?
      0
      Подробнее можно почитать здесь и здесь
        0
        Спасибо, что то никогда не обращал внимание на After this job. Прям сегодня и попробую — сколько времени удастся отыграть.
          0
          Объединением в цепочки «отыграть» времени не получится, только проиграть.
            0
            Тут можно долго спорить, но иногда этим методом можно реально сократить общее время бэкапов (не их скорость).При бэкапе машин из vcloud может вполне пригодиться.
              0
              Ну почему же? У меня есть несколько задач. Они выполняются от 5 до 40 минут в зависимости от прироста данных. Допустим я запускаю задачи раз в час и теряю от 20 до 55 минут (ну образно), если они будут запускаться сами друг за другом — сэкономлю и ни мало
                0
                А вот здесь как раз обратная сторона. Новая задача у вас начнется, конечно, раньше запланированного срока, только вот представьте ситуацию, когда в вашей цепочке задач есть одна машина с очень большим диском и следующая задача ждет только эту машину, при этом 90% ресурсов прокси простаивает, хотя, запустись она параллельно, уже бы обрабатывала другие виртуалки.

                На самом деле тут все очень индивидуально и каждый использует то, что ему удобней. В 8 версии я перестал использовать цепочки задач, потому что, если мне нужно было запустить только одну задачу из цепочки, после ее выполнения запускались следующие. В 9 версии, к счастью, теперь можно запустить только одну задачу и не запускать всю последующую цепь.
                  0
                  На самом деле тут все очень индивидуально и каждый использует то, что ему удобней.

                  Полностью согласен. Вот как раз в ситуации, о которой я говорил — это хорошее решение, т.к. из-за невысокой общей производительности инфраструктуры, бекапы делаются в очень малое кол-во потоков и с контролем iops на продуктивной схд, так что прокси у нас и так простаивает, пока изменений в архитектуре не будет — это отличный вариант заканчивать РК раньше.
                  0
                  Там есть подвох — следующая задача запустится только в том случае, если предыдущая закончилась со статусом Success или Warning. Так что если она Fail, то и остальные тоже будут Fail. По крайней мере в Veeam B&R 8 было так.
                    0
                    Вот это конечно недостаток, да.
                      0
                      Если Fail, то (по умолчанию) будет еще 3 попытки с интервалом 10 минут повторить задачу и только после этого таки запустится следующая задача. Только что простой 30 минут.
                        0
                        Ну кол-во попыток и интервал же настраиваются. Можно и уменьшить
            +1
            Еще хорошо, когда не читаешь, что пишет менеджер восстановления, и восстанавливаешь машину поверх оригинальной, работающей, хотя хотел просто копию.
            Ну и разносить виртуальные машины из одного VAPP в разные задачи резервного копирования, которые запускаются в одно время. В таком случае, кому не повезло — будет ждать, пока VAPP, занятый другой задачей не освободится.
              +1
              Если в целом, то вся статья сводится к:

              Неправильное бэкапирование — вы не используете продукты Veeam.
              Правильное бэкапирование — вы используете продукты Veeam.
                0
                ИМХО шедулер не достаточно гибкий, и даже PS-скриптами не всё можно обыграть.
                Хотелки:
                1.Периодичность Active full и Syntetic full бэкапов вынести из «Advanced» закладки Storage, например, в закладку Virtual mashines задачи бэкапа.
                2.На закладке задачи Virtual mashines возможность настройки последовательности с условием а) пока не закончилась текущая очередь — следующую не начинать б) следующую очередь начинать только когда освободятся ресурсы от выполнения текущей очереди. Например (а): очередь формируется из ВМ размещенных на ЛУНе (функция storage snaphots используется), ЛУНов в задании несколько, сценарий — бэкапятся ВМ с ЛУНа 1 (снапшеты ВМ, снапшет ЛУНа, удаление снапшетов ВМ, бэкап, удаление снапшета ЛУНа) и только после окончания бэкапа ВМ с ЛУНа 1 начинается очередь ВМ с ЛУНа 2,…
                3.Имея много задач по бэкапу с разными настройками хотелось бы видеть эти «настройки» в табличном виде на заглавной странице Jobs или с помощью PS-скрипта
                  0
                  Тут бы хоть расписание произвольного списка ВМ выудить в приемлемом виде.
                  А то даже скриптом устанешь парсить, я всё себя заставить не могу начать такой писать.
                  Вроде надо, но как увидишь вывод — всякое желание пропадает ))

                  Start time: [20161123 1:00:00], Latest run time: [20170201 1:00:02], Next run time: [02/02/2017 01:00:00], Retry times on failure: [3], Retry timeout:
                  [10 min], Daily options: [Enabled: True, DayNumberInMonth: Everyday, Days: Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday]Monthly optio
                  ns: [Enabled: False, Time: 20160419 22:00:00, Day Number In Month: Fourth, Day Of Week: Saturday, Months: January, February, March, April, May, June, J
                  uly, August, September, October, November, December]Periodically options: [Enabled: False, Period: 1 hour(s), ScheduleString: 0,0,0,
                  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,00,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,00,0,0,0,0,0,0,0,0,0,0,0,0,0,
                  0,0,0,0,0,0,0,0,0,00,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,00,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
                  0,0,00,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,00,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</s
                  cheduler>, HourlyOffset: 0]Continuous options: [Enabled: False, ScheduleString: 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Sun
                  day>0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,00,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,00,0,0,
                  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,00,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,00,0,0,0,0,0,0,0,0,0,0,
                  0,0,0,0,0,0,0,0,0,0,0,0,00,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]


                    0
                    Зачем там столько нулей? :)
                      0
                      Предполагаю, что это опции задания.
                      0 — выкл
                      00 — вкл.
                      Но уверенности нет)
                    0
                    Мне вот столбца с размером ВМок внутри задания не хватает

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое