Для удобного управления бэкапами портала было принято решение использовать для этого систему контроля версий и групповой разработки под названием svn.
Важной задачей, которую она решает является создание инкрементальных бэкапов директории портла с максимальным удобством для администратора.
Замечание: портал состоит из файлового архива и базы данных. В базе данных фиксируются любые изменения на портале, в файловом архиве - изменения в загружаемых файлах (картинки, рабочие документы). Для корректного сохранения изменений следует отслеживать обе эти составляющие.
Принято решение создать папку в корне сайта с запретом к ней доступа для веб-сервера (владелец директории - root), в которой будет постоянно обновляться дамп БД и соответственно заливаться в svn вместе со всеми изменениями в файловом архиве.
Доступ к svn решено сделать локальным, т.е. только с рабочей машины. Для такого типа доступа нет необходимости в какой-либо настройки сервера svn, можно сразу приступать к работе.
Создаем директорию-хранилище для svn.
Говорим серверу что мы создали новое хранилище.
Заливаем все файлы первично в хранилище (инициализируем его)
В конце мы должны получить сообщение типа
Если возникли проблемы - следует обратиться к тематическим сайтам.
Единственное, что могу порекомендовать - это если после миграции с Windows возникла ошибка типа
т.е. с кодировкой, то просто svn повстречал файлы с именами, созданными в кодировке cp1251 (т.е. русские имена).
Варианты решения - удалить их, переименовать латинскими буквами (но если файлы используются порталом, то нужно будет отыскать все связи и тоже их переименовать), либо воспользоваться утилитой для перекодировки наименований файлов.
Итак, svn успешно создала ревизию. Теперь наша задача извлечь оттуда эту ревизию в рабочую директорию, чтобы появились связи файлов с svn, и в дальнейшем система делала только инкрементальные снимки.
Теперь по использованию.
Создадим новую директорию и устанавливаем на нее права только для администратора linux, чтобы она не была доступна через сайт
Ну и каждый раз будем создавать туда бэкап БД
Все просто, пока подразумеваем, что разработка ведется только в trunk (корневой ветке).
Поэтому в качестве вечернего бэкапа мы вызываем из корневой директории сайта команду рекурсивного обхода директории и метки всех новых файлов и папок. Она помечает новые файлы для последующей загрузки их в хранилище
И затем добавляем все сделанные измениния в хранилище
По завершении операции будет указано что все прошло успешно и увеличен номер ревизии
P.S. svn хранит снимок директории в виде бинарного файла.
Единственным минусом использования этой системы является то, что в каждую директорию она добаляет катлог .svn размером 40Кб. Но в сумме объем извлеченной из svn директории больше оригинала на 2 Гб (40Кб х 50 000 директорий). Хотя это по идее компенсируется инкрементальностью бэкапов.
Важной задачей, которую она решает является создание инкрементальных бэкапов директории портла с максимальным удобством для администратора.
Замечание: портал состоит из файлового архива и базы данных. В базе данных фиксируются любые изменения на портале, в файловом архиве - изменения в загружаемых файлах (картинки, рабочие документы). Для корректного сохранения изменений следует отслеживать обе эти составляющие.
Принято решение создать папку в корне сайта с запретом к ней доступа для веб-сервера (владелец директории - root), в которой будет постоянно обновляться дамп БД и соответственно заливаться в svn вместе со всеми изменениями в файловом архиве.
Доступ к svn решено сделать локальным, т.е. только с рабочей машины. Для такого типа доступа нет необходимости в какой-либо настройки сервера svn, можно сразу приступать к работе.
Создаем директорию-хранилище для svn.
root@bitrixvm:/# cd /var root@bitrixvm:/var# mkdir svn root@bitrixvm:/var# mkdir svn/www root@bitrixvm:/var# mkdir svn/www/trunk |
Говорим серверу что мы создали новое хранилище.
root@bitrixvm:/var# svnadmin create /var/svn/www/trunk |
Заливаем все файлы первично в хранилище (инициализируем его)
svn import -m "Bitrix portal" /var/www file:///var/svn/www/trunk |
В конце мы должны получить сообщение типа
Transnitted revision 1 |
Если возникли проблемы - следует обратиться к тематическим сайтам.
Единственное, что могу порекомендовать - это если после миграции с Windows возникла ошибка типа
UTF-8 sequence |
т.е. с кодировкой, то просто svn повстречал файлы с именами, созданными в кодировке cp1251 (т.е. русские имена).
Варианты решения - удалить их, переименовать латинскими буквами (но если файлы используются порталом, то нужно будет отыскать все связи и тоже их переименовать), либо воспользоваться утилитой для перекодировки наименований файлов.
#apt-get install convmv #convmv -f cp1251 -t utf-8 --notest * |
Итак, svn успешно создала ревизию. Теперь наша задача извлечь оттуда эту ревизию в рабочую директорию, чтобы появились связи файлов с svn, и в дальнейшем система делала только инкрементальные снимки.
root@bitrixvm:/var# mv /var/www /var/www_backup root@bitrixvm:/var# mkdir /var/www root@bitrixvm:/var# svn co file:///var/svn/www/trunk www/ |
Теперь по использованию.
Создадим новую директорию и устанавливаем на нее права только для администратора linux, чтобы она не была доступна через сайт
root@bitrixvm:/var/www# mkdir db_backup root@bitrixvm:/var/www# chmod 700 db_backup |
Ну и каждый раз будем создавать туда бэкап БД
mysqldump --opt sitemanager > sitemanager.sql |
Все просто, пока подразумеваем, что разработка ведется только в trunk (корневой ветке).
Поэтому в качестве вечернего бэкапа мы вызываем из корневой директории сайта команду рекурсивного обхода директории и метки всех новых файлов и папок. Она помечает новые файлы для последующей загрузки их в хранилище
root@bitrixvm:/var/www# svn add * --force |
И затем добавляем все сделанные измениния в хранилище
root@bitrixvm:/var/www# svn commit -m "Backup db and file backup 28_10_10" |
По завершении операции будет указано что все прошло успешно и увеличен номер ревизии
Committed revision 2. |
P.S. svn хранит снимок директории в виде бинарного файла.
Единственным минусом использования этой системы является то, что в каждую директорию она добаляет катлог .svn размером 40Кб. Но в сумме объем извлеченной из svn директории больше оригинала на 2 Гб (40Кб х 50 000 директорий). Хотя это по идее компенсируется инкрементальностью бэкапов.