Три вопроса, которые стоит задать при выборе способа резервного копирования
На рынке существуют десятки инструментов резервного копирования — как open source, так и коммерческих решений. Выбор подходящего можно считать стратегическим для компании. Нужно учитывать целый ряд факторов и не забывать о финансовой составляющей. Чтобы избежать «мискастинга», бизнесу стоит задать себе несколько вопросов. Об этом рассказал Иван Романько, директор по развитию ядра облачной платформы компании Selectel.
Вопрос №1. Сколько времени вы готовы уделять резервному копированию
Ходят легенды, что есть системы бэкапов, которые можно настроить единожды и больше не трогать. Но сделать раз и навсегда не получится. Хороший системный администратор знает: бэкапы нужно не только настраивать, но и периодически восстанавливать, проверяя их консистентность и работоспособность.
Совсем не уделять время бэкапам, даже если это решение из «коробки», не получится. Но можно выбрать частоту и длительность работ с резервными копиями.
Ручное резервирование
Более интенсивно приходится работать с бэкапами, если компания выбирает ручное снятие резервных копий. При таком сценарии сисадмин делает копии важных данных, отправляет их в объектное или файловое хранилище, загружает на отдельный сервер или любую внешнюю инфраструктуру.
Допустим, бэкапы делаются хотя бы раз в неделю. Сисадмину нужно будет совершать один и тот же алгоритм действий каждый раз. При этом не перепутать окно снятия бэкапов и следить за количеством хранимых версий — хранилище нужно периодически подчищать, чтобы не переплачивать за ресурсы.
Кому подойдет. Обычно ручное резервное копирование — практика небольших компаний, где систему администрирует один человек и работы немного (нужно резервировать несколько наборов данных). Часто выбор продиктован дешевизной: хранить копии некритичных систем можно хоть на Google Диске. Еще одной причиной может быть отсутствие профильного специалиста, который настроит автоматическое снятие бэкапов.
Кому не подойдет. Компаниям с более сложной инфраструктурой. Если резервировать нужно несколько систем — базы данных, сетевые и локальные диски серверов и др., ручное резервирование слишком рискованно. Поскольку оно сильно завязано на человеке, который не застрахован от ошибок. Специалист может забыть сделать бэкап, удалить не ту копию, не проверить скачанные данные на консистентность.
Резервное копирование с кастомной автоматизацией
Снятие бэкапов можно автоматизировать с помощью скриптов и утилит. В таком случае специалист компании тратит время на старте, чтобы организовать необходимую логику автоматизации. Зато потом это позволит ему реже заботиться о бэкапах. Например, клиенты Selectel могут самостоятельно настроить создание резервных копий с облачных серверов (организовать автоматический перенос копий данных в хранилища Selectel) или хранение бэкапов своих внешних систем на инфраструктуре компании.
Возможности автоматизации ограничиваются фантазией и навыками специалиста, а также гибкостью выбранного места размещения инфраструктуры (например, провайдер должен предоставлять доступ к API).
Настройка может занять рабочий день или неделю — в зависимости от объема работ. Зато после бэкапы будут сниматься и отправляться на хранение без участия специалиста. Автоматизировать можно и проверку консистентности, например, настроив мониторинг и алерты на несоответствие объема копий, и обновление копий. Администратору остается лишь время от времени восстанавливаться из бэкапа, чтобы повысить безопасность.
Кому подойдет. Любой компании, где навыки специалистов позволяют организовать и поддерживать необходимую автоматизацию. Поддерживать — ключевое слово, поскольку скрипт может «отвалиться» или начать работать некорректно. Это нужно вовремя заметить и исправить.
Также автоматизация — прерогатива компаний, которые хотят получить более кастомизированное решение и не зависеть от вендора. Нередко в больших компаниях автоматизацию добавляют в дополнение к «коробочному» решению, чтобы повысить безопасность или закрыть индивидуальные потребности.
Кому не подойдет. Компаниям, где нет сотрудников с необходимыми компетенциями. Кроме того, некоторым организациям, чаще всего большим, необходимы определенные гарантии сохранения данных, которую чаще всего могут предложить лишь разработчики готовых решений. Так, услуга автоматических бэкапов по расписанию от Selectel работает по SLA — соглашению об уровне предоставляемых услуг, которое описывает создание бэкапов и последующее восстановление данных с использованием сервиса.
Резервное копирование с помощью готового решения
Это самый простой способ настройки бэкапов. Можно выбрать подходящее стороннее решение для корпоративного и enterprise-сектора. Бэкапы «из коробки» устанавливаются как обычное программное обеспечение, каждый шаг по внедрению подробно описан в документации.
Еще больше упростит работу с резервным копированием решение провайдера ИТ-инфраструктуры, у которого размещается компания (спросите у партнера про доступные опции). Основное преимущество в том, что не нужно заниматься синхронизацией стороннего ПО с инфраструктурой: система для бэкапов и объекты резервирования уже находятся в одном окружении.
Здесь показателен пример автоматических бэкапов сетевых дисков от Selectel. Настройка занимает несколько минут: для старта нужно выбрать диск, с которого будут сниматься бэкапы, и установить необходимое расписание резервного копирования. Нужный диск можно просто выбрать из списка используемых. Подключить бэкапы по расписанию можно по ссылке.
Помимо собственных решений, крупные облачные провайдеры также предлагают ПО популярных вендоров-партнеров. Здесь профит, помимо скорости настройки, в удобстве оплаты «в едином окне».
Кому подойдет. Такое решение часто выбирают компании, чьи задачи администрирования инфраструктуры сложнее рядовых, поэтому они хотят делегировать резервное копирование другим специалистам. Это повышает безопасность хранения данных и позволяет не думать об инфраструктуре для хранения копий.
Кому не подойдет. Компаниям, у которых ограничен бюджет на приобретение ПО. Готовое решение стоит денег, иногда значительных сумм.
В качестве консенсуса можно подумать об open source-решениях, которые предлагают бесплатные тарифы. Но они сильно ограничены в функциональности и спорны с точки зрения информационной безопасности.
Вопрос №2. С какой периодичностью планируется делать бэкапы
Ответ на этот вопрос поможет определить, какой тип резервного копирования подойдет компании. Обычно выделяют три: полный, инкрементальный и дифференцированный.
Полный бэкап, то есть полная копия системы, подойдет для редких бэкапов — раз в 1-2 недели — или для частого копирования данных небольшого объема. Редкие бэкапы оптимальны, если компания резервирует данные, которые так же редко обновляются.
Инкрементальный бэкап подразумевает копирование файлов, которые были изменены со времени предыдущего бэкапа. Причем каждый последующий бэкап добавляет лишь файлы, которые были изменены с момента предыдущего.
Изменившиеся или новые файлы не замещают старые, а независимо добавляются на носитель. Такой бэкап хорошо подходит для нагруженных и часто изменяемых систем, потому что производится быстрее, чем полный. Но инкрементальные бэкапы не отменяют необходимость делать полный бэкап раз в неделю.
И полные, и инкрементальные бэкапы можно настроить через утилиты или найти релевантное готовое решение.
Дифференцированное резервное копирование — пока редкий тип, но он набирает все большую популярность. При таком резервном копировании файл, который был изменен с момента последнего полного бэкапа, копируется всякий раз заново, а не по обновленным «кусочкам». Этот вариант также подходит для большого объема данных и ежедневно изменяющихся систем.
Вопрос №3. За какое время нужно восстановиться из бэкапа
От ответа на этот вопрос также зависит выбор способа и типа резервного копирования. Обычно ответ — «как только, так сразу». Если «упавшая» система критически важна, счет может идти на минуты — простой сервиса принесет убытки компании.
Восстановление полного бэкапа может занять много времени. Есть вы организовали бэкапы самостоятельно, подумайте о резервной площадке, куда вы будете восстанавливать систему. В готовом решении обычно это продумано за вас. Так, в бэкапах по расписанию Selectel из копии создается новый диск, который можно подключить к существующему или новому серверу.
Будет правильным реализовать возможность восстанавливать отдельные файлы вместо всей системы. Так, если повреждены лишь несколько последних файлов, будет грустно тратить время на восстановление системы полностью и подвергать риску весь сервис.
Если сравнивать инкрементальный и дифференцированный бэкапы, восстановление из первого занимает больше времени. Сначала восстанавливаются данные последнего полного резервного копирования, затем — данные всех последующих инкрементальных РК. В случае дифференцированного типа процесс происходит быстрее. Для восстановления нужна последняя полная и последняя дифференцированная копия, которая уже содержит в себе свежие изменения.
Важно: Какой бы способ и тип вы ни выбрали, важно периодически — раз в 2-3 месяца — восстанавливаться из бэкапа в тестовом режиме. Так вы точно поймете, сколько времени займет восстановление, и предупредите возможные «сюрпризы» при его реализации.
Заключение
Нужна ли реализация бэкапов — это не вопрос. Резервировать не только данные, но и инфраструктуру очень важно.
Стратегия бэкапов — гибкая: в ходе развития компании можно реализовывать несколько типов бэкапов, переходить от самописных автоматизаций на «коробочные» решения и наоборот. Важно, что здесь вы не одиноки — надежный провайдер ИТ-инфраструктуры всегда проконсультирует по возможным опциям резервного копирования и посоветует подходящие именно вашей компании способы.
Чтобы карета не превратилась в тыкву, или зачем нужны тестовые восстановления из резервных копий
Рассказываем, как грамотно проводить тестовые восстановления из бэкапа.
19 мая 2017 • Александр Васильев
В этом посте обещал подробнее остановиться на истории с тестированием резервных копий. Сегодня как раз об этом. Чтобы обойтись без неприятных сюрпризов и в без того волнительные моменты потери данных, резервные копии нужно тестировать. Далее речь пойдет не про проверку целостности файлов резервных копий (проверка контрольной суммы блоков данных в файле бэкапа), а о полноценном тестовом восстановлении, когда проверяем работоспособность того, что у нас восстановилось.
Что может быть не так с файлом бэкапа
Помимо случаев, когда поврежден сам файл бэкапа, существует много причин, технических и организационных, почему восстановление из резервной копии может закончиться ошибкой. Остановлюсь на тех, с которыми столкнулся я.
В резервную копию ушли уже поврежденные данные/файлы. На сервере начал сыпаться диск. Мониторинг не отработал. Часть файлов испортилась, но они благополучно забэкапились. Такая проблема неделями может оставаться незамеченной, пока не понадобится открыть нужный файл. В процессе восстановления окажется, что файлы в бэкапе тоже нерабочие.
Неконсистентный бэкап. Такое может случится, когда выбрали неподходящее средство резервного копирования. Например, на виртуальной машине работает база данных, для бэкапа которой администратор решил использовать резервное копирование ВМ без поддержки целостности приложения (application aware backup).
Дело в том, что при своей работе БД активно использует кэш в оперативной памяти, и часть данных находится там. СУБД записывает данные на диск так, чтобы они в любой момент были согласованы между собой, и при внезапном выключении сервера база не превратилась в бесполезный набор байтов. Система резервного копирования записывает данные не мгновенно, и ничего не знает про синхронизацию кэша с файловой системой, поэтому при резервном копировании часть данных может быть записана в неправильном порядке. Тогда после восстановления ВМ мы получим поврежденную базу, части которой не соответствуют друг другу.
При использовании специальных агентов резервного копирования такого не произойдет.
Рабочий бэкап есть, но там не то. Это встречается довольно часто, потому что цикл жизни системы примерно следующий: сделали систему и поставили ее на резервное копирование. Потом рано или поздно поменяли архитектуру системы, добавили/убавили сервера, диски, переименовали, восстановили рядом из бэкапа, а отразить изменения в политике резервного копирования забыли. Вот и получается, что в бэкап идет не то что нужно.
Зачем тестировать
Казалось бы, ответ простой: чтобы удостовериться, что из бэкапа можно восстановиться. Но есть еще пара важных организационных моментов, которые неплохо бы для себя прояснить.
Понимание реального RTO. Умозрительные оценки будут отличаться от реальности. Особенно если весь процесс восстановления не ограничивается разворачиванием данных или приложений из бэкапа. Прежде чем восстанавливаться, нужно понять, что и откуда мы восстанавливаем. После восстановления не всегда система сразу готова к использованию, иногда требуются ручные настройки. После нужно проверить работоспособность восстановленных систем. Если бэкапы хранятся на лентах вне офиса, то нужно понять, как быстро их довезут до вашего офиса. Все это увеличивает время восстановления или часы ко времени восстановления.
Так что если рассматривать весь путь восстановления “от двери до двери”, то скорее всего RTO получится больше, чем просто “чистая” скорость восстановления данных.
Кто и что делает. Во время тестовых восстановлений тестируется не только техника, но и работа людей, процессов, регламентов, если они есть;) Это возможность выявить слабые места, продумать, что вы будете делать, если нужного человека не окажется на месте.
Чем больше людей задействовано в восстановлении, чем нужнее такие боевые учения.
Как тестируем
Частота тестирований. После того как настроили систему резервного копирования, проверьте, хотя бы раз, что у вас там бэкапится, и попробуйте восстановить.
Далее расписание проверок определяет владелец сервиса, например, разработчик, исходя из того, как часто вносятся изменения в приложения/данные, важности тех или иных данных, какие у него есть ресурсы для тестирования.
Различные сценарии аварий и восстановлений из бэкапов. Включите воображение и продумайте различные причины, почему может понадобиться восстановление из резервной копии. Так вы проверите технику, процессы, людей в боевых условиях, а не проведете сферическое в вакууме восстановление. Удобно для этого наметить модели угроз. Как вариант:
- сбой аппаратуры: отказал диск, сервер с исходной информацией;
- программный сбой: неудачное обновление, вирус;
- человеческий фактор: администратор удалил нужный файл.
В каждом из этих случаев восстанавливаться нужно будет в разном объеме: где-то отдельные файлы, а где-то разворачивать все.
Обязательно попробуйте восстановиться удаленно с домашнего компьютера. Ведь сбои происходят не только в рабочие часы.
И еще продумайте действия на пару шагов вперед: что будете делать дальше, если во время восстановления бэкап оказался пшиком или восстановиться не удалось. Если во время тестов выяснилось, что последний бэкап оказался нерабочим, по возможности сделайте новый бэкап вне очереди или предупредите коллег, чтобы они работали с данными максимально бережно до следующего цикла резервного копирования.
Восстанавливаться из разных точек времени. Неизвестно, какие именно бэкапы вам понадобятся, поэтому при тестировании пробуйте восстановиться из разных точек восстановления. Так вы проверите, что у вас в порядке, например, не только пятничный бэкап, но и тот, что вы делаете в среду. Чем обширнее будет выборка, тем меньше поводов переживать за работоспособность резервных копий.
Документирование процедур восстановления. Как-то читал, что в одной конторе используют следующий подход к тестированию восстановления из бэкапа: человеку, который ничего не знает о системе, предлагают сделать все восстановление только по документации, никто из коллег ему не подсказывает. Потом по результатам проверяют, удалось ли восстановиться, и делают выводы об актуальности инструкций. Необязательно идти на такие крайности во время боевых учений, но хорошо бы зафиксировать в регламентах и прочей документации все необходимые действия по восстановлению той или иной системы.
Делается это для этого, чтобы была возможность запустить процесс восстановления, если человек, отвечающий за систему, временно недоступен.
Также нужно позаботиться, чтобы вся необходимая информация для восстановления системы (конфигурационные настройки, лицензионные ключи, пароли) была не только в голове отсутствующего администратора, но продублирована в электронном виде и надежно хранится вдалеке от посторонних глаз.
На всякий случай: тестируем восстановление в отдельной песочнице, не рискуя продуктивом.
Как делать бэкапы, чтобы не стать грустным админом
В международный день резервного копирования вспоминаем вместе с клиентами Selectel, какие лучшие практики и косяки в работе с бэкапами встречались в их карьере.
Сегодня международный день резервного копирования. Повод вспомнить, какие промахи в настройке и хранении бэкапов зацементировали ваши нервные клетки и остались навсегда в виде неуловимой тяжести опыта в глазах.
Предлагаем в честь праздника сыграть в игру «Было/ не было». С помощью клиентов Selectel, которые подключили автоматические бэкапы по расписанию, мы описали лучшие практики и косяки при работе с бэкапами. С какими из них вы встретились в карьере? Поучительные байки в комментариях приветствуются!
Составлял подробную документацию по бэкапам
Достойный подход, одобренный сотнями крепко спящих по ночам админов. Многие согласятся, что первый шаг в работе с бэкапами — это составление документа, в котором описывается, что и как часто нужно делать, где хранить, как восстанавливать. Нередко такой документ является частью Disaster Recovery Plan компании.
Документация нужна не только для того, чтобы ничего не забыть, но и выбрать максимально рациональный способ снятия и хранения бэкапов. Так получится найти баланс между эффективным расходованием средств и надежностью решения. Ведь далеко не каждой системе подойдет ежедневный полный бэкап.
Вот что рассказывает о своем опыте клиент Selectel, который занимается инфраструктурой страховой компании:
«По разным системам у нас есть разные регламенты бэкапирования. Их формулируют владельцы сервиса / приложения исходя из собственных аргументированных потребностей и требований государственных регуляторов, если они есть.
Некоторые системы бэкапятся каждый день или каждую неделю. Если есть активная на запись база данных и потери критичны, бэкап снимается с логов каждый час. Если база большая, то в будни ночью делается дифференциальный бэкап, а полный — в выходные. Для некоторых данных нужно еще организовать долгосрочное хранение на ленточных кассетах до 5-10 лет.
В ответственности админа могут быть сотни серверов. Знать и помнить требования к бэкапам каждого — невыполнимая задача. Документация выручает: сисадмин все настраивает по регламенту и далее следит, чтобы все работало. К составлению таких документов в компании относятся крайне серьезно».
Ошибся с выбором окна снятия бэкапов
Выбор времени снятия бэкапа важен. Нужно, чтобы в этот период происходило минимум операций с данными — так легче гарантировать консистентность резервной копии. Кроме того, это снижает шансы, что резервное копирование будет идти медленно и тормозить систему в целом.
Разработчики знают, что, когда бэкапится база данных, индексы лучше не обновлять, иначе задачи накладываются друг на друга. Как минимум обе операции будут идти дольше и часть ресурсов будет «выедаться» текущей нагрузкой, как максимум — наткнешься на более диковинные конфликты, известные лишь DBA.
Клиент, который развивает площадку для автоматизации рекламных кампаний, обезопасил себя от подобной ошибки с помощью GitHub:
«Все расписания бэкапов у нас лежат в репозитории. На их основании можно найти свободное окно для резервирования нового сервиса.
Окно определяется в зависимости от порядка взаимодействия с сервисом. Где-то пользователи работают с 9:00 до 18:00 — например, бухгалтеры в 1С. После окончания рабочего дня они не задерживаются, так что бэкапиться можно с 6 вечера.
С какими-то системами люди могут взаимодействовать постоянно. Тогда мы снимаем бэкапы с реплики в момент минимальной нагрузки. Потому что, когда реплика бэкапится, входящие записи копятся и занимают место. И нужно рассчитать так, чтобы места хватило как на сам рост базы, так и для wal».
Использовал непроверенное решение для бэкапов
Обычно резервное копирование — не место для экспериментов. С другой стороны, непроверенное решение можно тестировать в дополнение к зарекомендовавшему себя способу снятия бэкапов. Если пройдет проверку, его можно использовать на постоянной основе.
Один из клиентов рассказал такую поучительную историю из прошлого:
«Однажды использовал бесплатную программу, которая делала что-то наподобие zip-архивов данных. Впоследствии оказалось, что zip нечитаемые — все архивы побиты. К сожалению, понял я это только тогда, когда нужно было восстановить данные. Сделать это, разумеется, не удалось. Зато с тех пор я всегда проверяю работоспособность копий».
Не проверял работоспособность резервных копий
Говорят, все системные администраторы делятся на три группы: те, кто не делает бэкапы, те, кто делает бэкапы, и те, кто проверяет их консистентность и работоспособность.
Действительно, далеко не всегда бэкапы — это «сделал и забыл». Работа по проверке целостности и периодические восстановления из бэкапа не менее важны. Это даст гарантии, что в экстренном случае резервные копии восстановятся штатно. То есть вы найдете их там, куда положили, они будут консистентными, и вы вернете последнюю версию системы за известное количество времени.
Способов проверки немало. Так, один из опрошенных нами специалистов пробовал и ручные проверки, и решения из «коробки»:
«Сейчас у меня нет регламентов проверки. Просто проверяю работоспособность копий время от времени. Делаю это нерегулярно, но, если настраиваю что-то новое, обязательно чекаю архив.
У ряда компаний этот процесс задокументирован. Так, мой коллега раз в полгода обязательно восстанавливал бэкап production-базы данных и передавал разработчикам на проверку. Некоторые команды хотят, например, видеть базу, развернутую из бэкапа только на чтение, чтобы убедиться, что все данные записаны корректно».
Другой сисадмин с десятилетним стажем уверен, что формирование механизмов проверки бэкапов требует много ресурсов, но, если они есть, нужно делать:
«При первом запуске системы и бэкапов проверяем работоспособность бэкапов и развертку из них. Если бюджет позволяет, проводим искусственные тесты возникновения внештатных ситуаций — так называемые Monkey testing. В рамках теста начинаем отключать инфраструктуру по частям и, руководствуясь регламентом, тренируем необходимые действия в каждом случае. Такие тесты нужны в сложных системах, где есть распределенность не только за счет репликаций, но и функционала (если у вас микросервисы, например)».
Масштабные тесты нужны не всегда. Иногда для проверки достаточно развернуть пустой проект, наполнить его данными, сделать бэкап и восстановиться из него. Также есть практика закрывать риски для систем несколькими способами резервирования: одна копия из 3-4 будет целостной с большей вероятностью.
Использовал несколько способов резервного копирования
Кто-то называет это оверхедом, а кто-то — лучшими практиками. Тем не менее, как показывает опыт сисадминов, чем богаче панель инструментов для бэкапов, тем надежнее. В некоторых компаниях реализовывать бэкапы несколькими способами — корпоративная норма. Главное, чтобы было место для их хранения. Часть клиентов бэкапов по расписанию Selectel подключили решение как раз в добавку к существующим способам бэкапирования — чаще всего кастомным скриптам.
DevOps-специалист, с которым нам удалось поговорить, отметил, что несколько видов бэкапов полезны там, где нужно закрыть и риск падения инфраструктуры, и риск потери данных. Для критических сервисов стоит поднять реплику, чтобы быстро переключиться на нее при отказе «железа». Исключительно на RAID и SMART-мониторинг дисков полагаться не стоит.
Защита данных тоже может быть в двух вариациях. Вот, так, например, решал эту задачу один наш клиент:
«В нашей компании есть правило: резервируем всю инфраструктуру и всегда двумя способами. Так, база данных бэкапится и в режиме plain text — это чистый SQL, который описывает всю структуру базы данных, и в формате бинарных файлов. В экстренном случае это позволит нам более гибко подойти к восстановлению базы».
Не ставил алерты
Хорошо настроенные бэкапы усыпляют бдительность. Они могут долгое время работать без нареканий — вы уже забудете о них, но в определенный момент что-то может пойти не так. Регулярно проверять статус бэкапов сложно, особенно если их много. Правильным решением будет поставить уведомления в систему мониторинга или на личную почту о том, что случилось какое-то триггерное действие.
Один из опрошенных клиентов Selectel предлагает не мелочиться и ставить алерты на все:
- факт снятия копии;
- копия больше или меньше, чем должна быть;
- остаточный объем места на сервере, куда отправляются бэкапы (чтобы место не кончилось);
- статус для команды бэкапа (может завершиться ошибкой) и др.
Конечно, можно работать без алертов, но зачем отказываться от возможности дать инфраструктуре самой сообщить об ошибках. Так, у системного администратора, который поделился с нами опытом, потенциальные проблемы автоматически формируются в тикеты:
«У нас есть проверка на размер бэкапа: он должен расти. То есть текущая резервная копия должна быть больше или равна предыдущей. Если бэкап меньше, сразу формируется тикет — мы расследуем причины. Иногда это связано не с ошибками в копировании, а, например, с чисткой базы. Проверки проводятся в среднем раз в неделю, в зависимости от объема базы данных. Скрипт запускается автоматически по планировщику в GitLab».
Хранил резервные копии на одном сервере с бэкапируемыми данными
Иногда это объясняется тем, что другого места нет и так экономнее (плохой сценарий). Или же так админ решает хранение горячей копии данных, чтобы восстановление конкретного утерянного файла происходило быстрее (хороший сценарий). В таком случае правильность решения определяется наличием холодной копии на стороннем сервере.
Не всегда проблема с системой может затронуть весь сервер. Например, если работник компании нечаянно удалит несколько важных файлов, самой инфраструктуре ничего не грозит. Но, если проблема более сложная, под раздачу попадет весь сервер вместе с бэкапами. Подобных случаев в практике немало. Вот, например, рассказ инженера, который администрировал серверы 1C:
«Ситуация: в пятницу вечером взломали сервер. В субботу бухгалтер захотел поработать, а у него ничего не открывалось. На самом сервере все файлы были зашифрованы. Хорошо, что резервные копии хранились отдельно и нам удалось все восстановить».
Проблема с сервером может произойти как в ПО, так и в «железной» части. Поэтому резервирование серверов часто идет рука об руку с бэкапами данных. Есть такая неприятная история:
«У сервера с базой данных сгорел блок питания — машина перестала работать. Блок питания заменили, но система не загружалась. Вчерашний бэкап “умер” вместе с сервером. Пришлось брать более старую холодную копию. Разницу между репликами восстанавливали вручную всем отделом: вспоминали, что делали последние два дня, какие документы выписывали и меняли».
Забывал делать бэкапы
Если объект бэкапирования не самый большой, проще сделать копию вручную, чем писать скрипты и настраивать автоматизацию. Но в таком случае велик шанс, что в какой-то особо загруженный день на своевременный бэкап не хватит времени.
Проблему забывчивости, нехватки времени и добрую половину ранее озвученных вызовов решит сервис бэкапов сетевых дисков по расписанию. Бэкапы создаются автоматически по плану, который достаточно настроить один раз и применить ко всем дискам. Для переноса резервных копий в хранилище используются выделенные сети провайдера (не нужно нужно думать о торможении систем из-за ограничений собственных каналов). А для объема хранимых бэкапов нет ограничений — можно забыть о страхе, что однажды бэкап не сделается из-за отсутствия свободного места на диске.
Автоматические бэкапы в облачной платформе
Настройте расписание резервного копирования и спите спокойно.
Резервное копирование данных простым языком
Недавно моя подруга попросила объяснить ей, как делать резервное копирование данных. Она гуманитарий, поэтому ей нужны были варианты, в которых ничего настраивать не нужно. Так как она — человек не глупый, который любит сам разбираться в проблеме и принимать решение, я решила собрать для нее основные принципы и описать плюсы и минусы тех или иных вариантов (как я их вижу). Опубликовать здесь я решилась на тот случай, что кому-то из вас пригодится – помочь другу или родственнику. Буду очень рада комментариям о том, как можно было бы сделать текст проще и понятнее.
Основные принципы
1. Регулярность и частота
Backup данных должен быть таким же регулярным, как прием таблеток. Именно за эту дисциплинированность себя можно будет благодарить, если вдруг произошел какой-то крах. Порой потерять даже всего несколько рабочих дней из-за того, что backup не сделан, — может быть очень болезненным. Ответить на вопрос — как часто делать бэкап возможно, поняв, данные за какой промежуток времени тебе было бы наименее болезненно терять. Один из оптимальных вариантов — backup данных раз в неделю по выходным.
Раздельность
Желательно, чтобы данные сохранялись на отдельный внешний жесткий диск (или другой носитель), хранились в отдельном месте от основных данных. Принцип вполне очевиден — если произошла проблема, она будет локализована в одном месте. Например, если сломался жесткий диск на компьютере, диск с резервной копией будет функционировать отлично. Тем не менее, здесь стоит соблюдать баланс между легкостью доступа и безопасностью. Жесткий диск, стоящий рядом с компьютером, существенно повышает мотивацию использовать его по назначению. И в то же время, это не самый безопасный вариант для очень важных данных, которые терять нельзя ни в каком случае. Именно поэтому различают резервное копирование и архивацию данных.
Перепроверка
Как только сделана первая резервная копия данных, необходимо сразу проверить, что из нее эти данные можно восстановить! Это означает не только то, что файлы становятся видны. Нужно открыть несколько файлов на выбор и проверить, что они не испорчены. Желательно такую проверку потом повторять раз в какой-то период (скажем, раз в год).
Различение
Лучшая практика — различать данные по категориям. Категорией может быть их важности для тебя, частота обновления, или просто тематика.
Зачастую программы резервного копирования делают так называемые «образы» (image). Они выглядят как один единственный файл. Так вот в каждый такой образ лучше сохранять различные данные.
Для чего это нужно. Данные разной важности требуют разного обращения с собой, это очевидно. Свои важные документы, наверняка, захочется хранить более бережно, чем, скажем, коллекцию фильмов. Разделив данные по частоте обновления можно, к примеру, сэкономить время занимаемое резервным копированием. Тематика — какие данные желательно вместе восстанавливать за один шаг? Яркий пример двух типов backup, которые следует делать раздельно:
Резервное копирование данных
Это документы Word, фотографии, фильмы и т.д. Так же к этому относятся, но часто забываются — закладки в браузере, письма в почтовом ящике, адресная книга, календарь со встречами, конфигурационный файл банковского приложения и т.д.
Резервное копирование системы
Речь идет об операционной системе со всеми ее настройками. Такой backup избавляет от необходимости устанавливать операционную систему заново, делать все настройки, устанавливать программы. Однако, это не самый из необходимых типов резервного копирование.
Куда делать backup
1. Внешний жесткий диск. Часто можно купить прямо в коробке. Бывают ноутбучные — такие диски маленькие по размеру, но более дорогие. Обычные жесткие диски можно сравнительно дешево купить объемом в 2 Тб — тогда за место на диске долго не придётся беспокоиться.
+ Достаточно надежный (если не ронять и не трясти чрезмерно)
+ Относительно недорогой
-Необходимо самому не забывать подключать диск для бэкапа
-Не очень удобно переносить (не относится к ноутбучным дискам)
2. USB-stick — подойдет как дополнительное средство, когда данные хотелось бы переносить с одного компьютера на другой и/или иметь под рукой. Так же если сами данные не хочется хранить на компьютере.
Есть одно большое но — у флешки ограничено число записей, так что если на ней хранить данные приложения, которое будет интенсивно записывать, то флешка (usb stick) довольно быстро прикажет долго жить. К тому же, по моему личному впечатлению, они достаточно часто ломаются. Мой знакомый, покупая самые дорогие флешки, которые позиционировались как «не убиваемые», получал сломанную флешку за месяц-другой. Справедливости ради, надо сказать что у меня до сих пор ни одна флешка не сломалась, некоторые работают уже лет 5. Тем не менее, только на одном только usb-stick`e я бы хранить данные не стала.
+Мобильное хранение
+Занимает мало места
+Очень дешево
3. Хранение данных на удаленном сервере ( или в облаке).
Есть свои плюсы и минусы:
+Данные будут доступны не только дома, но и на работе, во время путешествий.
+Локационная раздельность основных данных и резервных копий (например, если случается, не дай бог, пожар данные выживают)
+Нет нужды подключать жесткий диск для бэкапа, как правило, все делается полностью автоматически.
-Желательно шифровать данные, так как неизвестно кто к ним может получить доступ
-Тратится большой объем трафика (если он ограничен, то возникают проблемы)
-Зачастую бесплатно можно хранить только данные до 2 Гб. Так что, такой backup — это дополнительная статья расходов
Список с хорошим описанием сервисов можно найти тут
Чем делать backup
Приведу список приложений, на которые стоит обратить внимание (по моему мнению), при резервном копировании на жесткий диск.
Из платных хороши
Из бесплатных пользуются популярностью
1. Genie Backup Manager — очень удобная программа, но немного тормозит при работе
2. Handy Backup — простой интерфейс, работает быстро.
Дополнительно
Часто в настройках программ по backup есть опция — сделать инкрементальный или дифференциальный backup. Практическое различие довольно простое. При дифференциальном резервном копировании можно сэкономить на месте которое он занимает. Зато есть только две возможности восстановления: данные в том состоянии, когда был сделан полный backup + данные на тот момент, когда был сделан дифференциальный.
Инкрементальный backup же позволяет откатиться на любой из моментов в прошлом, когда делалось резервное копирование. Однако, особенно если изменения в данных происходили часто, место будет съедаться быстро.