| 1 |
1) На Gentoo Linux достаточно успешно ставится и функционирует следующий |
| 2 |
продукт: Acronis True Image Server for Linux. С его помощью я бэкаплю свой |
| 3 |
Gentoo-сервер - и все это в горячем режиме - без каких-либо перезагрузок. |
| 4 |
|
| 5 |
Разворачивать архив пробовал - все работает, ничего не падает :) |
| 6 |
|
| 7 |
2) Второй вариант - использовать Dump/Restore - если сохранять архив на |
| 8 |
другой HDD в файл - также можно делать без перезагрузки - но лучше все |
| 9 |
ключевые сервисы остановить. |
| 10 |
|
| 11 |
11.01.07, Alex Efros <powerman@××××××××××××××××××.com> написал(а): |
| 12 |
> |
| 13 |
> Hi! |
| 14 |
> |
| 15 |
> On Thu, Jan 11, 2007 at 10:18:59AM +0200, Anton Ananich wrote: |
| 16 |
> > 1) Собственно главный вопрос - в сабже :) Есть ли "серебряная пуля"? |
| 17 |
> |
| 18 |
> Смотря что именно вам нужно. Если есть возможность выключить сервер на |
| 19 |
> время бакапа, загрузиться с LiveCD и сделать dd - то это вполне себе |
| 20 |
> серебряная пуля. :) Дальше можно добавить оптимизацию для копирования |
| 21 |
> только изменившихся секторов диска и радоваться жизни. |
| 22 |
> |
| 23 |
> А в общем случае, когда сервер выключать низзя, и приложения останавливать |
| 24 |
> тоже низзя, то надёжный бакап сделать невозможно в принципе (без поддержки |
| 25 |
> со стороны бакапящихся приложений). Дело в том, что если некое приложение |
| 26 |
> начало транзакцию при работе с базой данных, и в середине этой транзакции |
| 27 |
> база была забакаплена, то после восстановления этого бакапа база окажется |
| 28 |
> в не consistent состоянии. При этом под "транзакцией" я подразумеваю не |
| 29 |
> обязательно именно транзакцию в терминах SQL, а просто последовательность |
| 30 |
> операций которые нельзя прерывать. Такой транзакцией может быть и работа с |
| 31 |
> файлами на винте в каком-нить приложении, а не с базой данных. |
| 32 |
> |
| 33 |
> И решить эту проблему невозможно никакими средствами - никакое |
| 34 |
> реплицирование базы данных или посекторное "прозрачное" дублирование |
| 35 |
> файловой системы не может _гарантировать_ что после восстановления бакапа |
| 36 |
> приложения смогут корректно работать и данные не будут повреждены. |
| 37 |
> |
| 38 |
> Конечно, можно пытаться сделать относительно надёжный бакап с помощью, |
| 39 |
> например, блокировок базы данных которые гарантируют что все текущие |
| 40 |
> SQL-транзакции завершены в момент бакапа, и прочих техник которые пытаются |
| 41 |
> оптимизировать время бакапа (чем быстрее будет бакап, тем больше |
| 42 |
> вероятность что все файлы забакаплены примерно в "один и тот же момент") |
| 43 |
> а-ля постоянный фоновый бакап изменившихся секторов диска который реально |
| 44 |
> гарантирует snapshot файловой системы на конкретный момент времени... |
| 45 |
> |
| 46 |
> Но даже при использовании таких техник бакапа необходимость молиться не |
| 47 |
> отменяется, т.к. гарантировать что всё заработает при восстановлении |
| 48 |
> бакапа всё равно нельзя ибо в системе всегда есть много транзакций которые |
| 49 |
> реализованы криво внутри приложений и не оформлены SQL-транзакциями, |
| 50 |
> состояние которых можно контролировать через базу. |
| 51 |
> |
| 52 |
> -- |
| 53 |
> WBR, Alex. |
| 54 |
> -- |
| 55 |
> gentoo-user-ru@g.o mailing list |
| 56 |
> |
| 57 |
> |
Archives