Доброго времени суток!
Имею вопрос, так что не знаю как подступиться для его решения:есть в моем ведении 2 сервера: Server и Backup. Необходимо еженощно бекапить rsync'om кучу директорий с Server'a. кынтс работает через ssh.
Мне удалось настроить беспарольный вход от имени юзера с ограниченными правами work (входит в группу Wheel, могу от имени work запускать sudo bash и я уже с root-правами)
Теперь задача эту кучу директорий забирать по rsync на Backup.
Список директорий для бэкапа:
/data - сюда по пользователь work имеет доступ чтобы синхронизировать файлы и директории с Backup.
На остальные директории он прав не имеет:
/etc
/usr/etc
/usr/local/etc
/usr/home
/usr/local/www
/usr/local/servicesНа Backup запускается команда(скрипт), которая rsync'ом копирует файлы с сервера:
что-то вроде rsync -e ssh --progress -lzuogthvr work@site.com:/data /data/site/
Но на системных директориях rsync выпадает с ошибкой "нет такого файла"или "файл не найден".вопрос: как выкрутиться из этой ситуации? Как сделать так чтобы rsync работал в пакетном режиме, не интерактивно?
не прописывать же по всем директориям доступ для юзера work?
И не заходить по ssh от root - это тоже приемлемо.Надеюсь я доступно изложил мой вопрос, если что не понятно, готов прояснить.
спасибо.
> Доброго времени суток!
> Имею вопрос, так что не знаю как подступиться для его решения:
> есть в моем ведении 2 сервера: Server и Backup. Необходимо еженощно бекапить
> rsync'om кучу директорий с Server'a. кынтс работает через ssh.Посмотри на Dirvish. Это Rsync basded backup solution. Используем в продакшене уже больше 5 лет.
>> Доброго времени суток!
>> Имею вопрос, так что не знаю как подступиться для его решения:
>> есть в моем ведении 2 сервера: Server и Backup. Необходимо еженощно бекапить
>> rsync'om кучу директорий с Server'a. кынтс работает через ssh.
> Посмотри на Dirvish. Это Rsync basded backup solution. Используем в продакшене уже
> больше 5 лет.о, что-то новое и rsync-based. надо заценить тех возможности.
А почему нельзя запускать не на Backup, а на Server что-нибудь типа
rsync -e ssh -ztr.... /data user@Backup:/data ?
Тогда вроде бы проблемы такой и не возникнет.
> А почему нельзя запускать не на Backup, а на Server что-нибудь типа
> rsync -e ssh -ztr.... /data user@Backup:/data ?
> Тогда вроде бы проблемы такой и не возникнет.Мое имхо говорит мне что более правильно таки такие скрипты запускать на бэкап-машине а не на бэкапируемом хосте.
Не вижу проблемы со входом под рутом по ключу.PermitRootLogin without-password или как-то так опция зовется, не помню, по памяти пишу.
Смотрю в сторону dirvish-а, как он организован....
В нем есть то, о чем я размышлял когда-то... В настоящее время - bontmia, несколько "пропатченная", но pre и post скриптов еще не изобрел. буду смотреть как сделан дирвиш.
> Не вижу проблемы со входом под рутом по ключу.
> PermitRootLogin without-password или как-то так опция зовется, не помню, по памяти пишу.Если я правильно понял, вы говорите о настройках sshd? можно поподробнее?
> Смотрю в сторону dirvish-а, как он организован....
> В нем есть то, о чем я размышлял когда-то... В настоящее время
> - bontmia, несколько "пропатченная", но pre и post скриптов еще не
> изобрел. буду смотреть как сделан дирвиш.да занятная штучка... вот только сомневаюсь подойдет ли она в моем случае...
Server находится в Питере, Backup в Новосибирске...
>> Не вижу проблемы со входом под рутом по ключу.
>> PermitRootLogin without-password или как-то так опция зовется, не помню, по памяти пишу.
> Если я правильно понял, вы говорите о настройках sshd? можно поподробнее?PermitRootLogin
Specifies whether the root can log in using ssh(1). The
argument must be yes, without-password, forced-
commands-only, or no. without-password means that root
cannot be authenticated using the "password" or
"keyboard-interactive" methods (see description of
KbdInteractiveAuthentication above).
>> Смотрю в сторону dirvish-а, как он организован....
>> В нем есть то, о чем я размышлял когда-то... В настоящее время
>> - bontmia, несколько "пропатченная", но pre и post скриптов еще не
>> изобрел. буду смотреть как сделан дирвиш.
> да занятная штучка... вот только сомневаюсь подойдет ли она в моем случае...
> Server находится в Питере, Backup в Новосибирске...Дирвиш умеет бекапить только измененные файлы. Этим оно и отличается от полного пофайлового бекапа. Если initial бэкап у нас занимал 4 часа, то второй -- 20-30 минут.
У меня сервер находится в питере, а бекап в Калифорнии. :-)
> PermitRootLogin
> Specifies whether the root can log in using ssh(1). The
> argument must be yes, without-password, forced-
> commands-only, or no. without-password means that root
> cannot be authenticated using the "password"
> or "keyboard-interactive" methods (see description
> of KbdInteractiveAuthentication above).вот тут мне не понятно: с одной стороны рутом на удаленный сервер нежелательно
предоставлять доступ по ssh (у нас он отключен).
С другой - вроде как надо.вопрос: а можно ли обойти этот скользкий момент с помощью sudoers?
> Дирвиш умеет бекапить только измененные файлы. Этим оно и отличается от полного
> пофайлового бекапа. Если initial бэкап у нас занимал 4 часа, то
> второй -- 20-30 минут.если я правильно понимаю, то любая rsync-based утилита будет так работать, если без наворотов.
Да и вопрос о правах пользователя группы wheel на системные директории остается повисшим.
Пока что-то не представляю как Dirvish решит этот вопрос...
>[оверквотинг удален]
>> Specifies whether the root can log in using ssh(1). The
>> argument must be yes, without-password, forced-
>> commands-only, or no. without-password means that root
>> cannot be authenticated using the "password"
>> or "keyboard-interactive" methods (see description
>> of KbdInteractiveAuthentication above).
> вот тут мне не понятно: с одной стороны рутом на удаленный сервер
> нежелательно
> предоставлять доступ по ssh (у нас он отключен).
> С другой - вроде как надо.Тут можно разрешить ходить рутом только с определенного хоста, и ключ залочить на определенный хост. ну можно еще firewall-ом зафильтровать.
> вопрос: а можно ли обойти этот скользкий момент с помощью sudoers?
теоретически да, но практически будет тяжело и смысла иметь не будет.
>> Дирвиш умеет бекапить только измененные файлы. Этим оно и отличается от полного
>> пофайлового бекапа. Если initial бэкап у нас занимал 4 часа, то
>> второй -- 20-30 минут.
> если я правильно понимаю, то любая rsync-based утилита будет так работать, если
> без наворотов.Да. Дирвиш -- это просто фрэмворк вокруг rsync.
> Да и вопрос о правах пользователя группы wheel на системные директории остается
> повисшим.Объясни, что ты имеешь ввиду. если ты на удаленный хост заходишь root-ом, то автоматом и в группе wheel.
>>[оверквотинг удален]
>> вот тут мне не понятно: с одной стороны рутом на удаленный сервер
>> нежелательно
>> предоставлять доступ по ssh (у нас он отключен).
>> С другой - вроде как надо.
> Тут можно разрешить ходить рутом только с определенного хоста, и ключ залочить
> на определенный хост. ну можно еще firewall-ом зафильтровать.нет. Это не подойдет - разработчики ходят на сервак с кучи айпи адресов, кто-то с динамического пулла... дохлый номер всех отлавливать - ибо всегда будут обделенные :-)
>> Да и вопрос о правах пользователя группы wheel на системные директории остается
>> повисшим.
> Объясни, что ты имеешь ввиду. если ты на удаленный хост заходишь root-ом,
> то автоматом и в группе wheel.вот почему спросил:
логин на Server (смотри первый пост) по ssh делается от имени work (состоит в группе wheel). следовательно, если заходишь как work надо получить рутовые права. Это можно сделать интерактивно - sudo bash, например. А вот как в пакетном режиме?
>>>[оверквотинг удален]
> нет. Это не подойдет - разработчики ходят на сервак с кучи айпи
> адресов, кто-то с динамического пулла... дохлый номер всех отлавливать - ибо
> всегда будут обделенные :-)Это тоже решается. опять же preshared keys.
> вот почему спросил:
> логин на Server (смотри первый пост) по ssh делается от имени work
> (состоит в группе wheel). следовательно, если заходишь как work надо получить
> рутовые права. Это можно сделать интерактивно - sudo bash, например. А
> вот как в пакетном режиме?Нужно курить маны в эту сторону:
rsync -av --rsync-path='sudo rsync' remote:dir .
но sudo должно быть NOPASSWORD
>> Не вижу проблемы со входом под рутом по ключу.
>> PermitRootLogin without-password или как-то так опция зовется, не помню, по памяти пишу.
> Если я правильно понял, вы говорите о настройках sshd? можно поподробнее?
>> Смотрю в сторону dirvish-а, как он организован....
>> В нем есть то, о чем я размышлял когда-то... В настоящее время
>> - bontmia, несколько "пропатченная", но pre и post скриптов еще не
>> изобрел. буду смотреть как сделан дирвиш.
> да занятная штучка... вот только сомневаюсь подойдет ли она в моем случае...
> Server находится в Питере, Backup в Новосибирске...debian:~# cat /etc/ssh/sshd_config |grep oot
PermitRootLogin without-password
Содержимое authorized_keys:
from="1.2.3.4" no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-dss AAAAB3Nz....[продолжение ключа]
> А почему нельзя запускать не на Backup, а на Server что-нибудь типа
> rsync -e ssh -ztr.... /data user@Backup:/data ?
> Тогда вроде бы проблемы такой и не возникнет.Потому что:
1. Идеологически бэкап-задачи выполняются на резервном хосте. Да и продакшн сервер не хотелось бы грузить лишним функционалом.
2. организовано так, что Server - находится на арендуемом сервере у хостера. Backup - в серверной, в офисе. Чтобы заставить Server отправлять бэкапы на Backup, надо будет использовать нестандартные порты для работы rsync, ssh (так как стандартые уже заняты). А лишние действия - они лишние.
>> А почему нельзя запускать не на Backup, а на Server что-нибудь типа
>> rsync -e ssh -ztr.... /data user@Backup:/data ?
>> Тогда вроде бы проблемы такой и не возникнет.
> Потому что:
> 1. Идеологически бэкап-задачи выполняются на резервном хосте. Да и продакшн сервер не
> хотелось бы грузить лишним функционалом.
> 2. организовано так, что Server - находится на арендуемом сервере у хостера.
> Backup - в серверной, в офисе. Чтобы заставить Server отправлять бэкапы
> на Backup, надо будет использовать нестандартные порты для работы rsync, ssh
> (так как стандартые уже заняты). А лишние действия - они лишние.Поддерживаю.
Любой бэкап -- это дырка в безопасности. Тут выгоднее делать pull (инициировать бекап с бекапного сервера). Да и не продакшен хосте держать ключи для доступа куда-то внутрь идеологически неверно.
Но можно и rsync-ом (over ssh+preshared keys) делать то-же самое.
rsync -zavHessh host:/fs /localdir/
Дирвиш еще умеет бекапить только измененные файлы и делать хардлинки на уже существующие файлы если они не менялись.
вот примерно такой командой:
ACTION: rsync -vrltH --delete -pgo --stats -S -D --numeric-ids -x --exclude-from=/backup/bank0/root/2010-10-13/exclude --link-dest=/backup/bank0/root/2010-10-12
/tree /snapshot/root/ /backup/bank0/root/2010-10-13/tree