Как настроить резервное копирование  сайта?

Итак друзья, последнее время я занимаюсь всевозможными изысканиями в профессиональном плане, поэтому  иногда статьи будут выходить сильно технического характера. Хотя ранее я тоже иногда баловался таким статьями, но  теперь и тематика сайта к этому располагает и моя профессиональная деятельность.
У меня была беседа с друзьями, а они занимаются системным администрированием сетей. Так вот, они сильно были удивлены, и даже где-то расстроены, когда в подробностях узнали о том, на что способен SSH.  А он способен делать в буквальном смысле ВСЁ!

Что такое скрипт?

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

Зачем нужен скрипт для бэкапа?

Польза от такого формата очевидна — однажды написав скрипт, его можно выполнять многократно,  причём автоматически и по расписанию.  Именно это и требуется для решения задачи по созданию резервных копий. Бэкапирование сайтов и VPS поддерживается у многих хостеров, у некоторых по умолчанию, у некоторых это дополнительная услуга.  Ведь для хранения бэкапов требуется дисковое пространство.   Если проекты небольшие и бэкапы занимают несколько мегабайт, то это не создаёт проблем.  Но если резервные копии ваших сайтов занимают несколько гигабайт, то бэкапить это становится сильно сложнее.

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

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

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

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

Если вы хотите просто настроить бэкапы за 500 рублей:

Я принимаю заявки по контактам на vpsadm.ru. А ещё предлагаю  воспользоваться новой интересной фриланс-платформой  Kwork

---

Если вы с ней ещё не знакомы — рекомендую. Это биржа от компании Мирафокс, которую вы возможно уже знаете по другим проектам для вебмастеров (Telderi, Miralinks, Gogetlinks). На Kwork  не фрилансеры побираются по размещенным потенциальным заказчиком  предложениям, а сами выставляют предложения,  которые заказчик может выбрать.  «Фишка»  сервиса — базовая стоимость любого кворка (так называют предложения фрилансеров)  всегда 500 рублей.

Мой кворк по резервному копированию

А для тех, кто хочет разобраться во всём до конца и настроить самостоятельно — едем дальше.

Требования к бэкапам сайта

Итак, подведём промежуточный итог в виде требований к нашим резервным копиям:

1. Бэкап должен содержать в себе всё, что нужно для восстановления проекта на любом другом сервере или хостинге.  Бэкап должен быть удобным — самого простейшего доступного формата.
2. Бэкап должен быть всегда под рукой.
3. Бэкап должен храниться где-то далеко от основной работающей системы, на другом физическом носителе.
4. Бэкап должен делаться максимально быстро и с наименьшими затратами ресурсов.

Дело за малым — создать такое решение.  2 и 3 пункты могут ввергнуть вас в когнитивный диссонанс, но сейчас дойдём до этого и станет понятней.

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

Какие части сайта нужно бэкапить?

Сайт обычно состоит из CMS и файлов.  Мы не будем их разделять и пусть это будет одна составляющая — файлы.

В каких-то особых случаях это можно или даже нужно разделять. К примеру, если мы имеем слишком большой объём или большое количество файлов самой CMS — нам нет смысла каждый раз бэкапить  эту часть.  Также встречаются варианты со всевозможными временными файлами, кэшами, которые также можно не копировать, ибо при восстановлении все эти части будут воссозданы, для нас не критична их потеря. 

Но чаще всего сама CMS имеет небольшой объём относительно всего проекта, или  в принципе.  Поэтому проще сохранять в резерве всё подряд.

Как и чем делать бэкапы файлов сайта

В unix-системах, есть пару штатных средств которые лучше всего для этого подходят.  Это архиватор — утилита tar, которая используется в связке  с компрессором gzip.
tar zcfv  backup-`date +%y%m%d`.tar.gz  /var/www/myhosting/

На выходе получается архивный файл, в который упакованы сжатые файлы проекта.

Чем делать бэкапы большого размера?

При малом объёме данных такой подход себя оправдывает.  Но если проект занимает сотни мегабайт или даже гигабайты — такой вариант очень плохо подходит для резервного копирования, поскольку сжатие будет занимать кучу времени и прилчно отъедать ресурсы системы.  К счастью, в Linux имеется прекрасная штука  rsync. Это утилита для синхронизации файлов.    Это даже не просто утилита, а целый протокол, активно используемый для некоторых задач, но для нас интересна именно утилита.  И что ещё важнее, она умеет работать поверх SSH, что нам пригодится в дальнейшем.

Простейший пример использования:
rsync -avh /var/www/site.com/  /var/backup/site.com

Эта команда полностью зеркалирует папку /var/www/site.com/ с папкой   /var/backup/site.com. Я говорю — зеркалирует, потому что это не просто копирование, а именно синхронизация.  Для неё характерны следующие особенности:

1. Файлы переносятся как есть — с сохранением даты создания и изменения
2. Файлы переносятся с  сохранением владельца и прав
3. В том случае, если во второй  папке уже есть какие-то файлы из первой папки они не копируются. Сверяется их хэш и если файлы действительно совпадают — то они не перезаписываются.
4. Имеет возможность не только копировать, но делать полную синхронизацию, с удалением из папки назначения тех файлов, которые исчезли из исходной директории.  Требует предельной внимательности при использовании, но порой незаменима.

Что такое синхронизация?

Третий пункт  —  это важнейшая особенность, которая как раз позволяет легко бэкапить большие объемы данных. Ведь если у вас уже имеется резервная копия, то утилите нужно лишь дополнить её новыми файлами и перезаписать изменившиеся.    Наверняка всем известны торренты — там используется нечто подобное. Файл не перекачивается, а дополняется, синхронизируется. Rsync работает точно так же. Поэтому, при общем полном объёме проекта в десятки гигабайт  —   вам не нужно гонять все десятки гигабайт данных, достаточно «долить» в имеющийся бэкап то, что появилось или изменилось.

Как сделать бэкап базы данных сайта?

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

Тут есть хорошая новость. Большинство хостеров регулярно  делает резервные копии всех баз данных, которые у них хостятся на виртуальном (shared) хостинге.

Однако, в случае с ВПС/ВДС  тут уже нельзя  сказать  так однозначно.  Если вы держите свои сайты на отдельном виртуальном или выделенном сервере, то это предполагает, что вы сами в состоянии озаботиться такими вещами.  Хостер же, банально  может не иметь доступа к вашим БД и даже не знать об их существовании. Чаще всего так и происходит.

Для бэкапов БД существует также множество способов, но все они используют вот это:

mysqldump -u dbuser -p dbpass  dbname > mysql-`date +%y%m%d_%H%M`.sql

Это и phpmyadmin, и панели управления вроде ISP  и сторонние утилиты вроде Navicat.  Все они используют штатные утилиты самой СУБД и работают поверх них. Однако, штатные утилиты имеют преимущество   —  бэкапы сохранённые с их помощью всегда гарантированно рабочие.  Что же касается сторонних решений — тут надо только надеяться на то, что оно делает действительно  целостный бэкап.   В случае с mysql, на котором работают большинство сайтов  — это утилита mysqldump.   Если используется БД postgesql  — команда будет выглядеть несколько иначе, но это тоже будет штатная утилита самой Postgres:

pg_dump -U user -Fc dbname > pgsql-`date +%y%m%d_%H%M`.dump

В данном случае используется специальный формат дампа — Custom, доступный в Postgresql. Он гораздо удобней обычного SQL, но таковой в постгрес тоже доступен — просто нужно выполнять эту команду без опций Fc.

Куда сохранять бэкапы сайта?

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

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

Тогда зачем это нужно? Представьте себе ситуацию.  Нерадивый программист, решил что-то изменить в коде шаблона. Но ошибся и сайт перестал открываться.  Он, конечно же, не сохранил исходный файл (потому и нерадивый)  и теперь не помнит как это вернуть обратно. Он надеялся что фатальной ошибки не будет, что тут надо просто подправить пару функций и переменных и… сайт ложится  и не открывается.   Программиста прошибает пот…  Да это может быть и не программист, а вы сами.  У меня такое случается, например.   Уж  я-то ведь  точно знаю что делаю, что  ничего плохого не случится, если я уберу вот эти пару строк кода и вот здесь тоже сменю параметр…  Упс.

Как настроить автоматический бэкап сайта по расписанию?

Но меня не прошибает пот.   Потому что  файлы всех  сайтов на впс  сбрасываются в соседнюю папку, каждые два часа.   А если вирусы  или взломали сайт? это ведь можно заметить гораздо позднее, чем через 2 часа, тогда в бэкапе тоже будут испорченные данные.   Верно. Поэтому есть ещё одна папка, куда сбрасываются все  файлы раз в 3 дня. У меня записано в crontab:

0 */2 * * * rsync -avh /var/www/ /var/h2backup/ #бэкап делается каждые 2 часа
0 1 */3 * * rsync -avh /var/www/ /var/d3backup/ #раз в три дня в час ночи

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



Но ведь это увеличивает объем файлов в 3 раза.  Да,  увеличивает.     Но  бэкапов много не бывает, друзья :)   Других способов на 100% обезопасить себя от вышеперечисленных неприятностей я не знаю.  Если самому можно быть просто аккуратней  и внимательней при правке кода, сохранять копию файла перед редактированием , то при работе команды это становится невозможным. И чем больше команда, тем больше верятности, что где-то кто-то накосячит.  Что уж говорить о кулхацкерах и вирусах.

Надеюсь по этому пункту всё понятно.

Зачем сохранять бэкапы на удалённое хранилище?

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

Это значит, нужно сохранять свои данные на каком-то облачном  хранилище, или, на худой конец,  на своём рабочем или домашнем компьютере — это доступно всем без исключения.  Особенно, учитывая,  что где, как не на личном компьютере, у нас есть сотни гигов, а то и терабайты диска, бесполезно простаивающие или забитые каким-нибудь хламом :)    Кстати, именно такая ситуация  стала предпосылкой к написанию всего этого талмуда.  Один мой знакомый озадачился бэкапированием сайта, в 50 гб объёмом, на свой домашний компьютер.   И обратился за помощью ко мне.  Подумали, потестировали, и родилось решение — как делать бэкап по SSH на компьютер с Windows.

Если у нас имеется другой ВПС — то можно бэкапить данные на него без особых трудностей.   rsync придётся здесь как нельзя кстати. Сделайте авторизацию по ключу, добавьте  пару строк в вашем crontab  c нужной периодичностью — и можно забыть про бэкапы.   Точно также можно сделать и для хранения бэкапов на домашнем компьютере, если там стоит Linux или FreeBSD.

Как бэкапить сайт по SSH на домашний компьютер Windows?

Но вот в случае с Windows придётся заморочиться. Для этого потребуется утилита plink.exe. Получить её можно на putty.org по ссылке here. Она позволяет использовать ssh из командной строки винды.  Это маленькая но крайне полезная штуковина поможет создать те самые  скрипты для автоматического бэкапа.

Просто создайте текстовый файл с такими строками:

d:\plink.exe -pw rootpassword  root@example.com -C "mysqldump -uroot  -ppassword  sitedb|gzip">d:\backup\sitedb-%date%.gz
d:\plink.exe -pw rootpassword root@example.com -C "tar czfv - /var/www/example.com/">d:\backup\example_com-%date%.tar.gz


здесь  rootpassword — это пароль ssh, а -uroot  пользователь БД — -uuser, например.  -ppassword — пароль этого пользователя, соответственно — —pyourpass,    sitedb — имя БД  сайта.   Здесь не пугайтесь, mysql поддерживает опции слитно со значениями, но можно и поставить пробел — -u user и -p password. 

И сохраните файлик с расширением bat.  Теперь, запустив этот файлик двойным кликом вы получите бэкап базы данных и сайта в указанную папку.

сохранение в bat

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

Как настроить автоматические бэкапы в Windows?

Очень просто — нужно использовать штатный планировщик для запуска скрипта.

Нажмите win+R  и запустите  taskschd.msc:

Запуск планировщика Windows

В  меню «действие»  выберите «Создать задачу»:

В первой вкладке у вас будет обязательное поле для произвольного имени задачи.  Затем выберите вкладку «действия»  и укажите путь к своему скрипту:

Перейдите на вкладку «Триггеры» и задайте расписание:

Вы можете настроить здесь любую периодичность.

Теперь перейдя в раздел «Библиотека планировщика» вы можете убедиться, что ваша задача создана.

Это самый простой способ бэкапировать сайт на домашний компьютер. Всё что вам нужно — это доступ к хостеру по SSH и утилитка plink.   Но будьте внимательны, если забыть об этом на пару месяцев, вы можете очень удивиться, когда на вашем диске закончится свободное пространство :) Поэтому заглядывайте в папку, куда вы настроили сохранение резервных копий и удаляйте старые бэкапы.  Этот метод отлично подходит для небольших проектов в несколько мегабайт.  

Как избежать переполнения  и как быть, если вам нужно бэкапить большие объёмы данных?  Об этом расскажу обязательно, но в следующий раз.   Подписывайтесь на новые статьи, друзья, и вы этого не пропустите!

Если вы дочитали досюда, но настраивать самому неохота, а настроить бэкапы таки надо. Всего 500 рублей :)

Велком на vpsadm.ru или Kwork, друзья!  Усё будет сделано в лучшем виде, дайте мне нажиться на решении вашей проблемы :)

Мой кворк по резервному копированию