(Облегченные) стратегии резервного копирования для стека приложений LAMP?
Я изучаю некоторые легкие инструменты для резервного копирования стека ламп. Двумя наиболее важными частями являются
- кодовая база php и
- база данных mysql.
Я могу tar/bz2 код и mysqldump и восстановить его на новом сервере (если старый выйдет из строя), и это более или менее нормально.
В любом случае, существуют ли более полные решения для этого?
- например, отслеживать и повторно устанавливать дополнительно установленные pear-пакеты;
- отслеживать другие пакеты связанный со стеком LAMP, установленным через менеджеры пакетов Linux, например APC;
- храните конфигурации mysql и php вместе с резервными копиями и возможностью их автоматического восстановления...
- возможно, полные образы серверов, которые можно восстановить без необходимости переустановки всего..
Мне любопытны подсказки, советы, опыт, решения..
3 answers
Базой кода PHP следует управлять в системе контроля версий, такой как SVN, Git и т.д. Простое создание tar не дает вам много возможностей, которые дает вам надлежащая система управления версиями.
Проблема с mysqldump заключается в том, что вам нужно заблокировать таблицы, которые вы сбрасываете, чтобы обеспечить согласованный снимок. Если это займет много времени, другие операции с БД могут прерваться во время ожидания. Мы используем замечательный скрипт для моментальной съемки работающей базы данных без чрезмерного замки. Он был разработан для среды Amazon/EC2, но принципы применимы к любой системе Linux с файловой системой xfs.
Вот отличное руководство по созданию образа машины Ubuntu (очевидно, вы можете использовать его в других дистрибутивах): http://ubuntuforums.org/showthread.php?t=35087
В двух словах (из статьи)
tar cvpzf backup.tgz --exclude=/proc --exclude=/lost+found --exclude=/backup.tgz --exclude=/mnt --exclude=/sys /
Для резервного копирования системы, затем отправьте ее по ftp на другой сервер.
Я могу ответить на несколько вопросов. Я знаю, что это не популярный пакет, но я всегда пересматривал схему с помощью RCS на сервере. Это не обязательно должен быть RCS, но нет причин не сбрасывать хранилище CVS/RCS с резервной копией.
Для "полных образов сервера" вместо автономной установки требований к приложениям (пакеты PHP и c) мы развертываем нашу собственную структуру bin/ src/ usr/ var/ lib/ в соответствии с каждым приложением , что упрощает резервное копирование и перспективу системного запроса.
Надеюсь, что помогает.
Я также видел, как mysqldumps RCS сохранял только изменения. Я уверен, что это было бы несколько нетривиально с точки зрения управления изменениями.