Синхронизатор SugarSync. Как обойтись без Linux-клиента

Одним из сервисов, без которого мне уже трудно представить свою работу, да и компьютерную жизнь вообще, является Dropbox. Он прекрасно справляется с синхронизацией моих документов некоторых других файлов между тремя компам - рабочей и домашней станцией, а также ноутбуком. У этого сервиса огромное множество преимуществ. Главное - это наличие нормального клиента для всех популярных операционных систем. Да и бесплатность 2 гигов синхронизируемых данных тоже большой плюс. Но есть мелкие минусы. В частности, это синхронизация только одной своей директории и всех вложенных в нее папок и файлов. Поэтому, я организовал на всех компах сохранение файлов именно в эту директорию. Ну и 2 гига, по нынешним меркам, это не так уж и много.

Но есть и другие подобные сервисы. В частности это SugarSync. Фактически это тоже онлайновое хранилище личных файлов с возможностью синхронизации их между любыми устройствами. По многим параметрам он обходит своего старшего товарища - DropBox. Вот здесь приводится сравнительная таблица различных сервисов синхронизации. SugarSync на общем фоне выглядит лидером. Важно, что работы с имеется и программа-клиент. Есть версии для Windows, Mac, Android, iPhone, Symbian. А вот для Linux нет. Пока нет. Учитывая, что Android клиент существут, осмелюсь предположить, что вскоре появится и клиент для Linux на которой Android и основан. Фактически, это единственный минус SugarSync. Ведь при бесплатном использовании вы получаете 5 Гб для хранения файлов. Более того, этот объем можно увеличить за счет реферальной программы. То есть, если вы пришли по моей реферальной ссылке и зарегистрировались, то и мне и вам добавляется еще 500 Мб дискового пространства. Поэтому я зарегистрировался, по началу просто на перспективу в ожидании Linux-клиента. Если интересно, то вот моя реферальная ссылка. Или дайте свой e-mail и я прямо из программы вышлю ссылку для регистрации.

Но дальше оказалось, что ничего ждать не надо!!! При регистрации на сайте проекта одним из этапов является загрузка клиента под Windows или другую ОС. Я качнул себе виндовую версию и чуть про не не забыл. Но потом вдруг решил попробовать установить программу в Wine. Опыт прошел с потрясающим результатом. Программа не только установилась и запустилась, но она еще и интегрировалась в мою Ubuntu 10.10. В общем выглядело это так...

Кликаем правой кнопкой на инсталляционный файл и выбираем запуск с помощью Wine. И вот оно окно установки. Жмем традиционное виндовое Next.

Clonezilla - клонируем диски бесплатно и эффективно

Иногда вощзникает дикое желание сохранить копию всей ситсемы в данной конфигурации, либо перенести ее на аналогичный компьютер минуя процесс стандартной установки и настройки. Как это сделать расказывается в приведенной ниже статьье, взятой отсюда:
Clonezilla - клонируем диски бесплатно и эффективно « It_blog's

Всем привет!
Сейчас у меня сессия в институте, поэтому статьи пишу по реже.

Сегодня решил познакомить Вас, уважаемые читатели с проектом Clonezilla

Вот выдержка из оф.сайта, о возможностях дистрибутива:

* Free (GPL) Software.
* Filesystem supported: ext2, ext3, reiserfs, xfs, jfs of GNU/Linux, FAT, NTFS of MS Windows, and HFS+ of Mac OS (testing feature provided by partclone). Therefore you can clone GNU/Linux, MS windows and Intel-based Mac OS. For these file systems, only used blocks in partition are saved and restored. For unsupported file system, sector-to-sector copy is done by dd in Clonezilla.
* LVM2 (LVM version 1 is not) under GNU/Linux is supported.
* Multicast is supported in Clonezilla SE, which is suitable for massively clone. You can also remotely use it to save or restore a bunch of computers if PXE and Wake-on-LAN are supported in your clients.
* Based on Partimage, ntfsclone, partclone, and dd to clone partition. However, clonezilla, containing some other programs, can save and restore not only partitions, but also a whole disk.
* By using another free software drbl-winroll, which is also developed by us, the hostname, group, and SID of cloned MS windows machine can be automatically changed.

Т.е Clonezilla - бесплатная альтернатива Acronis, Norton Ghost и т.д
При создании образа раздела/диска копируются только занятые блоки данных, допускается возможность сжатия образа. Полученный образ можно записать как локально, так и на удаленный сервер (ssh, smb, nfs).
В отличие от простого копирования командой dd, которая копирует и свободное место, в Clonezilla входят несколько утилит, обрабатываю поток данных до утилиты dd, полностью игнорируя свободные блоки.
Поэтому в образ войдут только данные.
Так-же не стоит забывать, что получаемый образ - это образ созданный с помощью утилиты dd , и архиватора (опционально) с которым можно работать на любой UNIX системе, и Вы не привязаны к одному дистрибутиву(продукту).

Так же помимо LiveCD есть серверный вариант.
Clonezilla поддерживает PXE установку образов. Этот вариант я рассматривать не буду. Кому интересно об этом можно почитать ТУТ

Приступим:
1) Идём на Clonezilla.org и оттуда закачиваем последний Stable Live CD
Пишем его на CD или в случае использования Grub4DOS делаем следующие:
Монтируем образ :

mkdir -p /mnt/iso
mount -o loop /tmp/clonezilla-live-1.2.1-23.iso /mnt/iso

2) Монтируем раздел Flash, на который будем копировать файлы Clonezilla

mkdir -p /mnt/flash
mount /dev/sdb1 /mnt/flash # sdb - моя Flash, а sdb1 мой 1-й раздел Flash c Grub4DOS
cp -r /mnt/iso/live /mnt/flash # копируем папку live из iso образа, в котором содержаться файлы Clonezilla

3) В файл menu.lst вписываем:

title Clonezilla
root (hd0,0)
kernel /live/vmlinuz1 boot=live union=aufs ocs_live_run="ocs-live-general" ocs_live_extra_param="" ocs_live_keymap="" ocs_live_batch="no" ocs_lang="" vga=791 ip=frommedia nolocales
initrd=/live/initrd1.img

4) Сохраняем, поздравляю, у Вас теперь Live Flash версия Clonezilla с загрузкой через Grub4DOS

Теперь остаётся следовать инструкциям мастера Clonezilla.
Если вдруг Вы вышли в командную стоку и не знаете как запустить мастера, выполните:

sudo -i # получите права root'a и можете например монтировать диски, и т.д
clonezilla # запуск мастера

По окончании клонирования Вы получите образ, который можно легко восстановить через Clonezilla или любой другой Live Linux дистрибутив.
Если Вам понадобятся отдельные файлы ил образа, то Вы можете просто скопировать их из образа, привязав его к виртуальному устройству.
Как это сделать я писал ранее.

Автоматизация резервного копирования в Linux

Автоматизация резервного копирования в Linux

Никаких отговорок: безопасное распределенное сетевое резервное копирование своими руками

Уровень сложности: средний Карлос Юстиниано, архитектор программного обеспечения, Ecuity Inc. 13.01.2009 Потеря критически важных данных может оказаться невосполнимой. И тем не менее миллионы профессионалов легкомысленно относятся к резервному копированию своих данных. И хотя причины этому в каждом случае свои, одно из наиболее часто встречающихся объяснений сводится к тому, что регулярное выполнение резервного копирования может быть неприятной рутинной работой. Поскольку машины являются непревзойденными исполнителями повторяющихся изо дня в день задач, автоматизация резервного копирования является важнейшим способом уменьшить объем связанной с данным процессом рутинной работы и побороть присущую человеку тенденцию к откладыванию важных дел. Если вы - пользователь Linux, то в вашем распоряжении уже имеются исключительно мощные инструменты для создания специализированных решений резервного копирования. Решения, описанные в данной статье, позволяют выполнять как простое, так и более продвинутое сетевое резервное копирование, используя инструменты с открытыми исходными кодами, входящие в состав практически любого дистрибутива Linux. Простая схема резервного копирования Чтобы упростить освоение материала, в данной статье используется пошаговый подход. Мы начнем с простого, но эффективного механизма архивирования, а затем перейдем к расширенному решению для распределенного резервного копирования. Взгляните на удобный скрипт arc, позволяющий создавать резервные копии из командной строки Linux. Листинг 1. Shell-скрипт arc #!/bin/sh tar czvf $1.$(date +%Y%m%d-%H%M%S).tgz $1 exit $? Скрипт arc принимает в качестве параметра путь к файлу или каталогу, после чего создает архивный файл, имя которого содержит текущую дату. Например, для архивирования каталога beoserver скрипту arc необходимо передать путь к нему, после чего будет сформирован сжатый архив, имеющий имя приблизительно следующего вида: beoserver.20040321-014844.tgz Упорядочить архивные файлы поможет включение в их имена даты и времени с помощью команды date. Дата имеет следующий формат: год, месяц, день, час, минуты, секунды - секунды, вероятно, в нашем случае уже лишние. О параметрах команды date можно узнать из ее руководства, просмотреть которое можно командой man date. Кроме того, в листинге 1 мы используем параметр -v (verbose, подробно) команды tar. Команда tar, запущенная с данным параметром, отображает имена всех архивируемых файлов. Если этого не требуется, параметр -v можно убрать. Листинг 2. Архивирование каталога beoserver $ ls arc beoserver $ ./arc beoserver beoserver/ beoserver/bookl.dat beoserver/beoserver_ab_off beoserver/beoserver_ab_on $ ls arc beoserver beoserver.20040321-014844.tgz В начало Сложные схемы резервного копирования Простая схема резервного копирования весьма полезна, но она требует ручного выполнения операций. Лучшие отраслевые методики рекомендуют регулярно выполнять резервное копирование, хранить резервные копии на разных носителях и в разных местах. Базовый принцип заключается в том, чтобы избегать зависимости от единственного носителя или места хранения носителей. Мы будем решать эту проблему в следующем примере, основанном на некоторой распределенной сети, схема которой, приведенная на рисунке 1, включает системного администратора, имеющего доступ к двум удаленным серверам и внешнему хранилищу данных. Рисунок 1. Распределенная сеть Резервные копии файлов, находящихся на Сервере №1 и Сервере №2, будут безопасным образом передаваться во внешнее хранилище; весь процесс распределенного резервного копирования будет выполняться полностью автоматически на регулярной основе. Мы воспользуемся стандартным набором инструментов, в который входят программы из пакета Open Secure Shell (OpenSSH), ленточный архиватор (tar) и служба планирования задач cron. В общем виде наш план заключается в использовании cron для планирования задач резервного копирования, реализованных с помощью shell-скриптов и ленточного архиватора tar. Защищенная оболочка (ssh) будет обеспечивать шифрование трафика и аутентификацию пользователей, а программа защищенного копирования (scp) - автоматизацию передачи файлов. Предварительно рекомендую ознакомиться с руководствами по использованию всех перечисленных инструментов. В начало Защищенный удаленный доступ с использованием открытых/закрытых ключей В контексте информационной безопасности ключ представляет собой данные, используемые для шифрования и расшифровывания других данных. Принцип работы открытого и закрытого ключей интересен тем, что данные, зашифрованные открытым ключом, могут быть расшифрованы только с помощью соответствующего закрытого ключа. Открытый ключ можно свободно распространять чтобы другие люди могли шифровать им сообщения, адресованные вам. Одной из причин, по которым схемы с открытым ключом произвели революцию в информационной безопасности, является отсутствие у отправителя и получателя сообщения необходимости в общем ключе или пароле. Помимо прочих полезных вещей, криптография с открытым ключом сделала возможной электронную торговлю и другие виды защищенных транзакций. В этой статье мы создадим открытый и секретный ключи, которые будем использовать для создания защищенного решения для распределенного резервного копирования. На каждом компьютере, задействованном в процессе резервного копирования, должна быть запущена служба защищенной оболочки OpenSSH (sshd). Используемый службой порт 22 должен быть открыт для данных машин на всех промежуточных сетевых экранах. Если вы работаете с удаленными серверами, велика вероятность, что вы делаете это с помощью защищенной оболочки. Мы постараемся обеспечить удаленный доступ к компьютерам, избежав необходимости указывать пароли вручную. Существует мнение, что самым легким способом решения данной задачи является отказ от использования паролей: так делать не нужно . Это небезопасно. Подход, который мы рассмотрим в данной статье, позволит за час настроить систему, обеспечивающую высокий уровень информационной безопасности, и при этом сохраняющую все преимущества "беспарольного" доступа. Для начала проверим, установлен ли пакет OpenSSH, и выясним номер его версии. На момент написания этой статьи последним выпуском OpenSSH была версия 3.8, увидевшая свет 24 февраля 2004 г. Рекомендуется использовать наиболее свежий и стабильный выпуск, по крайней мере более поздний, чем версия 2.x. Для получения подробной информации о уязвимостях, обнаруженных в ранних версиях OpenSSH, посетите страницу OpenSSH Security (ссылка приведена ниже в разделе Ресурсы). В настоящий момент OpenSSH является вполне стабильной программой, не имеющей уязвимостей, обнаруженных в других SSH-инструментах. Для отображения версии программы выполните команду ssh с параметром V (прописная буква): $ ssh -V OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f Если команда ssh отобразила версию выше 2.x, данный компьютер находится в относительно неплохой форме. Рекомендуется тем не менее использовать последние стабильные выпуски всего установленного программного обеспечения - в особенности это важно для средств информационной безопасности. Нашим первым шагом будет вход на сервер внешнего хранилища под учетной записью, которая будет иметь доступ к серверам 1 и 2 (рисунок 1). $ ssh accountname@somedomain.com После входа на сервер внешнего хранилища создайте пару из открытого и секретного ключей, запустив программу ssh-keygen с параметром -t dsa. Параметр -t является обязательным и используется для указания типа ключа шифрования, который требуется сгенерировать. Мы воспользуемся алгоритмом Digital Signature Algorithm (DSA), позволяющим применять новый протокол SSH2. Дополнительную информацию по данному вопросу можно получить, ознакомившись с руководством к программе ssh-keygen. После запуска ssh-keygen вам будет предложено указать каталог, в котором будут созданы файлы ssh-ключей, после чего будет запрошен пароль. Если на вопрос о каталоге для сохранения ключей ответить простым нажатием Enter, программа создаст скрытый каталог .ssh (если он не был создан ранее), в котором будут находиться два файла, содержащие открытый и секретный ключи. Интересной возможностью ssh-keygen является то, что программа позволяет пользователю отказаться от ввода парольной фразы, нажав Enter в ответ на соответствующий запрос. Если парольная фраза не указана, ssh-keygen сгенерирует незашифрованные ключи. Нетрудно догадаться, что это - не самая лучшая идея. В ответ на запрос парольной фразы следует ввести текстовое сообщение разумной длины, состоящее из алфавитно-цифровых символов, а не ограничиваться обыкновенным односложным паролем. Листинг 3. Старайтесь выбрать хорошую парольную фразу [offsite]:$ ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/accountname/.ssh/id_dsa): Enter passphrase (empty for no passphrase): (enter passphrase) Enter same passphrase again: (enter passphrase) Your identification has been saved in /home/accountname/.ssh/id_dsa. Your public key has been saved in /home/accountname/.ssh/id_dsa.pub. The key fingerprint is: 7e:5e:b2:f2:d4:54:58:6a:fa:6b:52:9c:da:a8:53:1b accountname@offsite Поскольку каталог .ssh, создаваемый ssh-keygen, является скрытым, чтобы его увидеть, необходимо выполнить команду ls с параметром -a. [offsite]$ ls -a . .. .bash_logout .bash_profile .bashrc .emacs .gtkrc .ssh Перейдите в скрытый каталог .ssh и выведите его содержимое: [offsite]$ cd .ssh [offsite]$ ls -lrt id_dsa id_dsa.pub Видно, что в скрытом каталоге .ssh находятся файлы секретного (id_dsa) и открытого (id_dsa.pub) ключей. Просмотреть содержимое этих файлов можно с помощью текстового редактора, например, vi или emacs, или воспользовавшись командами less или cat. При просмотре содержимого файлов вы увидите, что оно состоит из алфавитно-цифровых символов кодировки base64. Далее нам потребуется скопировать и установить открытый ключ на серверы 1 и 2. Не нужно использовать для этого ftp. Вместо этого воспользуйтесь программой защищенного копирования. Листинг 4. Установка открытых ключей на удаленные серверы [offsite]$ scp .ssh/id_dsa.pub accountname@server1.com:offsite.pub accountname@server1.com's password: (enter password, not new passphrase!) id_dsa.pub 100% |*****************************| 614 00:00 [offsite]$ scp .ssh/id_dsa.pub accountname@server2.com:offsite.pub accountname@server2.com's password: (enter password, not new passphrase!) id_dsa.pub 100% |*****************************| 614 00:00 После установки новых открытых ключей мы сможем заходить на каждый из серверов, используя парольную фразу, указанную при создании открытого и секретного ключей. А пока войдите на каждый из серверов и добавьте содержимое файла offsite.pub в конец файла authorized_keys, находящегося в каталоге .ssh. Это можно сделать с помощью текстового редактора или команды cat: Листинг 5. Добавление offsite.pub к списку авторизованных ключей [offsite]$ ssh accountname@server1.com accountname@server1.com's password: (enter password, not new passphrase!) [server1]$ cat offsite.pub >> ./ssh/authorized_keys На следующем шаге мы примем дополнительные меры безопасности. Сначала мы изменим права доступа к .ssh таким образом, чтобы доступ к данному каталогу на чтение, запись и выполнение имел только его владелец. Затем мы убедимся, что доступ к файлу authorized_keys имеет только его владелец. И наконец, мы удалим за ненадобностью ранее загруженный файл открытого ключа offsite.pub. Очень важно правильно назначить права доступа, поскольку сервер OpenSSH может отказать в использовании ключей, для файлов которых заданы небезопасные права доступа. Листинг 6. Изменение прав доступа командой chmod [server1]$ chmod 700 .ssh [server1]$ chmod 600 ./ssh/authorized_keys [server1]$ rm offsite.pub [server1]$ exit После выполнения этого процесса на сервере 2 мы перейдем на сервер внешнего хранилища для проверки работы нового способа доступа, основанного на парольной фразе. Сделать это можно, выполнив следующую команду на сервере внешнего хранилища: [offsite]$ ssh -v accountname@server1.com Параметр -v, включающий режим вывода подробных сообщений, позволяет отображать отладочную информацию в ходе проверки доступа вашей учетной записи к удаленному серверу с использованием новой парольной фразы вместо первоначального пароля. В отладочную информацию входят сведения, недоступные пользователю в иных условиях, в том числе высокоуровневая информация о работе процесса аутентификации. В ходе обычной работы указывать параметр -v нет необходимости, но при проверке соединения это очень полезно. В начало Автоматизация доступа к компьютеру с помощью ssh-агента ssh-агент играет роль шлюза, по требованию предоставляющего безопасный доступ к ключам. После запуска ssh-агент работает в фоновом режиме и может использоваться такими программами пакета OpenSSH как, например, ssh или scp. С его помощью программа ssh может использовать заранее расшифрованный ключ вместо того, чтобы запрашивать парольную фразу при каждой необходимости. Давайте взглянем на программу ssh-agent поближе. Ssh-agent выводит команды: Листинг 7. ssh-agent в действии [offsite]$ ssh-agent SSH_AUTH_SOCK=/tmp/ssh-XX1O24LS/agent.14179; export SSH_AUTH_SOCK; SSH_AGENT_PID=14180; export SSH_AGENT_PID; echo Agent pid 14180; Мы можем указать оболочке выполнять команды, выводимые программой ssh-agent, с помощью встроенной команды eval: [offsite]$ eval `ssh-agent` Agent pid 14198 Команда eval вычисляет (выполняет) команды, генерируемые программой ssh-agent. Убедитесь, что используются именно обратные (`), а не одинарные кавычки! Команда eval `ssh-agent` возвращает идентификатор процесса агента. Незаметно для нас были экспортированы переменные оболочки SSH_AUTH_SOCK и SSH_AGENT_PID. Их значения можно просмотреть путем вывода в консоль следующей командой: [offsite]$ echo $SSH_AUTH_SOCK /tmp/ssh-XX7bhIwq/agent.14197 Переменная $SSH_AUTH_SOCK (сокращение от SSH Authentication Socket) содержит путь к локальному сокету, предназначенному для связи приложений с программой ssh-agent. Чтобы убедиться в том, что переменные SSH_AUTH_SOCK и SSH_AGENT_PID всегда заданы, добавьте команду eval `ssh-agent` в файл ~/.bash_profile. После этого ssh-agent становится фоновым процессом, увидеть который можно с помощью команд top и ps. Теперь мы можем организовать с его помощью совместный доступ к парольной фразе. Для того, чтобы это сделать, нам потребуется программа ssh-add, добавляющая (отправляющая) парольную фразу программе ssh-agent. Листинг 8. Использование ssh-add для входа на сервер без лишних трудностей [offsite]$ ssh-add Enter passphrase for /home/accountname/.ssh/id_dsa: (enter passphrase) Identity added: /home/accountname/.ssh/id_dsa (/home/accountname/.ssh/id_dsa) Теперь при получении доступа к server1 парольная фраза запрашиваться не будет: [offsite]$ ssh accountname@server1.com [server1]$ exit Если приведенный пример кажется вам неубедительным, попробуйте выгрузить (kill -9) процесс ssh-agent и повторно подключиться к server1. В этом случае вы заметите, что server1 запросит парольную фразу секретного ключа, хранящегося в файле id_dsa, который находится в каталоге .ssh. [offsite]$ kill -9 $SSH_AGENT_PID [offsite]$ ssh accountname@server1.com Enter passphrase for key '/home/accountname/.ssh/id_dsa': В начало Упрощенный доступ к ключам с помощью скрипта keychain К данному моменту мы узнали, как работают некоторые программы пакета OpenSSH (ssh, scp, ssh-agent и ssh-add), а также создали и установили секретный и открытый ключи для того, чтобы обеспечить безопасный автоматический процесс входа на сервер. Вы, вероятно, уже поняли, что большую часть работы по настройке требуется выполнить только единожды. Например, процесс создания и установки ключей, а также настройка запуска ssh-agent из .bash_profile выполняются только один раз для каждого сервера. Это хорошо. Плохо то, что программа ssh-add должна запускаться каждый раз, когда мы входим на сервер внешнего хранилища и, помимо этого, в том, что обеспечение совместимости программы ssh-agent с планировщиком с, который потребуется нам для организации резервного копирования, требует дополнительных усилий. Причина неспособности cron взаимодействовать с ssh-agent заключается в том, что задачи cron выполняются как дочерние процессы планировщика и поэтому не получают копию переменной $SSH_AUTH_SOCK. К счастью, данная проблема имеет решение, позволяющее не только снять ограничения, связанные с использованием ssh-agent и ssh-add, но и использовать cron для автоматизации всех видов задач, требующих безопасного беспарольного доступа к удаленным машинам. В своем цикле OpenSSH key management (ссылка приведена в разделе Ресурсы), состоящем из трех статей, опубликованных developerWorks в 2001 году, Дэниел Роббинс (Daniel Robbins) представил скрипт keychain, представляющий собой интерфейс к программам ssh-agent и ssh-add, облегчающий процесс беспарольного доступа. Со временем был сделан ряд улучшений данного скрипта, который теперь поддерживается Ароном Гриффисом (Aron Griffis). Последний выпуск, датированный 17 июня 2004 г., имеет номер 2.3.2-1. Текст скрипта keychain слишком велик для того, чтобы его можно было привести в данной статье, поскольку он, как и любой качественно написанный скрипт, включает большое количество проверок возникновения ошибок, подробную документацию и внушительный объем кроссплатформенного кода. Несмотря на обширные возможности, скрипт keychain можно быстро загрузить с web-сайта проекта (ссылка приведена в разделе Resources). Работать со скриптом, после того как вы его загрузите и установите, очень просто. Просто зайдите на каждый из серверов и добавьте следующие две строки в конец файлов .bash_profile: keychain id_dsa . ~/.keychain/$HOSTNAME-sh Когда вы зайдете на серверы в следующий раз, keychain запросит парольную фразу. При последующих входах, однако, ввод парольной фразы не будет запрашиваться до момента перезагрузки сервера. И, что самое главное, задачи cron смогут осуществлять безопасный доступ к удаленным машинам без ввода пароля. Теперь наше решение совмещает преимущества повышенной безопасности и простоты использования. Листинг 9. Инициализация keychain на каждом сервере KeyChain 2.3.2; http://www.gentoo.org/projects/keychain Copyright 2002-2004 Gentoo Technologies, Inc.; Distributed under the GPL * Initializing /home/accountname/.keychain/localhost.localdomain-sh file... * Initializing /home/accountname/.keychain/localhost.localdomain-csh file... * Starting ssh-agent * Adding 1 key(s)... Enter passphrase for /home/accountname/.ssh/id_dsa: (enter passphrase) В начало Автоматизация процесса резервного копирования Нашей следующей задачей является написание скриптов, выполняющих операции, необходимые для резервного копирования. Целью работы данных скриптов будет создание полной резервной копии баз данных, находящихся на серверах server1 и server2. На каждом из серверов в рассматриваемом примере установлена СУБД MySQL. Соответственно для экспорта нескольких таблиц в виде SQL-скрипта мы будем использовать утилиту mysqldump, работающую в командной строке. Листинг 10. Скрипт dbbackup.sh для сервера 1 #!/bin/sh # переходим в каталог backup_agent, в котором хранятся файлы данных. cd /home/backup_agent # экспортируем таблицы баз данных с помощью утилиты mysqldump mysqldump -u sitedb -pG0oDP@sswrd --add-drop-table sitedb -- tables tbl_ccode tbl_machine tbl_session tbl_stats > userdb.sql # архивируем и сжимаем файлы tar czf userdb.tgz userdb.sql На сервере 2 мы разместим аналогичный скрипт, осуществляющий резервное копирование уникальных таблиц установленной на нем БД. Для каждого из скриптов необходимо задать признак исполняемого файла, выполнив команду: [server1]:$ chmod +x dbbackup.sh Разместив копии файла dbbackup.sh на серверах 1 и 2, мы возвращаемся на сервер внешнего хранилища, где создаем скрипт, выполняющий их перед запуском процесса удаленного копирования сжатых архивов (.tgz). Листинг 11. Скрипт backup_remote_servers.sh для размещения на сервере внешнего хранилища #!/bin/sh # используем ssh для удаленного выполнения скрипта dbbackup.sh на сервере 1 /usr/bin/ssh backup_agent@server1.com "/home/backup_agent/dbbackup.sh" # используем scp для безопасного копирования созданного архивного файла userdb.tgz # с сервера 1. Обратите внимание на использование команды date для формирования временной отметки # при размещении файла на сервере внешнего хранилища. /usr/bin/scp backup_agent@server1.com:/home/backup_agent/userdb.tgz / home/backups/userdb-$(date +%Y%m%d-%H%M%S).tgz # выполняем скрипт dbbackup.sh на сервере 2 /usr/bin/ssh backup_agent@server2.com "/home/backup_agent/dbbackup.sh" # используем scp для копирования transdb.tgz на сервер внешнего хранилища. /usr/bin/scp backup_agent@server2.com:/home/backup_agent/transdb.tgz / home/backups/transdb-$(date +%Y%m%d-%H%M%S).tgz Скрипт backup_remote_servers.sh использует ssh для удаленного выполнения скриптов на серверах. Поскольку доступ, организованный нами, не требует ввода пароля, программа ssh может удаленно выполнять команды на серверах 1 и 2 с сервера внешнего хранилища. Благодаря keychain процесс аутентификации происходит полностью автоматически. В начало Планирование задач Наша следующая и последняя задача заключается в планировании выполнения скрипта backup_remote_servers.sh на сервере внешнего хранилища. Для этого мы добавим в конфигурационный файл планировщика cron две новые записи, согласно которым скрипт резервного копирования будет запускаться дважды в день - в 3:34 и в 20:34. Чтобы добавить записи, запустите на сервере внешнего хранилища программу crontab с параметром -e. [offsite]:$ crontab -e Программа crontab запустит используемый по умолчанию текстовый редактор, указанный в переменных среды VISUAL или EDITOR. Теперь введите две новые записи, после чего сохраните и закройте файл. Листинг 12. Записи crontab на сервере внешнего хранилища 34 3 * * * /home/backups/remote_db_backup.sh 34 20 * * * /home/backups/remote_db_backup.sh Запись файла crontab состоит из двух основных частей: спецификации времени выполнения и команды, подлежащей выполнению. Спецификация времени выполнения включает следующие поля: Листинг 13. Формат записи crontab +---- минута | +----- час | | +------ день | | | +------ месяц | | | | +---- день недели | | | | | +-- команда, подлежащая выполнению | | | | | | 34 3 * * * /home/backups/remote_db_backup.sh В начало Верификация резервных копий Рекомендуется регулярно проводить проверку резервных копий чтобы убедиться в правильной работе процесса. Автоматизация процессов помогает избавиться от ненужной рутины, но заменить добросовестного отношения к делу она не может. Если ваши данные заслуживают резервного копирования, то время от времени имеет смысл проводить выборочную проверку качества его выполнения. Возможно, стоит создать задачу планировщика cron, которая по меньшей мере раз в месяц напоминала бы вам о необходимости проверки резервных копий. Кроме того, неплохо было бы менять ключевую пару по истечении определенного периода; напомнить вам об этом может также задача планировщика cron. В начало Дополнительные меры обеспечения информационной безопасности Для повышения уровня информационной безопасности можно установить и настроить на каждом сервере систему обнаружения вторжений (Intrusion Detection System, IDS), например, Snort. Система обнаружения вторжений предназначена для оповещения о попытках взлома системы, происходящих в данный момент или имевших место недавно. Наличие такой системы позволит наращивать уровень информационной безопасности за счет применения таких технологий как цифровая подпись и шифрование резервных копий. Архивные файлы можно защитить с помощью распространенных инструментов с открытым исходным кодом, например GNU Privacy Guard (GnuPG), OpenSSL и ncrypt, однако, применять их без дополнительного уровня защиты, предоставляемого системой обнаружения вторжений, не рекомендуется (ссылки на дополнительную информацию по Snort приведены в разделе Ресурсы). В начало Заключение В статье было продемонстрировано удаленное выполнение скриптов на серверах и осуществление безопасного автоматического копирования файлов. Я надеюсь, что ее прочтение дало вам информацию для размышлений о том, как защитить ваши ценные данные с помощью таких инструментов с открытыми исходными кодами, как OpenSSH и Snort. Ресурсы Примите участие в обсуждении материала на форуме. Оригинал статьи Automate backups on Linux (EN) (developerWorks, июль 2004 г., обновлено: июль 2008 г). На официальном сайте OpenSSH и странице OpenSSH Security вы найдете файлы для загрузки, документацию и много другой информации. Прочтите замечательный цикл из трех статей, написанный Дэниелом Роббинсом для IBM developerWorks "OpenSSH Key Management" (EN) (developerWorks, 2001) и загрузите написанное им приложение keychain. Тем, кто хочет узнать больше о SSH, Карлос рекомендует книгу издательства O'Reilly SSH, The Secure Shell: The Definitive Guide (EN) (O'Reilly & Associates, 2001 г.). Система обнаружения вторжений Snort - лучший инструмент данного типа с открытыми исходными кодами, предназначенный для выявления и информирования о случаях несанкционированного доступа или подозрительного поведения. Рекомендуем использовать систему обнаружения вторжений при организации автоматической подписи и шифрования архивных файлов, Архивные файлы резервных копий можно подписывать и шифровать с помощью скриптов, использующих GNU Privacy Guard (GnuPG), OpenSSL и ncrypt. Любителей Perl должны заинтересовать статьи Теда Златанова (Ted Zlatanov) "Automating UNIX system administration with Perl" (EN) (developerWorks, 2001 г.), "Intro to cfengine for system administration" (EN) (developerWorks, 2002 г.), and "Application configuration with Perl" (EN) (developerWorks, 2000 г.). Статья "Windows-to-Linux roadmap: Part 8. Backup and recovery" (EN) (developerWorks, 2003 г.), опубликованная на сайте developerWorks, содержит советы по выбору стратегии резервного копирования. IBM Tivoli Storage Manager для Linux (EN) позволяет автоматизировать и обеспечить проведение по расписанию надежного резервного копирования, архивирования и централизованного управления данными на рабочих станциях и серверах, работающих под управлением Linux. Кроме того, линейка продуктов Tivoli включает инструменты для управления пользователями, управления доступом, мониторинга сети и многого другого, предлагая при этом унифицированную среду и интерфейс. Узнайте больше о решениях Tivoli в разделе сайта IBM developerWorks, посвященном Tivoli. В разделе сайта developerWorks, посвященном Linux, можно найти другие материалы для Linux-разработчиков. В магазине технической литературы есть книги на эту и другие темы.(EN) Разрабатывайте и тестируйте ваши приложения для Linux с помощью новейших инструментов и ПО промежуточного слоя, предлагаемых IBM по подписке developerWorks (EN): вы получаете такое программное обеспечение IBM как WebSphere, DB2, Lotus, Rational и Tivoli вместе с лицензией, дающей право пользования им в течение 12 месяцев - все это за меньшие деньги, чем вы предполагаете. Загрузите бесплатные ознакомительные версии отдельных продуктов подписки developerWorks, предназначенных для Linux, включая WebSphere Studio Site Developer, WebSphere SDK for Web services, WebSphere Application Server, DB2 Universal Database Personal Developers Edition, Tivoli Access Manager и Lotus Domino Server, в разделе сайта developerWorksSpeed-start your Linux app (EN). Чтобы начать работу еще быстрее, ознакомьтесь с обучающими статьями и материалами технической поддержки по продуктам.(EN) Об авторе Карлос Юстиниано - архитектор программного обеспечения в компании Ecuity, Inc. В круг его интересов входят коммуникации и распределенные вычисления. Карлос сотрудничает с рядом технических журналов в качестве автора. Кроме того, он является основателем и архитектором Linux-проекта ChessBrain, основанного на распределенных вычислениях и вошедшего в 2005 г. в Книгу рекордов Гиннесса.

Настройка резервного копирования в Ubuntu за 20 минут.

Настройка резервного копирования в Ubuntu / Linux для всех / Хабрахабр

Для работы над проектами использую svn, который находится на удаленном виртуальном выделенном хосте, под управлением ubuntu 8.04. Со временем объемы данных выросли, как и критичность этих данных. Потеря чего-то снилась в кошмарах. Время от времени копировал репозитории на локальный компьютер. Недавно мне это надоело. И я стал искать возможности автоматизировать это дело. Не буду говорить о поисках и вариантах, расскажу о результатах.

Итак, мы имеем удаленный хост под управлением ubuntu, с некоторым массивом довольно критичных данных. Довольно логичным было бы настроить бэкап прямо на удаленном хосте, с помощью tar по крону, rsyns и т.д. Но, т.к. место на виртуальном выделенном хостинге довольно дорого и использовать его лучше по делу, идеально было бы, чтобы данные автоматически копировались на какую нибудь локальную машину, место на которой хоть отбавляй. В моем случае это файловый сервис в офисе, под управлением все той же Ubuntu.

Подготовка

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

$ ssh-keygen -t dsa

Оставьте папку по-умолчанию, а пароль сделайте пустым.
Эта команда должна создать в папке ~/.ssh(по умолчанию) два файла — private и public key. private предназначается для локальной машины, pub отправляется на удаленный.

Теперь копируем private key в папку /root/.ssh, чтобы пользователь root так мог пользоваться им

$ cd ~/.ssh
$ sudo mkdir /root/.ssh
$ sudo cp id_dsa /root/.ssh

Теперь надо скопировать public key на удаленную машину, с которой мы хотим копировать данные. Предварительно создайте пользователя backup на удаленной машине(команда adduser). Не забудьте дать этому пользователю права на чтение каталогов, которые вы хотите копировать.

$ cat ~/.ssh/id_dsa.pub | ssh backup@remotehost.ru "cat >> ~/.ssh/authorized_keys2"

Теперь можем попробывать зайти через ssh на удаленную машину:

$ ssh backup@remotehost.ru

В случае, если все сделано правильно, нас впустит без пароля.
На удаленной машине ставим нормальные права на чтение публичного ключа:

remotehostru$ chmod 700 .ssh
remotehostru$ chmod 400 .ssh/authorized_keys2
remotehostru$ exit

Настройка rsnapshot

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

Установка

Устанавливаем rsnapshot:

$ sudo apt-get install rsnapshot

Если вы используете не debian-подобный дистрибутив, rsnapshot наверняка тоже есть в репозиториях вашего дистрибутива. Для CentOS, при включенных RPMForge это делается, например, так:

# yum install rsnapshot

Теперь нам нужно создать директорию, где мы собираемся хранить наши «снимки»:

$ sudo mkdir /var/snapshots

Настройка

Теперь можно перейти к настройке, собственно, rsnapshot:

$ sudo nano /etc/rsnapshot.conf

Вместо nano вы можете использовать любой другой редактор, например vi, или gedit, если работаете в GNOME.
Настроить нужно следующие параметры:

snapshot_root - директория, в которую вы хотите сохранять "снимки".

interval xxx yy - ххх - название интервала(например hourly, daily), yy - количество снимков для каждого. Например:
interval hourly 6
interval daily 7

Означает, что мы хотим хранить 6 ежечасных копий и 7 ежемесячных. Если уже доступно указанное количество копий, rsnapshot будет заменить старую более новой.

Расскомментируйте cmd_cp. cmd_ssh расскоментируйте и измените на

cmd_ssh /usr/bin/ssh

Настройка бэкапа осуществляется командой backup <откуда> <куда>:

#Добавляем папку /etc/ с локальной машины в папку localhost/
backup /etc/ local/
#Добавляем папку /var/svn с удаленной машины в папку remotehost/
backup backup@remotehost.ru:/var/svn/ remotehost/


Помните, что в конфигурационном файле недопустимы пробелы — используйте только табы.

Пробный запуск

Запустим rsnapshot:
$ rsnapshot hourly

Второй параметр означает интервал, который мы задали в конфигурационном файле.
Команда может выполняется продолжительное время. После выполнения, смотрим, что она создала:
$ ls -l /var/snapshots

Пока что в директории должен быть один каталог: hourly.0. При следующем запуске rsnapshot будет создавать каталоги hourly.1, hourly.2 и т.д., пока не упрется в максимум, указанный нами в конфигурационном файле.

Настройка cron

В Ubuntu автоматически создается файл /etc/cron.d/rsnapshot со следующим содержанием:
0 */4 * * * root /usr/bin/rsnapshot hourly
30 3 * * * root /usr/bin/rsnapshot daily
0 3 * * 1 root /usr/bin/rsnapshot weekly
30 2 1 * * root /usr/bin/rsnapshot monthly

Вот и все. Теперь у вас 6 раз в сутки должен автоматически создаваться снимок данных с вашего удаленного сервера. Данные в сохранности, да еще и географически распределены.

Кстати, 6 раз в сутки не означает, что размер будет в 6 раз больше, чем если копировать всего 1 раз в сутки. Если в промежутки между копированиями не будет изменений в файлах, то общий размер копий почти не изменится.

Дополнительная информация

С помощью параметра backup_script можно также настроить резервное копирование баз данных MySQL, да и вообще всего, чего угодно. Я не описывал сей процесс, т.к. у меня он не используется и ничего конкретного сказать не могу.
Подробнее можно почитать в гугле. По запросу rsnapshot вылезает куча релевантных ссылок, правда на английском языке.

Прошу особо не ругать, на гуру администрирования(да и linux) я не похож, но довольно долго искал, как просто автоматизировать резервное копирование — нашел способ, решил поделиться.
Но конструктивной критике и предложениям буду, конечно, рад.
_________
Текст подготовлен в ХабраРедакторе

Резервная копия Gmail

Резервная копия Gmail / Google / Хабрахабр

Многие пользователи (и я в том числе) уже давно перешли с привычных e-mail клиентов на работу с почтой непосредственно онлайн. А некоторые клиентами не пользовались в принципе. Это значит, что локальной копии писем и документов у них нет. Так вот, если где-то там, в дальних закоулках сознания у таких пользователей присутствует опасение за свои письма на сервере Gmail (ну, мало ли, всякое может произойти, ведь ничто не совершенно), то обезопасить себя и данные можно при помощи утилитки Gmail Backup.

Эта полезная штучка сохраняет резервные копии содержимого ящика на Gmail. Делает она это по IMAP. А сохраняет данные в формате EML. Программа работает как в OC Windows, так и под Linux и Mac OS X. В первом случае пользователю предлагается графический интерфейс. А для Linux и Mac OS X — утилита командной строки. Программа позволяет забэкапить как письма, так и аттачи.

Одно из самых значимых достоинств Gmail Backup — возможность загрузки архива обратно на сервер Gmail. Под другим аккаунтом. Так что если появилась нужда в «переезде» на другой аккаунт, то сделать это можно максимально просто и безболезненно.

Качать тут: Gmail Backup

via lifehacker

Сохраним свой LINUX - бэкап партиции с помощью PING (Partimage Is Not Ghost) | Kubuntu

Сохраним свой LINUX - бэкап партиции с помощью PING (Partimage Is Not Ghost) | Kubuntu

Bazilio написал 24 Февраля, 2008 - 14:56 |

Мне надоело переустанавливать Kubuntu после каждого неудачного эксперимента. А поскольку я эксперементирую довольно часто, доволно часто случается так, что первоначальное состояние системы уже не востановить.
Я решил сделать бэкап настроенной и рабочей системы. Но не с помощью всяких там "Keep - Backup System", ведь иногда и загрузиться то не удаётся нормально, а путём копирования партиции жёсткого диска, куда установлен Linux.
Сначала была идея сделать это с помощью винды, но нашёл ничего бесплатного и юзабельного. Погуглив, натолкнулся на такую шикарную вещь, как PING (Partimage Is Not Ghost). "PING is a live Linux ISO, based on the excellent Linux From Scratch (LFS)" - PING это Live CD, базирующийся на LFS.
Взять это чудо можно тут http://ping.windowsdream.com/ping/download.html

А вот как этим пользоваться:
Для начала нужно записать iso образ на диск. Далее следуем по шагам:
1) Загружаемся с этого диска
2) На первый вопрос (или предложение :) ) нажимаем Enter
3) Далее OK (нажатием Enter)
4) Нас спрашивают, что сделать, когда мы закончим. Я выбрал перезагрузку
5) Выбираем, где хранить\от куда востанавливать. Я выбрал локально, сетевое расположение не пробовал.
6) Выбираем партицию, которую хотим забэкапить. (Для востановления надо выбрать первую опцию) (Нужный пункт выбирается с помощью пробела)
7) Выбираем партицию, на которую хотим сохранить наш бэкап
8) Выбираем название каталога, куда сохраняь. Я выбрал "\"
9) Выбираем последний пункт: Create_New_Image
10) Вводим имя образа. (Будет создан каталог с этим именем, а в нём уже файлики бэкапа, созданные системой)
11) Выбираем сжимать или не сжимать наш образ. Я выбрал не сжимать, чтобы это всё побыстрей произошло.
12) NO
13) YES

Мой образ занял всего 3.85 Гигабайт. Заметьте, что делается образ не всей партиции (у меня она 25 гигов весит), а только занятого места!
По времени это заняло 5 минут.

Процесс востановления ещё проще, поэтому я не буду расписывать его по шагам. Я уже им пользовался - востановилось всё также быстро и без каких-либо глюков!

»

• Блог пользователя Bazilio
• цитировать

Резервное копирование в Линукс

Оригинал: Linux Backups For Real People
Автор: Carla Schroder
Дата: 1-8 ноября 2007
Свободный перевод: Алексей Дмитриев
Дата перевода: 20 декабря 2007

При копировании материала обязательны указание автора, переводчика и ссылки на оригинал статьи и настоящую страницу как первоисточник перевода!

Часть 1

Оборудование для резервного копирования

Каждый наслышан о необходимости регулярно делать резервное копирование своей информации. Но мало кто занимается этим так прилежно, как следовало бы. В данном руководстве мы изучим простые и надежные методы регулярного резервного копирования на отдельном ПК или в небольшой сети. В части первой рассказывается о сменных носителях резервных копий, и о том, как заставить udev дать этим сменным носителям постоянные имена. Часть вторая покажет быстрый, простой, надежный способ проведения резервного копирования - автоматически и со скоростью нажатия кнопки.

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

Чтобы осуществлять резервное копирование по моей схеме вам понадобятся:
Сравнительно современный ПК с поддержкой USB 2.0
GParted - великолепная графическая программа для создания разделов
Сменное устройство накопления данных, как то: жесткий диск SATA или PATA, либо USB-накопитель, либо компактная Flash-карта.

Можно приобрести внешний контейнер для жестких дисков и подключить к нему любой SATA или PATA жесткий диск. Можно предпочесть готовый внешний жесткий диск. Такие диски зачастую поставляются с предустановленным Windows- или Mac- программным обеспечением, что не является проблемой, так как нам не нужны их дурацкие программы. Диски нужно переформатировать, ведь они могут быть в NTFS или иной ненужной нам файловой системе. Тут на сцену выходит GParted - лучшая графическая программа создания и форматирования разделов для всех платформ. Подключайте внешний накопитель, убедитесь, что он не примонтирован, и создавайте на нем любые разделы.

Проще всего отформатировать носитель в файловые системы FAT16 или FAT32. Дело в том, что указанные файловые системы не поддерживают никаких прав собственности и прав доступа к файлам, что означает легкодоступность резервных копий на любом компьютере. FAT16 не применяется для носителей размером более 512 Мб, так как она очень неэкономно расходует дисковое пространство.

Создание файловой системы при помощи программы GParted

В верхнем правом углу окна программы GParted находится выпадающее меню для выбора нужного физического диска. Если появился маленький значок замочка, то файловая система примонтирована. Ее необходимо отмонтировать. Можно попытаться сделать это при помощи меню, вызываемого правой кнопкой мыши, но иногда этот прием не срабатывает. Ваше графическое рабочее окружение наверняка имеет инструменты, позволяющие монтировать и отмонтировать файловые системы. Но с полной надежностью можно проделать это, дав в командной строке команду (как root):

# umount /dev/sdc1

GParted сообщит вам правильное имя устройства (в примере - sdc1).
Потом нажимаем GParted -> Refresh Devices, и можно приступать к созданию разделов и форматированию их.

Как дать устройствам постоянные имена

Разные дистрибутивы Линукса по-разному настраивают udev - программу, управляющую устройствами. Вполне возможно, что одному и тому же сменному накопителю при подключении каждый раз будут присваиваться различные имена. Нас такое положение дел не может устроить, так как для использования их в качестве носителей резервных копий, они должны иметь постоянные имена.
Чтобы решить задачу, нужно внести изменения в конфигурацию udev. Ubuntu, Fedora, Red Hat, Mandriva, PCLinuxOS и многие другие дистрибутивы Линукс решают проблему, присваивая уникальную метку тома (label) нужному разделу.

Разберем на примере:
Допустим, для резервного копирования вы используете карту Compact Flash. Для разных файловых систем существуют разные инструменты; если мы используем файловые системы FAT16/32, то нам понадобится пакет mtools. Для начала нужно присвоить файловой системе какую-либо букву в стиле Windows, пусть это будет буква "u". Для этого в файл /etc/mtools.conf вписываем следующие строки:

# Lexar compact flash
drive u: file="/dev/sdc1"

Теперь в консоли, в командной строке, присваиваем устройству метку тома (label):

#  mlabel u:
Volume has no label
Enter the new volume label : backup1

Проверим правильность полученного:

$ mlabel -s u:
Volume label is BACKUP1

Теперь при подключении вашей Флеш-карты, она будет всегда автоматически монтироваться в директорию /media/BACKUP1. (Не пугайтесь заглавных букв, эта метка и не думает на вас кричать).

Что делать, если ваш дистрибутив всего этого не делает? Вскоре мы подобно разберем настройки udev, а пока придется обратиться к старому доброму файлу /etc/fstab. Сперва создаем директорию /media/backup1, затем вписываем в /etc/fstab следующие строки:

# Lexar 2G compact flash, backup1 LABEL=BACKUP1 /media/backup1 vfat user,noatime,noauto,rw,dev,exec,suid 0 0

Монтировать придется вручную, причем рядовой пользователь сможет монтировать и размонтировать устройство следующими командами:

$ mount /media/backup1
$ umount /media/backup1

Не переживайте, наша схема резервного копирования легко управится с этим.

Часть 2

Резервное копирование для одного пользователя

В первой части мы приводили в порядок оборудование для резервного копирования. Сейчас рассмотрим детально процесс резервного копирования информации (данных) на местный съемный носитель. Также узнаем, как отобрать файлы, подлежащие резервному копированию, и создать резервную копию одной командой.

Я подразделяю резервное копирование на две категории: резервное копирование системных файлов и резервное копирование файлов данных. Эта статья посвящена исключительно последним. Для клонирования системы и ее экстренного восстановления существуют простые специальные программы типа MondoRescue.

Мы не будем использовать сложных специализированных приложений для резервного копирования, а остановимся на старой надежной и эффективной команде rsync. Эта команда передает только изменения файлов, и после первичного создания резервной копии, все последующие делаются очень быстро. Программа rsync создает обычную Линукс директорию с обычными файлами, таким образом, процесс восстановления файлов сводится к привычному копированию, не требуя ни специального программного обеспечения, ни хитро-мудрых команд.

Размер носителя должен минимум вдвое превышать суммарный размер файлов, подлежащих резервному копированию. Графические файловые менеджеры сообщат вам размеры директорий, хотя я предпочитаю добрые старые команды du (disk used - использовано на диске) и df (disk free - свободно на диске), потому что они работают быстро и одинаково на любом дистрибутиве Линукса. Запускайте эти команды в терминале, чтобы выяснить, сколько свободного и занятого места в ваших файловых системах:

$ df -hlx tmpfs
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda1              14G  2.4G   11G  18% /
/dev/sda1              31G  9.3G   21G  32% /home
/dev/hda2             4.5G  543M  3.8G  13% /var

Для отдельных файлов и директорий нужна команда du, как в этом примере с моей директорией finances:

$ du -hs finances
8.2M    finances

А если нужна подробная распечатка директории с размерами всех подкаталогов, то опустите опцию -s.

Создание пробной резервной копии

Проведем пробное резервное копирование на USB носитель, используя имена устройств из части 1 данного руководства. Подключим носитель, затем скопируем на него две директории, используя команду rsync. Как вы помните, мы отформатировали носитель в FAT16/32, так что с командой rsync применим специальные опции для файловой системы FAT. В следующем примере я скопирую директории finances и configs, указывая полный абсолютный путь к этим директориям:

$ rsync -rlvt --modify-window=1 ~/finances ~/configs /media/BACKUP1

Тильда, ~, это общепринятое сокращение для домашней директории (/home). На экране промелькнут имена файлов, затем появится итог:

sent 8306732 bytes  received 1270 bytes  3323200.80 bytes/sec
total size is 8301576  speedup is 1.00

Теперь откройте директорию /media/BACKUP1 и полюбуйтесь на ваши резервные копии файлов. Они выглядят как обычные файлы, каковыми в действительности и являются, их можно просматривать и копировать как обычно.

Следите за замыкающими слэшами (/)! Их не должно быть, так что я напечатаю /media/BACKUP1/finances и /media/BACKUP1/configs. Если бы я напечатала finances/ и configs/ вместо этого, то получила бы /media/BACKUP1 без двух директорий, зато с файлами, которые находились в этих директориях.

Теперь попробуйте крутую штуку: нажмите стрелочку вверх, чтобы снова повторить команду rsync, и нажмите enter, чтобы снова выполнить ее. Вы увидите нечто вроде:

$ rsync -rlvt --modify-window=1 ~/finances ~/configs /media/BACKUP1 sent 1582 bytes received 20 bytes 3204.00 bytes/sec total size is 8301576 speedup is 5182.0

Отметьте разницу в размере показателя "sent" (отправлено). Эта разница свидетельствует о том что "заклинание" rsync сработало правильно, и во второй раз были переданы только изменения, произошедшие после первого раза.

Опция:
-r означает рекурсивно,
-v означает "комментируя свои действия",
-l копирует симлинки ("мягкие" ссылки),
-t фиксирует время модификации,
--modify-window=1 устанавливает односекундный интервал между временем модификации оригинала и копии.
Последние три опции необходимы для FAT16/32. Если вы опустите опцию -t, то команда rsync просто скопирует файлы, вместо того, чтобы передать лишь изменения. Файловая система FAT16/32 по умолчанию оперирует двухсекундными интервалами времени, и необходима преобразующая опция --modify-window, для установления односекундного интервала.

Команда rsync имеет полезную опцию --dry-run, которую стоит применять в случае неуверенности. Команда сработает "вхолостую" - будет видно, что произойдет, но никаких изменений в файловую систему при этом внесено не будет.

Rsync: усовершенствуем заклинание

Команда rsync имеет множество опций, их можно посмотреть в man rsync. Приведу несколько наиболее полезных:

-- delete
Когда вы удаляете файлы из системы, использование данной опции приведет к удалению этих файлов также и с носителя резервной копии.

--exclude-from=[filename]
Исключить. Можно создать файл filename, в котором перечислены типы файлов, не подлежащие резервному копированию. Их нужно указывать по одному на строке, вот так:
*.tmp
*.temp
*.bak

--include-from=[filename] Включить. Можно использовать эту опцию для перечисления директорий, подлежащих копированию, только нужно делать это предельно аккуратно и правильно. Иначе опция не будет работать, и вы примкнете к армии печальных, потерянных людей, бороздящих просторы Google, пытаясь найти ответы. Я копирую директории /home/carla/finances и /home/carla/configs. Для этого я прописываю в файле rsync-includes следующие строки:
+ /finances
+ /finances/**
+ /configs
+ /configs/**
- *
Двойные звездочки гарантируют, что все суб-директории также будут скопированы.
Затем я называю родительскую директорию в команде rsync следующим образом: /home/carla/*.

Есть и другие способы использования опций --include-from и --exclude-from, но сегодня мы остановимся на этом.

Теперь сведем все заклинание вместе:

$ rsync -rlvt --modify-window=1 --delete --include-from=/home/carla/rsync-includes /home/carla/* /media/BACKUP1

Довольно длинная строка, чтобы печатать ее каждый раз, так что создадим для команды псевдоним (alias):

$ alias backup1='rsync -rlvt --modify-window=1 --delete --include-from=/home/carla/rsync-includes /home/carla/* /media/BACKUP1'

Теперь, чтобы начать резервное копирование, достаточно напечатать backup1. И нажать Enter. Можно делать это так часто, как вам хочется. При работе с важным документом, можно запускать команду backup1 так же часто, как команду "save" (сохранить).

Ресурсы:
man 1 rsync
man 1 df
man 1 du
man 1 bash чтобы узнать про alias

Часть 3

Простое резервное копирование в сетях

В части первой этого руководства мы научились: как отформатировать съемный USB-накопитель и как настроить udev, чтобы он называл этот накопитель одинаково при каждом подсоединении к компьютеру. Во второй части мы познакомились с великолепной командой rsync, позволяющей просто и эффективно создавать резервные копии данных одного пользователя.

Сегодня займемся созданием значков в меню для простоты запуска процесса резервного копирования, наладим простую схему сетевых резервных копий и создадим расписание, по которому эти копии будут автоматически создаваться.

Сперва сохраним наше заклинание для команды rsync из второй части статьи в командный файл, так называемый скрипт оболочки (shell script) и дадим ему легко запоминающееся имя, скажем, backupscript:

#!/bin/sh ################################## # простой скрипт команды rsync для создания резервных копий # на USB носителе, отформатированном в FAT16/32 ################################## # это должна быть одна длинная непрерывная строка: rsync -rlvt --modify-window=1 --include-from=/home/carla/rsync-includes /home/carla/* /media/BACKUP1

Если у вас проблемы с использованием опций --include-from и --exclude-from и с файлами rsync-includes и rsync-excludes, для вас есть более простой путь - просто перечислить все директории и файлы, подлежащие резервному копированию вот так:

rsync -rlvt --modify-window=1 \
/home/carla/thisdirectory \
/home/carla/thatdirectory \
/home/carla/filename \
/media/BACKUP1

Как видно из примера, необязательно перечислять их в одной строке. Обратный слэш (\) сообщит оболочке Bash, что вы переносите команду на следующую строку. Если же вы решите печатать в одной строке, следите, чтобы эта строка была непрерывной.

Теперь нужно сделать наш текстовой файл исполняемым, т.е. превратить его в скрипт:

$ chmod +x backupscript

Создание значка в меню

И Gnome и KDE имеют редакторы меню, которыми и воспользуемся, чтобы добавить наш скрипт в меню и снабдить его соответствующим значком.

Вот как это сделать в Gnome:
Найдите редактор меню в вашем системном меню, либо вызовите его командой alacarte. Щелкните мышью на строке того меню, в которое желательно поместить наш скрипт. Затем нажмите кнопку New Item (Новый элемент или Новый пункт меню). Кнопка Icon (Значок или Иконка) предоставит вам богатый выбор значков. Введите название, типа MyBackup или нечто вроде того. Затем пропишите в окошке Команда буквально следующую строку (только подставьте свое имя домашнего каталога):

gnome-terminal -x /home/carla/backupscript

Если вам необходимы привилегии суперпользователя для запуска скрипта, то пропишите следующее:

gnome-terminal -x su - -c '/home/carla/backupscript' root

Рисунок 1

На рисунке 1 видно, как это должно выглядеть. Не ставьте галочку в окошко 'Run command in a terminal' (Запускать в терминале). Теперь откройте gnome-terminal и перейдите в 'Edit-Current Profile' (Редактировать профиль). На вкладке 'Title and Command' (Название и команда) выберите 'When command exits: Hold the terminal open' (По завершении оставить терминал открытым). Если этого не сделать, то терминал по завершении команды немедленно закроется, и вы не увидите вывод команды. Если же вы не желаете, чтобы такое поведение стало поведением по умолчанию, то используйте раздел 'File-New Profile' (Новый профиль), чтобы создать новый профиль и дать ему понятное имя типа stayopen. Тогда прописать нужно следующее:

gnome-terminal --window-with-profile=stayopen -x su - -c '/home/carla/backupscript' root

В KDE:

Рисунок 2

Откройте редактор меню, который также можно вызвать командой kmenuedit. Можно щелкнуть правой кнопкой мыши на значке главного меню в левом углу панели. Выберите меню, в которое хотите включить скрипт запуска резервного копирования. Укажите полный путь к вашему скрипту, включите опцию 'Run in Terminal' (Запускать в терминале), и введите опцию --noclose. Если нужны права суперпользователя, включите 'Run as a different user' (Запускать от имени другого пользователя) и введите 'root'. Все должно выглядеть как на рисунке 2.
Сохраните свои изменения и дело сделано.

Теперь нажмите вашу новенькую кнопку резервного копирования и увидите нечто похожее на рисунок 3.

Рисунок 3

Автоматизированное и сетевое резервное копирование

Недорогое резервное копирование в небольшой сети возможно на внешний жесткий диск, подключенный к одному из компьютеров. На этом компьютере должен быть запущен SSH сервер, а на остальных машинах - SSH клиенты. Вместо того, чтобы давать всем доступ к резервному компьютеру, лучше создайте на нем специальный пользовательский аккаунт с запоминающимся именем "backup". Имейте в виду, что тот, у кого есть доступ к резервным копиям, без труда может читать все файлы этих копий.

Допустим, что съемный диск подключен к ПК по имени Penguina. Вы, как положено фанату Линукса, имеете локальный DNS и можете проверить удаленный логин следующим образом:

$ ssh backup@penguina
backup@penguina's password:

Можно использовать также IP адрес, если этот адрес статический.

Мы не хотим появления приглашения ввести пароль, так как это сделает невозможным автоматическое резервное копирование по расписанию, так что мы используем SSH public key authentication. Это легко наладить - следуйте инструкциям раздела "Public-Key Authentication" из руководства The (Practically) Ultimate OpenSSH/Keychain Howto,
только не вводите фразу-пароль!

Теперь давайте модифицируем наш файл backupscript, вернее его последнюю строку, для доступа к удаленному диску. Теперь ее окончание должно выглядеть так:

backup@penguina:/media/BACKUP1/carla

Обратите внимание на добавление новой директории "carla". Поскольку сетевой диск является общим, вы, вероятно, выделите каждому пользователю по отдельной директории.
Команда rsync создаст их для вас. Помните, никаких замыкающих слэшей! (См. часть 2 по этому поводу). Синтаксис простой:

login-name@hostname:/полный-путь-к-директории

Что касается резервного копирования по расписанию без участия человека, то это просто, как дважды два.
Сделаем запись в файле /etc/crontab - замечательно простой способ использовать cron. Следующий пример запускает скрипт резервного копирования каждый рабочий день в 23:05:

23 5   * * 1-5   carla /home/carla/backupscript

Для знакомства с опциями смотрите man 5 crontab.

Диагностика и ссылки

Помните, если что-то идет не так, "разговорчивость" выхода команды rsync можно повысить, давая несколько опций "-v", вот так: -vv. Не забывайте также об опции --dry-run (холостой прогон) для тестирования правильности команды. man rsync отличается тщательностью и детальностью, а поиски в Интернете дадут сотни статей про команду rsync.
Гуру дадут вам еще множество способов усложнить и усовершенствовать команду rsync, что вы тоже сможете проделать.

Мы же в этой статье ставили задачу выработать простой портативный метод создания резервных копий, использующий универсальные утилиты Линукс (OpenSSH, rsync, scripting, и udev), и применимый на любой Линукс системе. Еще важнее, что резервные копии легко доступны - вы можете подключить съемный диск к любой Линукс или Виндоуз машине и восстановить информацию. Этот метод будет работать также на выделенном для резервных копий сервере, хотя для этого существуют лучшие и более безопасные методы, о которых мы поговорим когда-нибудь в будущем.

Ресурсы:

rsync

OpenSSH

Easy Automated Snapshot-Style Backups with Linux and Rsync

Моя личная поваренная книга Linux
содержит неплохую статью про создание резервных копий и восстановление поврежденных файлов.