В первой части было показано как установить сервер backuppc. Во второй части я покажу на примере одного unix сервера как подключать машины к backuppc. Если при настройке конфигурации через web интерфейс у вас возникли проблемы, посмотрите еще раз первую часть, там у конце статьи есть решения возможных проблем..
Сервер backuppc позволяет бэкапить компьютеры используя методы:
- archive – бэкап на внешний носитель ленточный или CD, DVD
- rsync – бэкап и восстановление через команду rsync, при этом используется ssh или rsh соединения с бэкапируемой машиной
- rsyncd – бэкап и восстановление через rsync демон на клиентских хостах. Т.е rsyncd должен постоянно работать на бэкапируемых машинах.
- tar – бэкап и восстановление через архиватор tar. Архивация при этом происходит через ssh, rsh или nfs
- smb – бэкап и восстановление через smbclient, используя SMB протокол. Используется для бэкапа windows машин.
Для бэкапа и восстановления unix машин самым лучшим методом является rsync метод. В дальнейшем речь пойдет о его настройке.
Итак, заводим новый хост. Выбираем Edit Hosts, нажимаем кнопочку Add и забиваем имя нового хоста и пользователя от которого будем делать бэкапы. После каждого изменения конфигурации в web интерфейсе не забываем сохранять конфигурацию. Для этого нажать на кнопку Save.
Прежде чем продолжить дальше, сначала надо настроить аутентификацию между хостом и сервером backuppc. Ведь, чтобы забрать или восстановить файлы надо установить соединение. Мы будем использовать беспарольное соединение ssh по ключам как наиболее безопасное, плюс настройка конфигурации sudoers на клиенте (в дальнейшем термин клиент это тот кого мы бэкапим, а сервер это наш backuppc).
Первым делом проверяем, чтобы на всех наших unix клиентах были установлены ssh сервер, программы rsync и sudoers. На машине с backuppc требуется, чтобы были установлены ssh и rsync.
В конфигурационный файл sudoers на клиентах добавляем следующую строку.
mik ALL = NOPASSWD: /usr/bin/rsync
Это означает, что пользователю mik (это тот пользователь, которого мы указали при заведении хоста), разрешается запускать команду rsync (путь до rsync поставите свой). Объясню для чего это мы делаем. Ведь пользователь mik не обладает всеми привилегиями root, например забэкапить /root каталог просто так не удастся. А если запускать rsync через sudo то доступ будет во все каталоги. В принципе можно этого не прописывать, если будем бэкапить клиентов от пользователя root, но хочу заметить, что пользователю root по умолчанию запрещено соединяться по ssh с хостами.
А теперь большое предупреждение. Ограничьте на эту машину доступ по ssh как можно с меньшего количества компьютеров, а пароль mik придумайте посложнее. Ведь если кто-то узнает пароль от mik, то командой rsync с привилегиями root можно вытащить всю информацию с компьютера или закачать на него любые программы. Всегда помните об этом!
Генерируем пару ключей для беспарольного ssh соединения и выполнять это лучше от пользователя mik. Генерировать можно либо на сервере, либо на клиенте, это значения не имеет. Парольную фразу не указываем, нажимаем Enter.
mik@gw:~$ ssh-keygen -t dsa -b 1024 -f /home/mik/gw-key
Generating public/private dsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/mik/gw-key.
Your public key has been saved in /home/mik/gw-key.pub.
The key fingerprint is:
7e:81:11:14:c6:c6:ba:ed:f7:67:ce:e7:52:32:5f:06 mik@gw
The key's randomart image is:
+--[ DSA 1024]----+
| +=. |
| .+. |
| o. |
| . o E |
| oS . . |
| ... . o +|
| .. . *.|
| ... .+ o|
| . ..+o+.|
+-----------------+
Получаем два файла gw-key и gw-key.pub. PUB ключ, это публичный, для клиентских машин, а другой это секретный, для сервера backuppc. Теперь на клиентах в конфигурации ssh сервера (файл /etc/ssh/sshd_config) раскомментировать строки
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PermitRootLogin no
PermitEmptyPasswords no
Обязательно перезапустить сервер ssh, можно использовать команду
#killall -HUP /usr/sbin/sshd
Возвращаемся к нашим файлам-ключам. Переименовываем ключ gw-key.pub в файл authorized_keys с правами 600 и кладем его в папочку /home/mik/.ssh. Если папки .ssh нет, то создаем и выставляем на нее разрешение 700. Владельцем папки .ssh и файла authorized_keys должен быть mik. От пользователя mik на клиенте выполняем
mik@gw:~$ mkdir /home/mik/.ssh
mik@gw:~$ chmod 700 /home/mik/.ssh
mik@gw:~$ chmod 600 /home/mik/.ssh/authorized_keys
Второй файл-ключ для сервера – gw-key надо аналогичным выше способом разместить в каталоге .ssh пользователя nobody на сервре backuppc. Владельцем всех папок и файлов должен быть nobody!
root@m1k:~# cd /mnt/backup/BackupPC/
root@m1k:/mnt/backup/BackupPC# mkdir .ssh
root@m1k:/mnt/backup/BackupPC# копируем файл gw-key в папку .ssh
root@m1k:/mnt/backup/BackupPC# chown -R nobody:nogroup ./.ssh
root@m1k:/mnt/backup/BackupPC# chmod 700 ./.ssh
root@m1k:/mnt/backup/BackupPC# chmod 600 ./.ssh/gw-key
Пробуем соединиться с сервера backuppc на наш клиентский компьютер gw через ключи ssh. Для этого становимся пользователем nobody и набираем команду ssh -i /mnt/backup/BackupPC/.ssh/gw-key mik@gw. После подтверждения yes, что хотим работать с этим хостом должны сразу безо всяких паролей соединиться с удаленным компьютером gw
root@m1k:~# su nobody
nobody@m1k:~# ssh -i /mnt/backup/BackupPC/.ssh/gw-key mik@gw
The authenticity of host '[gw]:22 ([192.168.0.1]:22)' can't be established.
RSA key fingerprint is be:68:fe:64:bb:62:d6:d8:a9:62:3e:76:17:85:76:94.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[gw]:22,[192.168.0.1]:22' (RSA) to the list of known hosts.
Last login: Thu Jul 22 11:12:22 2010 from mik.localhost
Linux 2.6.29.6-gw-smp.
mik@gw:~$
Возвращаемся к web интерфейсу backuppc. Выбираем наш новый хост -gw и делаем EditConfig. Задаем в настройках Xfer метод бэкапа -rsync, кодировку клиента (чтобы русские названия файлов и каталогов корректно отображались), путь до локального расположения rsync, папки, которые хотим бэкапить (/root), ну и самое главное строку бэкапа и восстановления. Строка у нас должна получиться примерно такая (она одинакова для бэкапа и восстановления):
$sshPath -i /mnt/backup/BackupPC/.ssh/gw-key -l mik $host /usr/bin/sudo $rsyncPath $argList+
Пути до файлов gw-key и sudo, (который на клиенте) подставьте свои. Переменные лучше не трогать. Не забываем нажать кнопку Save.
Вот и вся основная настройка, можно пробовать запускать первый полный бэкап в главном меню gw-Home.
В Host Summary должно отобразиться что процесс пошел и закончился
Теперь можно смотреть на содержание файлов забэкапленной папки /root в Browse backups хоста gw.
Можно попробовать восстановить или сохранить себе на диск какой нибудь не очень нужный файл. В принципе это основная настройка. В остальном совсем просто разобраться, да и по умолчанию в сервере backuppc заданы приемлемые настройки по умолчанию. Рекомендую только прописать ваш email, чтобы в случае каких нибудь проблем к вам приходила почта (но это будет работать только когда у вас настроен и запущен почтовый сервер в вашей сети).
Возможные проблемы при создании бэкапа.
Я специально повторил путь установки и настройки на одной из моих unix машин. Единственная проблема, которая возникла при бэкапе, это отсутсвие модуля File::RsyncP. Полный бэкап у меня сразу делаться отказался и появилась такая ошибка
После установки пакета File-RsyncP версии 0.68 все заработало.
Классная статья! Автору спасибо! Мне очень помогла.
Ставил на debian 5.0.6. Возник правда заглюк. Не хотела работать.
Пришлось зайти пользователем по ssh что-бы ответить yes. После этого все заработало.
Спасибо за отзыв! Про это в статье написано, что перед тем как заносить команды в интерфейс backuppc надо вручную пройтись ssh доступом от пользователя backuppc на все машины. Это пропишет в файл ~.ssh/known_hosts ip удаленного сервера и его ключ..
И еще, если по каким-то причинам вы переделали ключ у машины которую бэкапите (например переустановили), то процедуру входа по ssh надо повторить, а перед этим из файла known_hosts удалить строку относящейся к этому хосту.
Несовсем понятно откуда появился /mnt/backup/BackupPC ?
>> аналогичным выше способом разместить в каталоге .ssh пользователя nobody на сервере backuppc
У Вас я так понимаю ключи лежат в /mnt/backup/BackupPC ?
Прочитайте первую часть статьи, там сказано что директорию /mnt/backup/BackupPC мы создали сами, а пользователю nobody прописали эту директорию как домашнюю.
Да ключи лежат в директории /mnt/backup/BackupPC/.ssh
не подскажете , есть ли возможность делать два backup-задания для одного хоста ?
вопрос интересный 🙂 никогда такого не надо было.. могу ошибаться но в стандартных настройках я такого не видел.
Можно “обмануть” программу добавив еще один хост. А в DNS записях на новый хост сослаться на первый хост.
Ключи можно не генерировать а сделать все под копирку с первого задания.
В общем как выход из положения..
Забавно. Есть мысль использовать 2 разных XferMethod для одного хоста , попробую..
Поставил и пожалел потеряного времени. Это *** хранит всё что забакаплено в открытом виде в своём каталоге. Ни сжатия, ничего. Зачем вообще это нужно, такое резервное копирование? Просто делайте копии через scp – тоже самое
Виктор, наверное вы не до конца разобрались в настройках программы. Степень сжатия файлов настраивается. Действительно можно и без сжатия архивы делать. А в отличие от scp у backuppc есть инкрементальное копирование, которое очень выгодно экономит место и раскладывает все по временным полочкам.