Web сервер на debian (бэкапы, восстановление и т.п.) (совсем чайник)

[Sergey069]

В общем то задача довольно простая ( то есть так делают все кругом, но вот теперь мне нужно сделать так самому). Если по сути у меня есть 2-3 сайта, для которых я хочу собрать сервер на Debian 6. Установить установил, apach2+php5+mysql5, все в основном работает. Теперь начал думать о том как мне быть в случае каких то сбоев с дисками или сбоя ОС или банально взлома с какими то сильными последствиями и всякого такого...

Что мне пришло в голову - сделать RAID массив из двух винтов и в случае физической поломки заменять жесткий и дальше работать. Но вот как быть с остальным и как вообще это делается? Как в случае каких то проблем восстанавливать резервную копию? Например если сломают, будут проблемы с ОС софтом, какие то глюки или еще что-то? Просто не знаю куда копать и как вообще и как RAID может мне помочь в этом случае т.е. я им не пользовался, растолкуйте пожайлуста как организуются не сильно дорогие системы такого плана?

[watashiwa_daredeska]

Например если сломают, будут проблемы с ОС софтом, какие то глюки или еще что-то? Просто не знаю куда копать и как вообще и как RAID может мне помочь в этом случае

В случае взлома RAID не поможет.

растолкуйте пожайлуста как организуются не сильно дорогие системы такого плана?

Резервные копии. Резервировать конфигурацию и данные. Систему устанавливать заново.

[SLEDopit]

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

[drBatty]

Установить установил, apach2+php5+mysql5, все в основном работает. Теперь начал думать о том как мне быть в случае каких то сбоев с дисками или сбоя ОС или банально взлома с какими то сильными последствиями и всякого такого...

скрипты банально find + tar, и сливаете скажем каждый день. БД - mysqldump в то время, когда никого нет. Или репликацию, и сливать оттуда, если обязательно, что-бы сервер работал 24/7.

[Gineaser]

для критически важных участков системы начал не так давно (но масштабно) использовать систему контроля версий git, развернул свой сервер на амазоне ес2 с gitolite + gitlab, и с множества своих серверов все нужные компоненты систем храню именно так.
Так же использую C3 хранилище для бэкапов с гит-сервера. Это довольно сложный вариант реализации, не сложное управление, но когда в подчинении большое количество машин с разными пулами репозитариев следить за всем достаточно сложно.
Для идентичных репозитариев использую капистрано, в качестве отличного деплоера.
А вообще простым вариантом остается все тот же sync + find + tar, как и сказал drBatty выше.
Еще для непосредственно удобного бэкапа посоветую присмотреться к утилите fsbackup - на опеннет лежит. Полностью понятное русскоязычное описание. Множество настроек.
Для более крупных возможностей можно использовать Bacula.

[SLEDopit]

А вообще простым вариантом остается все тот же sync + find + tar, как и сказал drBatty выше.

Имхо, find + tar далеко не самый лучший выход, по сравнению с инкрементальными бэкапами: гоняется слишком много лишнего трафика, необходимо много места для хранения копий за длительный период. Да и в конце концов какой смысл самостоятельно в 100500 раз изобретать велосипед?
Куда проще потратить 10-15 минут на изучение простейших rsnapshot, duplicity, etc, чем тратить дни на тестирование и дебаг собственных скриптов.

[Gineaser]

а чем sync не инкрементный бэкап? Опций достаточно что бы настроить все под свои нужды без применения софта выходящего за рамки поставки коробочного по дистрибутива.
Хотя согласен в том что лучше один раз настроить систему бэкапа, очень нравится fsbackup, чем писать, пускай элементарные и не сложные, скрипты.

[drBatty]

Имхо, find + tar далеко не самый лучший выход,

имелось ввиду find -newer last_backup. Т.е. поиск файлов, которые новее последнего архива. Такие файлы ИМХО редко встречаются.

по сравнению с инкрементальными бэкапами

tar умеет инкрементальные бекапы, кстати...

Куда проще потратить 10-15 минут на изучение простейших rsnapshot, duplicity, etc, чем тратить дни на тестирование и дебаг собственных скриптов.

от задачи зависит на самом деле.

[Sergey069]

Так выходит насколько я понял можно пользоваться

sync + find + tar

- что вроде как система зеркалирования и в архив все сливать? Или как более хороший вариант, взять какую то систему бэкапов и настроить ее как говорили: rsnapshot, duplicity + Насколько я понял mysql сливать через mysqldump и видимо через Cron или по резервного копирования это тоже умеют?
Хм, хотя может RAID с бэкапами первое время и не будет так уж актуален кажется как я думал, бэкапы похоже намного важнее.

А вот что значит

Резервные копии. Резервировать конфигурацию и данные. Систему устанавливать заново.

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

[drBatty]

- что вроде как система зеркалирования и в архив все сливать?

можно и так... Это от задачи сильно зависит. От требований.

Или как более хороший вариант, взять какую то систему бэкапов и настроить ее

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

1. Насколько я понял mysql сливать через mysqldump и видимо через Cron
2. или по резервного копирования это тоже умеют?

1. да
2. нет. Т.е. снапшот-то они вам сделают, но вот сможете-ли вы его развернуть - неизвестно. Скорее всего да. А может потребоваться mysql-repair. А последний может и не восстановить. Короче лучше так не делать. Как вариант - остановить сервер, и сделать бекап.

бэкапы похоже намного важнее.

конечно. Причём обязательно удалённые.

Можно с настроенной периодически делать какую то копию, так чтобы потом поставил с диска и с этой копии все настройки восстановил? Ну вот как то так...

можно. Но нет смысла бекапить /usr/, ведь все файлы там можно и нужно скачать из Сети. Дело в том, что разворачивание бекапа - ситуация аварийная, потому не нужно её оптимизировать. (обычно).

но просто пока банально записываю, что ставил

вы можете записывать прямо в конфигах. Можете добавить коммент #МОЯ ПРАВКА, и потом найти все свои правки командой grep 'МОЯ ПРАВКА'
Обычно этого достаточно. Впрочем можно и dvcs прикрутить.

[SLEDopit]

Насколько я понял mysql сливать через mysqldump и видимо через Cron или по резервного копирования это тоже умеют?

Нет. Тот же rsnapshot прекрасно умеет выполнить какой-нибудь скрипт до и после бэкапа на удалённой стороне. Вот эти скрипты и будут создавать mysqldump и удалять его. С точки зрения какой-нибудь безопасности так гораздо лучше.

2. нет. Т.е. снапшот-то они вам сделают, но вот сможете-ли вы его развернуть - неизвестно. Скорее всего да. А может потребоваться mysql-repair. А последний может и не восстановить. Короче лучше так не делать. Как вариант - остановить сервер, и сделать бекап.

В случае с mysql это зависит от типа движка. Myisam'y пофиг как его копировать, а вот для innodb надо надо стопорить сервер, иначе не запустится. Однако гораздо надёжнее через mysqldump. Так будет соместимость между версиями, а то изменится какая-нибудь минорная версия и бэкап превращается в кучу мусора.

[drBatty]

В случае с mysql это зависит от типа движка. Myisam'y пофиг как его копировать,

не верю. пруф можно?

Однако гораздо надёжнее через mysqldump. Так будет соместимость между версиями, а то изменится какая-нибудь минорная версия и бэкап превращается в кучу мусора.

а... я не про то - я про нарушение согласованности - бекап делается не мгновенно, и возможен случай, когда одна из таблиц будет новой, а другая - старой. Например на форуме может быть таблица топиков, и таблица постов. Сначала допустим создаётся топик, потом к нему приклеивается пост. Если первой забекапится первая таблица, то в ней ещё не будет топика, за то появится пост без топика. Как на такое отреагирует форумный движок - совершенно непонятно. Может например этот пост всем подряд во всех топиках показать. Возможны и более трагичные последствия. В самой базе есть механизм блокировок, но вот для бекапа никаких блокировок не существует.

С точки зрения какой-нибудь безопасности так гораздо лучше.

можно ещё на лету жать дамп и его шифровать. Только надо учитывать, что создание дампа - долгий процесс(иногда ОЧЕНЬ долгий, даже до нескольких дней), и сервер при создании не отвечает на запросы.

[Sergey069]

можно ещё на лету жать дамп и его шифровать. Только надо учитывать, что создание дампа - долгий процесс(иногда ОЧЕНЬ долгий, даже до нескольких дней), и сервер при создании не отвечает на запросы.

Ну может не несколько дней, но в версии alpha (даже не бета еще, пока все в процессе и вообще на денвере) база у меня 1Gb и файлы 3-5Gb, пока еще пользователей там не было даже в сети сайта нет, просто часть контента залита и еще будет немного к релизу... Вообще я рассчитываю сначала на 1Tb диск основной и 2Tb под бекапы за последнее... сколько получится, тут еще финансовый вопрос, как появяться деньги с этого конечно можно и еще добрать и хранить за последние пару месяцев все да и не поскуплюсь на что то полезное, чтобы самому спокойнее было, да и можно было реагировать на разные сложные ситуации, а пока нужно собрать первый сервак в довольно стесненных условиях...

можно и так... Это от задачи сильно зависит. От требований.

Ну вот примерно я описал масштабы, потолок я думаю 4-5Тб будет через пару лет т.к. это дело на долго и аптайм конечно 24/7, но вот останавливать сервер на сутки чтобы дамп сделать просто ппц как нежелательно, прям вообще кошмар Я бы вроде не против и сам написать скриптики, по крайней мере для меня было бы все ясно и понятно, но вот как тут быть с остановкой БД и подобным? То есть разрастется, видимо придется на ранее утро это делать часов в 5-7 утра, все либо спят либо еще не встали, да и не каждый день думаю, можно раз в 2-3 дня и при сильных изменениях на сайте так же делать бэкап

вы можете записывать прямо в конфигах. Можете добавить коммент #МОЯ ПРАВКА, и потом найти все свои правки командой grep 'МОЯ ПРАВКА'
Обычно этого достаточно. Впрочем можно и dvcs прикрутить.

Я имел ввиду правда просто списки команд в txt файле, что я ставил из софта, а вот настройки конкретно mysql, php, apach - никак не помечаю... они будут со временем еще менять как то хочется это дело все таки упростить для себя, более прозрачным и понятным что ли сделать т.к. именно администрирования - очень мало и я банально забываю что я там делал и когда, много всякого мелкого и такое не помнишь, вот и думай тут как бы все это в случае чего собрать потом в кучу.

А бэкапить я думаю /var/www/ и БД сливать дампы в отдельную папку типа mysqldb

p.s. Еще тут будет SVN и закрытый домен для тестирования и разработки т.е. по принципу этого самого SVN trunk - сама папка с проектом, а в branches - сделать разные версии, так чтобы на отдельных доменах иметь возможность их отладки, вроде как:
v1.site.ru
v2.site.ru
v3.site.ru
Правда как не таскать за собой в branches все видео/аудио/фото/архивы - не совсем понятно, изменяюсь что отвлекся просто с дампами и оно всплыло

[SLEDopit]

не верю. пруф можно?

Мда, что-то я погорячился с myisam'ом без остановки. Ссылку, к сожалению не помню. Пишут, что всё таки при обновлении записей могут возникать ошибки, но они практически всегда восстнавливаемы. Однако, это ни в какие ворота не лезет, при условии, что мы делаем бэкап.
Помню ссылку только про innodb: http://dev.mysql.com/doc/refman/4.1/en/innodb-backup.html . Но тут с остановкой, как я и писал.

Только надо учитывать, что создание дампа - долгий процесс(иногда ОЧЕНЬ долгий, даже до нескольких дней)

Ну, я ориентировался на то, что человек писал "2-3 сайта". В моей практике, это, как правило, означало что базы там небольшие. Как поазывает последний пост ТС, я ошибся. Поэтому стоит почитать доки.

[drBatty]

Ну может не несколько дней

может и несколько.

но вот останавливать сервер на сутки чтобы дамп сделать просто ппц как нежелательно, прям вообще кошмар

на 30 минут тоже иногда недопустимо. Повторяю - сделайте репликацию, останавливайте ведомый сервер. Он вроде немного места/ресурсов занимает, да и полезно для тестов.

Еще тут будет SVN

ИМХО SVN устарела. В принципе.

Поэтому стоит почитать доки.

угу. хотя и "2..3 сайта" это может быть и ОЧЕНЬ много. Кстати, mysqldump умеет по таблицам делать бекап. А таблицы делятся на три вида
1. которые почти не меняются.
2. которые почти всегда только растут.
3. которые постоянно меняются.
если п1 и п2 в большинстве, то есть смысл делать по-табличный дамп.

[Sergey069]

ИМХО SVN устарела. В принципе.

А что используют сейчас как альтернативу?

Повторяю - сделайте репликацию, останавливайте ведомый сервер. Он вроде немного места/ресурсов занимает, да и полезно для тестов.

Спс, почтал немного. Тогда в общем-то и проблема ушла получается Значит с mysql все в общем то и не так страшно оказывается, осталось только определиться чем именно дамп файлов делать и как. Хотя я правда из дискуссии пока ничего толком не понял, что же лучше... Вроде как свои скрипты под конкретный случай и не так уж и плохо тем более я могу все это сделать точно так как нужно мне, нормально будет по ftp это делать удаленно? т.е. средствами самой ОС я так делал как то раз, когда файлы перекидывал...

И на счет что с сервером я вообще не въехал т.е. с самой ОС, есть все бэкапы - сломался HDD (RAID я решил не делать), поставил Debian, поставил php+apach+mysql и вот мне нужно восстановить все настройки, поставить весь софт... просто по списку все это делается? Хотя с другой стороны без лишних заморочек и блин надежно что ли... пусть и деревянно, но он всеравно у меня один такой... я глупости говорю?

[drBatty]

А что используют сейчас как альтернативу?

DVCS - Git, Mercurial.

Значит с mysql все в общем то и не так страшно оказывается, осталось только определиться чем именно дамп файлов делать и как. Хотя я правда из дискуссии пока ничего толком не понял, что же лучше... Вроде как свои скрипты под конкретный случай и не так уж и плохо тем более я могу все это сделать точно так как нужно мне, нормально будет по ftp это делать удаленно?

по FTP вообще-говоря не нужно. Это опасно тем, что ваши бекапы могут быть
1. перехвачены.
2. злоумышленник может получить доступ к FTP

поставил Debian, поставил php+apach+mysql и вот мне нужно восстановить все настройки, поставить весь софт...

какой "весь софт"? У вас его разве много? (того, что не в репах)
а настройки восстанавливаются простым копированием. Они все лежат в /etc/. (системные).

[Sergey069]

какой "весь софт"? У вас его разве много? (того, что не в репах)

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

1. перехвачены.
2. злоумышленник может получить доступ к FTP

А как тогда их копировать?

[drBatty]

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

дык делайте свои пакеты, потом оптом всё и поставите.

А как тогда их копировать?

очевидно два варианта:
1. зашифровать на сервере открытым ключом.
2. использовать ssh. Ещё говорят можно sftp, но я не пробовал.

[Sergey069]

дык делайте свои пакеты, потом оптом всё и поставите.

Вот оно ключевое слово то! http://wiki.debian.org/DebianRussian/deb-inside
Спасибо, теперь понятно становится что и как делать, как то сначала эти пакеты кажутся сложными...

[drBatty]

Вот оно ключевое слово то! http://wiki.debian.org/DebianRussian/deb-inside

обычно хватает http://asic-linux.com.mx/~izto/checkinstall/index.php
просто собираете как и исходники, но вместо make uinstall пишете checkinstall

[SLEDopit]

поставил Debian, поставил php+apach+mysql и вот мне нужно восстановить все настройки, поставить весь софт... просто по списку все это делается?

Весь софт, имеется в виду, просто восстановить все установленные пакеты? Тогда при чём тут тогда сборка пакетов? dpkg --get-selections/--set-selections спасут мир.

Вот оно ключевое слово то! http://wiki.debian.org/DebianRussian/deb-inside
Спасибо, теперь понятно становится что и как делать, как то сначала эти пакеты кажутся сложными...

Пакеты делаются не так уж сложно и страшно, если полчаса поразбираться с устройство каталога debian и страшными командами dh_make и debuild (при наличии собственного репозитория придётся изучить и debrelease, а ещё желательно, но вовсе необязательно научиться подписывать gpg ключами файлы и прочим ненужным вещам).

обычно хватает http://asic-linux.com.mx/~izto/checkinstall/index.php
просто собираете как и исходники, но вместо make uinstall пишете checkinstall

У checkinstall'a есть ряд недостатков (обычно, они проявляются при каком-нибудь обновлении). Впрочем всё зависит от самого пакета, сервера и прочих обстоятельств. В большинстве случаев его действительно хватает.

[Sergey069]

Еще такое нашел, может будет интересно или что скажете про него
http://packages.debian.org/ru/squeeze/backup-manager
mysql умеет делать копии и простой в настроке как оказалось до безобразия, хочу на днях проверить как оно будет, надеюсь что-то получится, тем более отзывы о нем есть

хотя все они оказывается пока "системы резервного копирования", а вот чтобы распаковать потом обратно....

[drBatty]

Весь софт, имеется в виду, просто восстановить все установленные пакеты?

нет. мы обсуждаем только бекап самосборных пакетов.

хотя все они оказывается пока "системы резервного копирования", а вот чтобы распаковать потом обратно....

в идеале, случая "развернуть бекап" быть НЕ должно.

[SLEDopit]

в идеале, случая "развернуть бекап" быть НЕ должно.

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