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

Так же следует помнить, что бэкап который просто делается, но не проверяется не существует, это очень хорошо показала авария в команде Gitlab’а(https://habrahabr.ru/company/southbridge/blog/321074/), когда выяснилось, что 6 бэкапов в разные места были неработоспособными или просто не существовали.

Ну и третье: бэкапы должны занимать минимум места.

Сначала немного теории, а во второй части нашей статьи(которая будет через пару дней) мы поговорим о практике.

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

О регулярности: все зависит от частоты изменения данных, обычно хватает бэкапа раз в сутки, но порой требуется более частый.

О плюсах инкрементальности:

Инкрементальный бэкап сохраняет только изменения относительно полной версии, благодаря этому мы экономим место и можем восстановить бэкапируемое на любой из моментов(я бэкапирую раз в день, то есть на любой из дней). При этом ежедневный полный бэкап занимает полное место для каждой своей копии. Простой пример: полное содержимое директории с сайтами одного из клиентов у меня занимает 7.1 гигабайта, в архивированном виде это выходит около 6.1 гигабайт, то есть ежедневный бэкап весит 6.1 гигабайт, а дальше место тратилось на 6.1количество дней хранения. Я перевел систему бэкапирования у этого клиента на инкрементальный бэкап 19 апреля, то есть 50 дней назад, если раньше для хранения бэкапов за 50 дней потребовалось бы 6.150=305 гигабайт, то сейчас с инкрементальным бэкапом весь бэкап занимает 6.7 гига, при этом я могу в любой момент сделать откат на состояние на любой из последних 50 дней.

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

С несколькими местами тоже достаточно понятно. Одна точка хранения, пусть даже супернадежная всегда находится под угрозой, особенно если это место у того же хостера, аварии и пожары в ДЦ случаются и вы можете потерять и данные боевого сервера, и бэкап сразу. У все того же клиента я для хранения использую место предоставляемое хостером(ДЦ в Германии) и место на собственном сервере(ДЦ во Франции). Таким образом я знаю, что даже в случае если на ДЦ хостера упадет метеорит я подниму данные из бэкапа хранящегося у меня.

Третье: необходимо следить за тем, что бэкап действительно выполняется. Не важно как вы это слежение реализуете, мониторингом который будет поднимать бучу если в директории в нужное время не появились новые файлы или почтой с отчетом(а лучше и тем, и другим), но вы должны обязательно следить за тем, что бэкап действительно прошел(а то будет как у Gitlab Inc.).

Четвертое: необходимо следить за тем, что бэкап валиден и существует на все даты, когда он должен был быть выполнен. Так как я использую duplicity для бэкапирования я это делаю используя ежедневные проверки самой duplicity и репортом в котором вижу, что бэкап есть.

Пятое и самое важное: необходимо регулярно самому, не доверяя никакой автоматике, проверять, что бэкап валиден, из него разворачиваются обратно все данные. Не верьте автоматике, она может помогать вам, но всегда нужно проверять, что бэкап цел, иначе будет, как в уже упомянутой истории с Gitlab Inc., когда они только после аварии обнаружили, что бэкапы-то у них битые, даже те, что есть. Минимум раз в месяц разворачивайте данные из бэкапов руками(ну или скриптом, но таки не только с отчетом на почту, но и с просмотром результатов глазами). Я раз в месяц лично и руками, не доверяя автоматике разворачиваю последний, на момент проверки, бэкап и сравниваю его с тем, что находится в продакшене, это занимает не так много времени, но позволяет быть уверенным, что в случае аварии я все спокойно подниму.

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

Во второй части моей заметки мы поговорим об инструментых, о duplicity, о minio, о скриптах для бэкапирования БД и прочих приятных вещах.