На хостинг надейся, а сам не плошай
Господа, не ленитесь! Делайте своевременный backup своих сайтов самостоятельно.
У меня штук 20 сайтов лежат на трех хостингах: VDS сервер от ipserver.com, shared-хостинг от sweb.ru и shared-хостинг от masterhost.ru. На всех трех есть система автоматического резервного копирования. Когда я был маленький и зеленый, я всецело полагался на эту, как мне тогда казалось, безупречную систему резервирования данных. Зачем делать backup сайтов, если всегда можно написать запрос на восстановление хостеру и откатить сайт до некой последней рабочей версии? Всегда, да не всегда. Во-первых, backup делается с определенной периодичностью, которая может не совпадать с частотой поломок сайта. Во-вторых, хранятся не все версии сайта за определенный временной промежуток, а только их небольшая часть. И, по закону подлости, нужной-то версии как раз и не оказывается. В-третьих, на VDS место под backup отводится в пользовательской дисковой квоте, таким образом на резервные копии сайтов отжирается полезное место на диске.
В том, что backup, который делают хостеры, вещь абсолютно бестолковая, я убедился, когда на один из моих эккаунтов на хостинге заполз IFRAME троян. Во все индексные файлы инжектировалась бессовская тварь, грузившая с удаленного сайта вирус на машину пользователей. О том, что на сайте вирус, я узнал только через неделю. За это время три последних backup уже были «затерты» вирусными копиями «как бы рабочего» сайта. Получается, что если сайт ломается, и вы узнаете об этом после выполнения процедуры резервного копирования, то восстановить сайт из backup вы уже не можете. Потому что и в резервной копии будет лежать «убитый» сайт. Кстати, восстановление сайта из резервной копии у того же мастерхоста – процедура, прямо скажу – не тривиальная.
Итак, что я могу предложить? Могу предложить взять ответственность за сохранность файлов на хостинге на себя, и выполнять процедуру резервного копирования тогда, когда вам удобно и с частотой, с которой вам удобно.
Естественно, скачивать несколько тысяч файлов через FTP и делать резервную копию базы данных через phpMyAdmin неэффективно. Есть способ лучше – SSH! Я не знаю ни одного приличного хостинга, у которого не было бы доступа к хостингу по SSH.
Заходим по SSH на хостинг. Создаем один раз шелловский скрипт, который будет выполнять всю работу по резервированию данных и складывать их в нужную папку. Вам останется лишь скачать архивы себе на компьютер.
Шелл-скрипт (например, backup.sh) должен выполнять два вида операций:
1. делать резервную копию Document Root директории веб-сервера в архив .tgz (.tar.gzip)
2. делать дамп базы данных mysql (или что там у вас) и архивировать его в .tgz (.tar.gzip)
Для выполнения первой операции вписываете в скрипт строку
tar cf backup_www_cmcka_ru.tar cmcka/www/*
Эта строка создает файл backup_www_cmcka_ru.tar в текущем каталоге, архивируя в него полное содержимое директории cmcka/www/
Для выполнения второй операции вписываете в скрипт строку
mysqldump music4ru_sms -um4ru_sms -psgwrttewrs1 > backup_cmcka_ru.sql
Эта строка создает файл backup_cmcka_ru.sql в текущем каталоге, сохраняя в него полный дамп базы данных mysql из базы music4ru_sms от пользователя m4ru_sms, авторизируя пользователя паролем sgwrttewrs1.
Третья строка и четвертая строки должны содержать
gzip *.sql
gzip *.tar
Таким образом вы архивируете с помощью утилиты gzip дамп базы и архив сайта.
После чего можно законнектится на сайт по FTP и скачать два полученных архива.
При умелом подходе процедуру резервного копирования можно настроить по определенным часам (дням, месяцам) через cron. Можно сразу указывать даты резервного копирования в именах файлов, можно копировать файлы в определенную директорию, да много еще чего можно придумать. Но главное не забывать хотя бы раз в месяц заходить на хостинг по SSH, запускать backup.sh и копировать полученные архивы себе локально, тогда никакой кризис вам не будет страшен.