Home » Полезные советы » Как правильно делать бэкапы и следить за ними

Как правильно делать бэкапы и следить за ними

Написать данную заметку меня побудила ситуация вокруг хостера ihor.ru, с которым я сотрудничаю уже лет 5. Еще летом у них начались какие-то проблемы, а сейчас они вылились в открытое противостояние собственников. В чем там конкретно проблемы, я не знаю. Есть 2 противоборствующие стороны, у каждой из которых свой канал в телеграме — @ihor_hosting и @marosnet. Там есть подробности. Они делят между собой компанию. А на пользователях это сказывается тем, что постоянно что-то не работает. То связи нет, то сервера выключаются, тех. поддержка не работает вообще, платежи не принимают. В общем, жуть.

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «Администратор Linux» в OTUS. Курс не для новичков, для поступления нужно пройти .

Введение

За столько лет я оброс всевозможными сервисами и услугами этого провайдера. Многим его советовал. Я туда десятки (может сотни) клиентов привел, в том числе через этот сайт. Долгое время у меня висела его реклама, так как я сам пользовался его услугами.

Последние дни торопливо переносил оттуда все критично важное (в основном в selectel). Оставил только то, что было оплачено заранее сильно вперед (например, дедики с оплатой на год). В связи с этой ситуацией, хотел еще раз обратить внимание на важность бэкапов и мои подходы к их созданию и обслуживанию.

Бэкапы нужно обязательно разворачивать и проверять

Мало просто настраивать мониторинг бэкапов и оповещения. Я регулярно вручную проверяю все бэкапы. Да, это очень хлопотно, но другого выхода я не вижу. Если я этого не делаю, то перестаю спокойно спать.

Вот свежий пример, когда большая продуктовая база бэкапилась, но бэкап не проверялся. Автору повезло, что потерял только несколько записей. А мог и всю таблицу. Там, где можно, я автоматизирую разворачивание на запасном сервере с помощью простых bash скриптов. У меня бывали всякие ситуации, когда бэкапы по каким-то причинам переставали делаться. Если они физически отсутствуют, я получаю уведомление от zabbix. Но этого мало.

Особенно важно проверять дампы баз. Физическое наличие файла с дампом не означает, что вы без проблем его развернете. Надо проверять данные, заливая дамп в базу. Это единственный способ убедиться, что данные реально есть и они актуальны.

Backup должен быть в другом дата центре у другого юр. лица

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

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

Как правильно делать бэкап

С самого сервера с данными не должно быть доступа к бэкапам

Очень важное правило — бэкап сервер сам подключается к целевым машинам и забирает информацию. Это добавляет сложности к сервисам, с помощью которых вы будете делать бэкап. Не получится просто купить где-то место в s3, nfs, smb и класть туда бэкапы с серверов. Нужен активный агент, который будет ходить по целевым серверам и собирать данные сам. Зачем такие сложности?

Представьте ситуацию, что на целевой сервер попадает злоумышленник или вирус. Он шифрует не только ваши данные, но и бэкапы, к которым есть доступ с машины. Иногда я делаю 2 разных бэкапа — в первое хранилище целевой сервер кладет данные самостоятельно. А с этого хранилища второй бэкап-сервер сам забирает данные. К нему нет доступа ни у кого. Для большей безопасности можно затирать в логах следы подключения, чтобы нельзя было получить информацию не только о местоположении второго сервера, но и в целом информации о том, что он существует.

Для подобного рода бэкапов хорошо подходят бюджетные vps с большими дисками. Такая услуга, к примеру, есть у ruvds. В списке услуг выбирайте большой диск. Доступен не на всех тарифах и датацентрах.

Большой диск на vps для бэкапа

Бэкапы должны быть максимально полные и подробные

Что я имею ввиду? Зачастую бэкапы делаются с расчетом на то, что что-то изменится на проде и нам надо будет развернуть бэкап и посмотреть на него. Бэкапятся, к примеру, исходники сайта и база к нему. Когда все в порядке и ты просто проверяешь бэкап, сложностей не возникает, потому что если ты даже что-то забыл, то залез на prod и посмотрел.

Например, у сайта может быть сложный и насыщенный конфиг nginx с кучей location и редиректов. В процессе эксплуатации вы могли тюнить и вносить много изменений в настройки mysql сервера. Если конфиги не забэкапить вместе с сайтом, то разворачивать и запускать его в работу может быть очень трудозатратно и хлопотно, особенно если оптимизация и настройки выполнялись давно и все уже забыто.

Отсюда правило — бэкапьте не только данные, но и все окружение из расчета на то, что вы разом можете потерять prod навсегда. Я много раз об это спотыкался и по второму разу настраивал все то, что у же было настроено ранее. Сейчас все конфиги проектов храню в своем gitlab. Из того, что часто забывают — ssl/tls сертификаты. А потом их приходится торопливо искать.

Backup виртуальных машин

Я знаю, что многие бэкапят целиком виртуалки. Я редко делаю такие бэкапы, так как с ними трудно работать. Получаются файлы огромных размеров. Если гоняете их через интернет, то они могут биться по дороге, либо в момент создания. У меня были ситуации, когда нужно было развернуть бэкап виртуальной машины на 200 Гб. Я несколько часов его заливал через интернет, а потом он не разворачивался из-за ошибки чтения. Пробовал несколько раз и каждый раз неудачно. Очень повезло, что заметил это в момент тестового разворачивания, а не тогда, когда была бы реальная авария. Это был бы полный провал, так как это был единственный экземпляр архивной копии.

Если нужно делать бэкап виртуальной машины, то я делаю небольшой системный диск (30-50 Гб) и бэкаплю только его. Данные кладу на отдельный виртуальный диск и забираю их в сыром в виде с помощью rsync или аналогов. С его помощью легко и быстро делать инкрементные бэкапы, а потом их разворачивать. Нет проблем с докачкой и битыми файлами. Даже если что-то и повреждено, то 1 файл из десятков тысяч погоды не сделает. Можно пережить.

Проверяйте скорость восстановления данных

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

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

Есть дешевые хранилища, где явно не указано, что скорость доступа будет низкой. Но нужно это понимать, если цена за хранение действительно ниже, чем в среднем по рынку. Многие хостеры на хранилищах с безлимитным трафиком на самом деле этот лимит имеют и включат вам его после того, как вы превысите определенный порог в скачанных данных. Вам просто сделают не 100 мегабит полосу, а 5-10.

У меня были ситуации, когда сервер с бэкапами живет на гигабитном порту с «безлимитным трафиком». А когда ты скачаешь 10-15 гигабайт, включается ограничение полосы до 100 мегабит. Возможно будет и дальнейшее урезание. С такими лимитами нет смысла платить за гигабит. Это просто маркетинговая уловка.

В общем, не доверяйте данным из описания тарифа, проверяйте их сами, чтобы потом не было сюрприза.

Заключение

Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!

Это мои основные правила создания бэкапов. А как вы делаете бэкапы? Поделитесь своим опытом. Возможно, я что-то забываю или упускаю.

Онлайн курс Основы сетевых технологий

Теоретический курс с самыми базовыми знаниями по сетям. Курс подходит и начинающим, и людям с опытом. Практикующим системным администраторам курс поможет упорядочить знания и восполнить пробелы. А те, кто только входит в профессию, получат на курсе базовые знания и навыки, без воды и избыточной теории. После обучения вы сможете ответить на вопросы:
  • На каком уровне модели OSI могут работать коммутаторы;
  • Как лучше организовать работу сети организации с множеством отделов;
  • Для чего и как использовать технологию VLAN;
  • Для чего сервера стоит выносить в DMZ;
  • Как организовать объединение филиалов и удаленный доступ сотрудников по vpn;
  • и многое другое.
Уже знаете ответы на вопросы выше? Или сомневаетесь? Попробуйте пройти тест по основам сетевых технологий. Всего 53 вопроса, в один цикл теста входит 10 вопросов в случайном порядке. Поэтому тест можно проходить несколько раз без потери интереса. Бесплатно и без регистрации. Все подробности на странице .

Помогла статья? Есть возможность отблагодарить автора

Автор Zerox

Zerox
Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству.

29 комментариев

  1. Аватар

    Всё правильно и познавательно написано. Для себя придумал следующее — с сервера резервного копирования второй сервер на Linux по cron-у забирает резервные копии и отключается — дополнительная защита от шифровальщиков и прочей нечисти.

    • Zerox

      А включается потом как? Как это реализовано полностью?

      • Аватар

        Сначала делаются резервные копии на Windows-сервер, потом Linux-сервер по cron монтирует нужные папки, копирует к себе резервные копии и отключается, кроме того — по cron удаляются старые резервные копии, фактически организовано дополнительное хранение резервных копий, про которое основная Windows-система не знает. Реализовано всё после атаки шифровальщика, которая особого вреда не нанесла, но подумать заставила.

        • Zerox

          А включается бэкап сервер потом как? Я точно так же забираю бэкапы с windows серверов.

          • Аватар

            Оба бэкап-сервера постоянно включены, если надо что-то забрать — можно монтировать папку или копировать через WinSCP.

            • Zerox

              Я что-то затупил. Думал серваки с бэкапами физически выключаются. У меня были идеи так сделать, но посчитал, что это уже слишком :)

              • Аватар

                Linux-сервер как раз и нужен как невидимое из Windows хранилище, подключаемое только на время копирования данных.
                Кто-то писал, что на сервере был внешний USB-диск, который скриптом подключался-отключался, но мне такой вариант не понравился.

  2. Аватар

    Автор, как вы относитесь к Veeam Backup? По моему ничего лучшего еще не придумали.
    Он не только безопасно бекапит по сети, проверяя целостность, но еще и может проводить дедупликацию данных.

    Работает с агентами, которые ставятся на машины, может бекапить всю систему, даже во время работы активной работы.

    Был ли у вас опыт работы с этим продуктом?

    • Zerox

      Постоянно пользуюсь там, где это уместно. Продукт хороший. У бесплатных версий большой функционал, которого часто хватает для небольших проектов. У меня статья есть про бэкап linux серверов с его помощью. Через поиск сразу находится.

  3. Аватар

    У меня бэкапы льются непосредственно с самих тачек (подавляющее большинство Linux) на целевой сервер (smb), но учетка под которой монтируется шара имеет доступ только к определенной папке. После завершения копирования всех бэкапов, на стороне сервера скрипт их перемещает в другое расположение, куда упомянутая выше учетная запись доступа не имеет. Копирование происходит утилитой rsync, что гарантирует целостность файлов.
    Две архива БД разворачиваются и проверяются автоматом каждый день. Остальные периодически вручную.
    Для zabbix настроено низкоуровневое обнаружение новых бэкапов, проверка их актуальности, плюс созданы триггеры оповещающие об отсутствии данных в течение определенное промежутка времени (что я считаю нужно делать на всех критически важных данных).

    • Zerox

      Спасибо, любопытное дополнение. Я как-то не догадался перемещать архивы в другое место в рамках одного сервера. Это где-то может быть неплохим решением.

      Как реализовано обнаружение бэкапов? Интересует просто принцип, без подробностей. Какой-то скрипт, который список директорий делает, а потом передает в zabbix для последующей работы или что-то еще? У меня есть наработки в этой области, но они не универсальные и не гибкие. Каждый раз приходится вручную редактировать под конкретную ситуацию. Что-то универсальное не получается придумать.

      • Аватар

        Принцип простой, получение списка папок через Powershell методом Get-ChildItem. Конечно, ни о какой универсальности речи не идет, у меня пара тройка серверов с бэкапами, все они прописаны в одном скрипте, который дергает Zabbix периодически и добавляет новые в мониторинг, если таковые появились, плюс почти у всех бэкапов стандартная схема ротации: неделя — месяц — квартал — год.
        Актуальность проверяется по свойству lastwritetime

  4. Аватар
    Владислав

    Использую Handy Backup (https://www.handybackup.ru/hyper-v-backup.shtml) для всех машин в институте, и не парюсь. Изнутри машины не делаю бэкап в принципе, и другим не рекомендую: первый сбой, вирус или рэнсомвэр в какой-нибудь тестовой конфигурации — и до свидания, данные! (Мы так один рад потеряли машину, на которой было развёрнуто целое виртуальное издательство, визгу от научных сотрудников было до небес!)

    • Zerox

      Бэкапы изнутри настоятельно рекомендую делать. Причем они должны быть с версионированием, чтобы была возможность откатиться на прошлую версию файла, тогда никакие шифровальщики не страшны. Бэкап виртуалки это один большой файл. С ним могут возникнуть проблемы. Он тупо может не прочитаться или не развернуться. Я с этим сталкивался лично, так что рекомендую не надеяться всецело на него.

  5. Аватар

    В догонку тем кто пользует Vmware ESXi Free.
    В последнем релизе отключена возможность использования стронних продуктов для бэкапа ВМ (
    Не верите? Читаем http://www.virtualizationhowto.com/2019/11/esxi-6-7-free-limitations-and-features/

    >>No backups from third-party backup solutions<>Maximum of 8 vCPUs for VMs running on ESXi 6.7 free<<

    Всем пользователям Veeam, Vembu etc — большой "привет". И еще один повод перейти на Open source.
    Proxmox, Opennebula etc в помощь.

    • Zerox

      Так в proxmox того же veeam вообще нет и никогда не было. Нет вообще ничего сопоставимого по функционалу. Да бог с ним, с veeam, там вообще нет ничего для инкрементного бэкапа на уровне гипервизора. Только на уровне хранилища, но для малого и среднего бизнеса это не вариант. У них нет промышленных хранилок.

      • Аватар

        Да, с инкрементными бэкапами из коробки пока не очень. Есть костыль в виде отдельного проекта для этого дела. Насчет «функционала» Вима. Вим — это отдельный проект, для к-го нужна отдельная машина. Ни у Гипер-В, ни у Вмваре Фри нет и никогда не будет готовой системы бэкапов с ротацией. У PVE она есть. Даром. Плюс скоро ZSTD-сжатие завезут.

        >>Только на уровне хранилища, но для малого и среднего бизнеса это не вариант. У них нет промышленных хранилок.
        Для малого и среднего бизнеса хватит отдельного PC (или неск-ко) + xigmanas на флешке + zfs raidZ2\3
        С головой хватит.

  6. Аватар

    Добрый.

    Для ZFS есть:
    http://www.znapzend.org
    или руками gist.github.com/sammy8806/b87021bbca83c9aff56c1c22941dcbc0

  7. Аватар
    Алексей

    У нас бэкапы разворачиваются каждые сутки на демо-стенды и мониторятся и там. Единственное — на момент разворота отключается проверка мониторингом, а то вздрагивай каждую ночь. :)

    • Zerox

      Это хороший вариант, если есть возможность автоматизировать. Какие средства для этого используете?

      Если есть veeam, то вопросов нет. Сам там настраиваю регулярную репликацию с проверками. А вот если вима нет, то все усложняется. Чаще всего восстанавливаю скриптами в полуавтоматическом режиме.

      • Аватар
        Алексей

        Стандартные линукс-утилиты, типа того же rsynс. Плюс некоторые вещи реализованы плейбуками для Ансибл (удобно что и порт проверит и так далее. Что не так — откат и матюги). Главное — не усложнять. :)

  8. Аватар

    Спасибо. Было позновательно.

  9. Аватар

    «А с этого хранилища второй бэкап-сервер сам забирает данные.»
    Если не секрет, то какие есть инструменты, чтобы так делали?

    • Zerox

      Способов может быть очень много. Все зависит от используемых средств и систем. Если оба сервера с бэкапами полноценные серверы с ssh, то один сервер с другого может забирать данные по scp, rsync, используя ssh авторизацию. Можно расшарить данные бэкапов по nfs или smb и настроить ограничения по ip, разрешая подключаться только со второго сервера. В общем, зависит от возможностей. Так или иначе это везде реализуется, только по разному.

  10. Аватар

    Больная тема вообще) сколько раз у меня ломали сайты, сколько раз хостеры с ума сходили… без Backup вообще никуда и никогда, делается на внешки раз в 24 часа. И проверять как минимум раз в неделю, чтобы не криво и четко по времени

  11. Аватар

    По поводу того, что бэкапы нужно обязательно проверять, подтверждаю на 100%. Был опыт.

  12. Zerox

    Кстати, статью я опубликовал и через некоторое время ihor умер окончательно. Я весь день все переносил и восстанавливал из бэкапов. Удалось восстановить все, не потерял ничего. Чего не скажешь о многих других людях.
    —————————————————-
    1
    —————————

    2
    ——————————————————

    3
    ——————————————————

  13. Аватар
    Алексей

    Согласен почти со всеми пунктами, только одно попало под сомнение.

    Вначале вы пишите:
    «Представьте ситуацию, что на целевой сервер попадает злоумышленник или вирус. Он шифрует не только ваши данные, но и бэкапы, к которым есть доступ с машины.»

    И тут же добавляете:
    » Иногда я делаю 2 разных бэкапа — в первое хранилище целевой сервер кладет данные самостоятельно. А с этого хранилища второй бэкап-сервер сам забирает данные.»

    Зачем настраивать backup-конфиги на самом целевом сервере, т. е. на том сервере, с которого backup-ться эти самые данные? Если на целевой сервер попадет вирус или хакер, то он почистит или зашифрует везде данные, включая данные на backup-сервере путем просмотра этих backup-конфигов. И тогда «А с этого хранилища второй бэкап-сервер сам забирает данные.» будет бессмысленным действием уже, т.к. данные уже будут зашифрованными на первом backup-сервере.

    Или я что-то понял неправильно здесь?

    • Zerox

      Иногда удобнее сделать так, чтобы целевой сервер сам бэкапил свои данные. Это бывает в силу каких-то технических особенностей или ограничений. Но чтобы не рисковать, мы эти данные еще раз забираем уже самостоятельно. Если первый бэкап будет зашифрован, что на втором как минимум останется предыдущая версия файлов, не зашифрованная.

      Бэкап же делается не в лоб, простым сравнением и перезаписью файлов. Хранится история изменений, чтобы можно было откатиться на какой-то предыдущий день. Это уже вопрос конкретной реализации.

Добавить комментарий

Ваш адрес email не будет опубликован.

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.