Пингвинья резервация

Alexander S. Salieff

Спецвыпуск: Хакер, номер #062, стр. 062-066-3

$> tar -zc -f - srcdir | ssh -C dstuser@dsthost.ru "cat > /home/dstuser/mybackup.tar.gz"

Если вдруг на хосте-хранилище не окажется возможности поднять SSH-сервер, хранилище может самостоятельно инициировать создание резервной копии в обратном порядке и принять ее на себя (вместо cat можно использовать dd, в качестве входного файла по умолчанию — stdin):

dsthost$> ssh -C srcuser@srchost "tar -zc -f - srcdir" | dd of=/home/dstuser/mybackup.tar.gz

Однако предыдущая схема предпочтительнее в плане безопасности, так как srcuser'у могут требоваться достаточно большие привилегии (для того чтобы бэкапить некоторые данные), в то время как dstuser практически во всех случаях имеет шансы остаться бесправным на своей машине. Ясно, что подобное использование SSH-сессии в качестве транспорта распространяется не только на архиваторы, но и на любые рассмотренные мной утилиты. К примеру, dd по умолчанию сливает данные в stdout. Осталось только перенаправить:

$> dd if=/dev/cdrom bs=2048 | ssh -C dstuser@dsthost.ru "dd of=/home/dstuser/mycd.iso"

Наши занятия выглядели весьма пристойно, пока мы работали руками. Только проявится автоматизация, сразу же возникнет вопрос: «Кто будет вводить пароли?» Чтобы вопроса даже не возникало, я сгенерю пару ключей:

$> ssh-keygen -t rsa

Утвердительно отвечаем на все вопросы и вводим пустую passphrase два раза, чтобы не вводить ее в качестве пароля (тем не менее, мы хорошо защищены асинхронным криптоалгоритмом, ключи для которого были сгенерированы только что). Затем кладем публичный ключ на удаленную машину:

$> cat ~/.ssh/id_rsa.pub | ssh dstuser@dsthost "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"

В ходе этой процедуры мы ввели пароль в последний раз, больше не потребуется. Обращаю особое внимание на смену прав на публичный ключ и каталог, содержащий его на стороне сервера. sshd — умный демон, и если доступ к публичному ключу получит кто-нибудь, кроме соответствующего пользователя, пользоваться ключом станет невозможно.

Итак. Довольно подробно мы рассмотрели аспекты, пригодные для создания автоматизированных скриптов, использующих в качестве сетевого транспорта SSH-сессию.

Rsync — сага об инкрементальности

Системы, созданные нами выше, хороши всем за исключением одного аспекта: они перегоняют все данные из источника в хранилище независимо от необходимости в этом. Безусловно, неблагоприятный фактор. Ни с точки зрения скорости создания бэкапа, ни в плане использования трафика в случае с удаленным хранилищем. Чтобы оптимизировать подобные ситуации, применяют схему инкрементального копирования (позволяет передавать только изменившиеся данные) и не трогают те, которые не менялись с прошлого «раза».

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