Pull to refresh

Comments 14

Акцент не на то. Как положить на место бэкап — это просто. Куда сложнее положить на место то, что нужно в консистентной форме. И ещё сложнее проверить, что оно туда легло, что оно там целиком, консистентное и не протухшее.

PS Что касается переноса бэкапов, ничего удобнее NFS пока не придумали. Подмонтировал — и копируй. Для параноиков есть IPSec.
UFO just landed and posted this here
Во-первых есть fuse, во-вторых, с вопросы бэкапа должен решать таки администратор. Времена унылого хостинга в уголке бзди плавно уходят (openvz/xen этому сильно помогает).
Очень советую уменьшить приоритет процесса архивирования. Ибо если ваш сервер что то делает, то без этого на время архивации(которое может быть весьма продолжительным) там все остальное сдохнет напрочь.
Как нибудь так например:

ssh $DST_LOGIN@$DST_IPADDR 'nice -n 15 tar -zcvf '$TMPDIR$DST_IPADDR'_'$timestamp'.tar.gz '$BACKUPDIRS || err «Remote connection failed»
expect "assword:"
А что за «жопослово» ожидает сервер?
Если вы заметили то это не в одном месте… Синтаксис правильный, почитайте про tcl, expect.
В данном случае это означает что комада «ожидает» строчку которая заканчивается на эти символы. Почему именно «assword» — первая буква может быть большой или маленькой, поэтому проще ее отбросить
Также и потому что «assword» должно быть окончанием строки. В нашем случае если мы укажем «password» — то это может совпасть не с окончанием а с полностью строкой респонса сервера (а не с окончанием) и будет ошибка скрипта.
да это всё понятно. Просто забавно. Почему не «sword:»? Более благородно.
:)) увеличиваем вероятность совпадения с нужным словом, за счет потери красивости :)
Как-то неправильно что-ли. Слишком много телодвижений. Создается аж 3 сессии ssh поочередно. Куда удобнее запускать скрипт с бэкапом на том сервере, откуда надо сделать бэкап, сделать там локальный бэкапчик такой, а потом воспользоваться rsync'ом, чтобы засинхронизировать бэкапы с бэкап-сервером, используя тот же ssh.

К примеру бэкап домиков пользователей

#!/bin/sh
backup_dir="/var/backup";
BACKUP_DAY=`date +%Y-%m-%d`;
mkdir -p $backup_dir/${BACKUP_DAY}
ROOTDIR="/home"
HOMEDIRS="user1 user2 user3"

export HOME=/root
export LC_ALL=C
export LC_TIME=C

TIME=`date +%H-%M-%S`
set $(date);
umask 077

for DIR in $HOMEDIRS; do
  BACKUP="$backup_dir/${BACKUP_DAY}/${DIR}_${TIME}";
  /bin/tar -cjpf ${BACKUP}.tar.bz2 -C ${ROOTDIR} ${DIR}
  /usr/bin/find $backup_dir -type d -ctime 15 |xargs rm -r
done                                                                                                                                                                                                                                         
                                                                                                                                                                                                                                             
/usr/local/bin/rsync -rtlvzplogbDH $backup_dir backup.somewhere.ru:/backup/users.server.ru --progress


Скрипт выполняется по крону раз в сутки (можно чаще). В результате — две копии бэкапа за последние 15 дней (нормальный срок, чтобы восстановиться в случае потери данных), лежащие в директориях с именами, обозначающими время бэкапа. Первый — собственно на сервере, откуда делается бэкап, второй — на бэкап-сервере. Данные гоняются по защищенному ssh с помощью rsync, новые файлы добавляются и старые удаляются в одной сессии.
Да возможно ваш метод быстрее. Я постарался показать основные принципиальные методики именно удаленного бекапа с максимальной централизацией на главном сервере, которые уже можно развить и улучшить.
UFO just landed and posted this here
Кто сказал, что на удаленный сервер надо логиниться под рутом. Настройку ssh еще никто не отменял.

# cat /root/.ssh/config

Host backup.somewhere.ru
User backup
Hostname x.x.x.x #(здесь IP)
IdentityFile /root/.ssh/rsync.key
....

В самом начале первого метода идет ссылка на статью по настройке ssh-доступа, в которой это, кстати, есть.
Sign up to leave a comment.

Articles