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

Существует множество подходов к созданию резервных копий в Linux. Они варьируются от простых методов, основанных на выполнении сценариев, до использования сложных коммерческих продуктов.

Вопрос, что именно вам копировать и каким способом решать непосредсвенно вам в зависимости от причины и целей.

Так как основная идея в концепции Linux - "все есть файл", то процесс копирования и резервирования фактически представляет собой архивирование и разархивирование файлов.

Вот некоторые каталоги, которые имеет смысл копировать:

• /etc
  Содержит все ваши ключевые конфигурационные файлы. В их число входят сетевые настройки, имя системы, правила брандмауэра, пользователи, группы и другие системные элементы.
• /var
  Содержит информацию, используемую вашими системными демонами (службами), в том числе настройки DNS, DHCP leases, файлы почтового буфера, файлы HTTP сервера, конфигурации db2 и другие.
• /home
  Содержит домашние каталоги по умолчанию для всех ваших пользователей. Хранит данные о персональных настройках, загруженных файлах и другую ценную для ваших пользователей информацию.
• /root
  Домашний каталог привилегированного пользователя root.
• /opt
  Каталог, для несистемного программного обеспечения. Сюда устанавливается программное обеспечение IBM. , JDKs и другое программное обеспечение по умолчанию так же устанавливается в этот каталог

Ниже приведены каталоги, для которых не надо выполнять резервное копирование.

• /proc
  Никогда не выполняйте резервное копирование для этого каталога. В нем лежат не реальные файлы, а лишь виртуальный образ работающего ядра и среды. Он содержит такие файлы, как /proc/kcore -- виртуальный образ всей используемой памяти. Копирование этого каталога -- лишь пустая трата ресурсов.
• /dev
  Содержит файловое представление ваших аппаратных устройств. Вы можете выполнить резервное копирование каталога /dev, если планируете начинать восстановление с пустой системы. Однако, если вы планируете восстановление с уже инсталлированным Linux, то нет необходимости копирования /dev.

Другие директории содержат системные файлы и установленные программные пакеты. В случае сервера большая часть этой информации остается неизменной. Большинство изменений происходит в каталогах /etc и /home. Но для полноты вы можете скопировать и их.

Средства резервного копирования

Так как резервное копирование в Linux заключается, главным образом, в архивировании и разархивировании файлов. Это позволяет вам использовать существующие системные утилиты и писать сценарии для выполнения резервного копирования и не покупать коммерческое программное обеспечение. В большинстве случаев такой резервной копии достаточно, и это предоставляет администратору широкие возможности для контроля ситуации. Запуск сценария резервного копирования можно автоматизировать, используя команду cron, которая в Linux управляет выполнением запланированных событий.

tar -- это классическая команда Unix, которая была перенесена в Linux. tar -- это аббревиатура tape archive, изначально эта команда была предназначена для архивирования файлов на магнитную ленту. Если вы загружали какой-нибудь Linux код, то, скорее всего, вы уже сталкивались с tar файлами. Это файловая команда, которая последовательно компонует файлы в непрерывную цепь.

Благодаря тому, что команда tar может архивировать целые деревья каталогов, она особенно хорошо подходит для создания резервных копий. Восстановление можно выполнять для архивов целиком, либо для отдельных файлов и каталогов. Резервные копии могут размещаться на файловых устройствах или на магнитной ленте. При восстановлении файлы могут быть перенаправлены и размещены в каталоге (или системе), отличном от того, с которого были сохранены. Команда tar не зависит от файловой системы. Она может использоваться в файловых системах ext2, ext3, jfs, Reiser и т.д.

Команда tar в использовании очень похожа на файловую служебную программу, такую как PKZip. Вы указываете ей исходный объект, который может быть файлом или устройством и затем перечисляете файлы, которые хотите запаковать. По ходу дела вы можете сжать архив, используя стандартные типы сжатия, или использовать для этих целей внешнюю программу сжатия, на ваш выбор. Используйте tar -j, чтобы сжимать или извлекать файлы из архива при помощи утилиты bzip2, или tar -j, чтобы сжимать или извлекать файлы из архива при помощи утилиты gzip.

Для того чтобы используя tar создать на ленточном SCSI-устройстве резервную копию всей системы, кроме каталога /proc, введите:

tar -cpf /dev/st0 / --exclude=/proc

В приведенном выше примере, ключ -c указывает на то, что создается архив. Ключ -p нужен для того, чтобы сохранить права доступа для файлов, что является необходимым условием для хорошего резервного копирования. Ключ -f указывает на имя файла для архива. В данном случае мы используем накопитель на магнитной ленте /dev/st0. Символ / задает, что именно мы хотим копировать. Поскольку в нашем случае это вся файловая система, то указан корневой каталог. При ссылке на каталог (в конце которого стоит символ /) tar автоматически рекурсивно обходит все подкаталоги. И, наконец, мы исключаем каталог /proc, поскольку он не содержит ничего ценного для нас. Если резервная копия не умещается на одной магнитной ленте, то мы добавим ключ -M (здесь не показан) -- указание на многотомный архив.

Чтобы восстановить файл или файлы, команда tar используется с ключом extract (-x):

tar -xpf /dev/st0 -C /

Ключ -f снова ссылается на наш файл, а -p указывает на то, что мы хотим восстановить заархивированные данные, сохранив права доступа. Ключ -x указывает на восстановление из архива. Ключ -C / указывает на то, что восстановление должно производится в корневой каталог. Команда tar по умолчанию восстанавливает архив в тот каталог, из которого была запущена. Ключ -C запрещает восстановление в текущий каталог.

Две другие команды tar, которые вы, скорее всего, будете часто использовать -- это ключи -t и -d. Ключ -t выводит содержимое архива. Ключ -d сравнивает содержимое архива с текущими файлами в системе.

Для облегчения работы и редактирования вы можете записать файлы и каталоги, которые вы хотите архивировать, в текстовый файл, на который можно сослаться при помощи ключа -T. Их можно комбинировать с другими каталогами, указанными в командной строке. В следующем примере производится резервное копирование всех файлов и каталогов, включенных в файл MyFiles, каталога /root, и всех файлов с расширением iso из каталога /tmp.

tar -cpf /dev/st0 -T MyFiles /root /tmp/*.iso

Список файлов представляет собой простой текстовый файл, содержащий файлы и каталоги в виде списка. Вот пример такого файла:

/etc
/var
/home
/usr/local
/opt

Обратите внимание, что команда tar -T (или files-from) не воспринимает шаблон. Имена файлов должны быть указаны точно. В примере выше продемонстрирован способ сослаться на файлы отдельно. Вы также можете выполнить скрипт, который проведет поиск в системе и создаст список. Вот пример такого скрипта:

#!/bin/sh
cat MyFiles > TempList
find /usr/share -iname *.png >> TempList
find /tmp -iname *.iso >> TempList
tar -cpzMf /dev/st0 -T TempList

Скрипт, приведенный выше, копирует весь существующий список файлов из MyFiles в TempList. Затем он выполняет две команды find для поиска в файловой системе файлов, удовлетворяющих определенному условию, и добавляет их в TempList. Первая команда поиска ищет в каталоге /usr/share все файлы, заканчивающиеся на.png. Вторая команда поиска ищет в каталоге /tmp все файлы, заканчивающиеся на.iso. После создания списка запускается команда tar, которая создаст новый архив (create) на файловом устройстве (file device) /dev/st0 (первый SCSI-носитель на магнитной ленте), который будет сжат в формате gzip с сохранением всех прав доступа для файлов (permissions). Архив будет разбит на несколько томов (Multiple volumes). Имена файлов, которые должны быть заархивированы будут взяты (Taken) из файла TempList.

Команды dump и restore

Команда dump выполняет практически те же функции, что и tar . Однако она скорее предназначена для работы с файловыми системами, а не отдельными файлами. Цитируя из руководства к dump : "dump проверят файлы файловой системы ext2 и решает, какие файлы нуждаются в резервном копировании. Эти файлы копируются для сохранности на указанный диск, магнитную ленту или другой носитель данных. Дамп, размер которого больше, чем размер носителя на выходе, разбивается на несколько томов. На большинстве носителей этот размер определяется путем записи до тех пор, пока не будет получен сигнал о переполнении носителя."

Программу dump дополняет программа restore , используемая для восстановления сохраненных файлов из дампа.

Команда restore выполняет функцию, обратную команде dump. После восстановления всей файловой системы поверх можно восстанавливать инкрементальные резервные копии. Из полной или инкрементальной копии могут быть восстановлены и одиночные файлы и директории с подкаталогами.

Как dump так и restore можно запустить по сети, то есть вы можете выполнять архивацию или восстановление с удаленных устройств. Команды dump и restore работают с ленточными и файловыми устройствами и обладают большим набором опций. Однако эти команды ограничены только файловыми системами ext2 и ext3. Если вы работаете с JFS, Reiser или другими файловыми системами, вам необходима другая утилита, например tar.

Резервное копирование с использованием dump

С помощью команды dump резервную копию сделать довольно просто. Приведенная ниже команда выполняет полное резервное копирование Linux с файловыми системами ext2 и ext3 на SCSI ленточное устройство:

dump 0f /dev/nst0 /boot
dump 0f /dev/nst0 /

В этом примере в нашей системе используются две файловые системы. Одна для каталога /boot, а другая для / -- стандартная конфигурация. При выполнении копирования на каждую из них надо ссылаться по отдельности. /dev/nst0 ссылается на первое ленточное SCSI устройство, использующуюся в режиме без перемотки. Этот режим гарантирует, что тома на ленте будут следовать четко друг за другом.

Интересной особенностью команды dump является встроенная функциональная возможность создания инкрементальной резервной копии. В примере выше 0 указывает на уровень 0 или на базовый уровень резервной копии. Такое копирование всей системы вам следует выполнять периодически для охвата системы целиком. Для изменения уровня последующих резервных копий вы можете использовать другие номера (1-9) вместо 0. При резервном копировании уровня 1 будут сохранены все файлы, которые были изменены с момента создания копии уровня 0. При копировании уровня 2 будет сохранено все, что было изменено с момента создания копии уровня 1 и так далее. То же самое можно выполнить с помощью команды tar, используя скрипт, но для этого необходимо, чтобы человек, пишущий скрипт, имел механизм для определения, когда было проведено последнее копирование. Команда dump обладает собственным алгоритмом, обновляющим update-файл (/etc/dumpupdates) при проведении резервного копирования. Update-файл сбрасывается в исходное состояние всякий раз, когда происходит резервное копирование нулевого уровня. При копировании последующих уровней ставятся метки вплоть до того момента, когда произойдет следующее копирование нулевого уровня. Если вы собираетесь проводить копирование на ленточные устройства, dump автоматически произведет деление на тома

Для восстановления информации, сохраненной с помощью команды dump, используется команда restore. По аналогии с tar, команда restore может вывести содержимое архива (-t) и сравнить архивы с текущими файлами (-C). Будьте внимательны с командой restore при восстановлении данных. Существует два различных подхода и для того, чтобы получить предсказуемые результаты, вы должны выбрать верный.

Воссоздание (-r)

Помните, что команда dump предназначена скорее для работы с файловой системой, чем с отдельными файлами. Поэтому существуют два различных способа восстановления данных. Для воссоздания файловой системы используйте ключ -r. Воссоздание по замыслу должно производиться на пустой файловой системе и восстанавливать ее сохраненное состояние. Перед началом воссоздания у вас должна быть созданная, отформатированная и подмонтированная файловая система. Не выполняйте воссоздание в файловой системе, содержащей файлы.

Вот пример полного воссоздания из дампа, выполненного в примере выше.

restore -rf /dev/nst0

Такая команда должна быть выполнена для каждой файловой системы, требующей восстановления.Процедуру можно повторять, добавляя, при необходимости, инкрементные резервные копии

Извлечение (-x)

Если вам надо работать с отдельными файлами, а не с целыми файловыми системами, используйте для извлечения ключ -x. Например, чтобы извлечь один каталог /etc из архива на ленточном накопителе, выполните следующую команду:

restore -xf /dev/nst0 /etc

Интерактивное восстановление (-i)

Еще одна возможность, заложенная в команду restore, -- это диалоговый режим. Выполнив команду:

restore -if /dev/nst0

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

dump или tar?

Обе команды, dump и tar, имеют своих почитателей. У каждой есть свои преимущества и недостатки. Если вы используете файловые системы, отличные от ext2 или ext3, то dump вам не подходит. Однако, в противном случае, команда dump позволит сократить до минимума использование скриптов и, кроме того, облегчит процесс восстановления благодаря наличию интерактивного режима.

Лично я предпочитаю использовать команду tar, поскольку я люблю писать скрипты, потому что они обеспечивают высокий уровень контроля. Кроме того, существуют многоплатформенные средства для работы с файлами.tar.

Другие утилиты

В принципе, любую программу, которая может копировать файлы, можно использовать для выполнения того или иного вида резервного копирования в Linux. Некоторые люди используют для создания резервных копий программы cpio и dd. cpio -- утилита архивации, похожая на tar. Она гораздо менее распространена. dd -- это утилита копирования файловой системы, создающая бинарные копии файловой системы. Утилиту dd можно использовать для создания образа жесткого диска в духе таких программных продуктов, как Symantec Ghost. Однако dd – это не файловая утилита, поэтому вы можете восстанавливать данные только на идентичные разделы жесткого диска.

Коммерческие программные продукты для резервного копирования

Существует несколько коммерческих программ резервного копирования, предназначенных для Linux. Коммерческие продукты обычно предоставляют удобный интерфейс и систему отчетности, в то время как, используя утилиты dump и tar, вам придется обойтись без этих удобств. Коммерческие программы предлагают широкий выбор функций. Наибольшая польза, которую могут принести коммерческие пакеты, – это предложить вам уже готовую для использования встроенную стратегию выполнения резервного копирования. Разработчики таких программ в свое время уже прошли через все те ошибки, что вам еще только предстоит сделать, и плата за их опыт невелика, по сравнению с потерей важных данных.

Оставьте свой комментарий!

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

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

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

Чтобы упростить освоение материала, в данной статье используется пошаговый подход.

Мы начнем с простого, но эффективного механизма архивирования, а затем перейдем к расширенному решению для распределенного резервного копирования. Взгляните на удобный скрипт arc, позволяющий создавать резервные копии из командной строки Linux.

Листинг 1. Shell-скрипт arc

Скрипт arc принимает в качестве параметра путь к файлу или каталогу, после чего создает архивный файл, имя которого содержит текущую дату. Например, для архивирования каталога beoserver скрипту arc необходимо передать путь к нему, после чего будет сформирован сжатый архив, имеющий имя приблизительно следующего вида: beoserver.20040321-014844.tgz

Упорядочить архивные файлы поможет включение в их имена даты и времени с помощью команды date . Дата имеет следующий формат: год, месяц, день, час, минуты, секунды - секунды, вероятно, в нашем случае уже лишние. О параметрах команды date можно узнать из ее руководства, просмотреть которое можно командой man date . Кроме того, в листинге 1 мы используем параметр -v (verbose, подробно) команды tar . Команда tar , запущенная с данным параметром, отображает имена всех архивируемых файлов. Если этого не требуется, параметр -v можно убрать.

Листинг 2. Архивирование каталога beoserver

Сложные схемы резервного копирования

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

Мы будем решать эту проблему в следующем примере, основанном на некоторой распределенной сети, схема которой, приведенная на рисунке 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 [email protected]

После входа на сервер внешнего хранилища создайте пару из открытого и секретного ключей, запустив программу ssh-keygen с параметром -t dsa . Параметр -t является обязательным и используется для указания типа ключа шифрования, который требуется сгенерировать. Мы воспользуемся алгоритмом Digital Signature Algorithm (DSA), позволяющим применять новый протокол SSH2. Дополнительную информацию по данному вопросу можно получить, ознакомившись с руководством к программе ssh-keygen.

После запуска ssh-keygen вам будет предложено указать каталог, в котором будут созданы файлы ssh-ключей, после чего будет запрошен пароль. Если на вопрос о каталоге для сохранения ключей ответить простым нажатием Enter, программа создаст скрытый каталог.ssh (если он не был создан ранее), в котором будут находиться два файла, содержащие открытый и секретный ключи.

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

Листинг 3. Старайтесь выбрать хорошую парольную фразу

Поскольку каталог.ssh, создаваемый ssh-keygen, является скрытым, чтобы его увидеть, необходимо выполнить команду ls с параметром -a .

$ ls -a
. .. .bash_logout .bash_profile .bashrc .emacs .gtkrc .ssh

Перейдите в скрытый каталог.ssh и выведите его содержимое:

$ cd .ssh
$ ls -lrt
id_dsa id_dsa.pub

Видно, что в скрытом каталоге.ssh находятся файлы секретного (id_dsa) и открытого (id_dsa.pub) ключей. Просмотреть содержимое этих файлов можно с помощью текстового редактора, например, vi или emacs, или воспользовавшись командами less или cat. При просмотре содержимого файлов вы увидите, что оно состоит из алфавитно-цифровых символов кодировки base64.

Листинг 4. Установка открытых ключей на удаленные серверы

После установки новых открытых ключей мы сможем заходить на каждый из серверов, используя парольную фразу, указанную при создании открытого и секретного ключей. А пока войдите на каждый из серверов и добавьте содержимое файла offsite.pub в конец файла authorized_keys, находящегося в каталоге.ssh. Это можно сделать с помощью текстового редактора или команды cat:

Листинг 5. Добавление offsite.pub к списку авторизованных ключей

На следующем шаге мы примем дополнительные меры безопасности. Сначала мы изменим права доступа к.ssh таким образом, чтобы доступ к данному каталогу на чтение, запись и выполнение имел только его владелец. Затем мы убедимся, что доступ к файлу authorized_keys имеет только его владелец. И наконец, мы удалим за ненадобностью ранее загруженный файл открытого ключа offsite.pub. Очень важно правильно назначить права доступа, поскольку сервер OpenSSH может отказать в использовании ключей, для файлов которых заданы небезопасные права доступа.

Листинг 6. Изменение прав доступа командой chmod

После выполнения этого процесса на сервере 2 мы перейдем на сервер внешнего хранилища для проверки работы нового способа доступа, основанного на парольной фразе. Сделать это можно, выполнив следующую команду на сервере внешнего хранилища:

$ ssh -v [email protected]

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

Автоматизация доступа к компьютеру с помощью ssh-агента

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

Давайте взглянем на программу ssh-agent поближе. Ssh-agent выводит команды:

Листинг 7. ssh-agent в действии

Мы можем указать оболочке выполнять команды, выводимые программой ssh-agent, с помощью встроенной команды eval:

$ eval `ssh-agent`
Agent pid 14198

Команда eval вычисляет (выполняет) команды, генерируемые программой ssh-agent. Убедитесь, что используются именно обратные (`), а не одинарные кавычки! Команда eval `ssh-agent` возвращает идентификатор процесса агента. Незаметно для нас были экспортированы переменные оболочки SSH_AUTH_SOCK и SSH_AGENT_PID . Их значения можно просмотреть путем вывода в консоль следующей командой:

$ 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 для входа на сервер без лишних трудностей

Теперь при получении доступа к server1 парольная фраза запрашиваться не будет:

$ ssh [email protected]
$ exit

Если приведенный пример кажется вам неубедительным, попробуйте выгрузить (kill -9) процесс ssh-agent и повторно подключиться к server1. В этом случае вы заметите, что server1 запросит парольную фразу секретного ключа, хранящегося в файле id_dsa, который находится в каталоге.ssh.

$ kill -9 $SSH_AGENT_PID
$ ssh [email protected]
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-сайта проекта (ссылка приведена в разделе ).

Работать со скриптом, после того как вы его загрузите и установите, очень просто. Просто зайдите на каждый из серверов и добавьте следующие две строки в конец файлов.bash_profile:

keychain id_dsa
. ~/.keychain/$HOSTNAME-sh

Когда вы зайдете на серверы в следующий раз, keychain запросит парольную фразу. При последующих входах, однако, ввод парольной фразы не будет запрашиваться до момента перезагрузки сервера. И, что самое главное, задачи cron смогут осуществлять безопасный доступ к удаленным машинам без ввода пароля. Теперь наше решение совмещает преимущества повышенной безопасности и простоты использования.

Листинг 9. Инициализация keychain на каждом сервере

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

Нашей следующей задачей является написание скриптов, выполняющих операции, необходимые для резервного копирования. Целью работы данных скриптов будет создание полной резервной копии баз данных, находящихся на серверах server1 и server2. На каждом из серверов в рассматриваемом примере установлена СУБД MySQL. Соответственно для экспорта нескольких таблиц в виде SQL-скрипта мы будем использовать утилиту mysqldump, работающую в командной строке.

Листинг 10. Скрипт dbbackup.sh для сервера 1

На сервере 2 мы разместим аналогичный скрипт, осуществляющий резервное копирование уникальных таблиц установленной на нем БД. Для каждого из скриптов необходимо задать признак исполняемого файла, выполнив команду:

:$ chmod +x dbbackup.sh

Разместив копии файла dbbackup.sh на серверах 1 и 2, мы возвращаемся на сервер внешнего хранилища, где создаем скрипт, выполняющий их перед запуском процесса удаленного копирования сжатых архивов (.tgz).

Листинг 11. Скрипт backup_remote_servers.sh для размещения на сервере внешнего хранилища

Скрипт backup_remote_servers.sh использует ssh для удаленного выполнения скриптов на серверах. Поскольку доступ, организованный нами, не требует ввода пароля, программа ssh может удаленно выполнять команды на серверах 1 и 2 с сервера внешнего хранилища. Благодаря keychain процесс аутентификации происходит полностью автоматически.

Планирование задач

Наша следующая и последняя задача заключается в планировании выполнения скрипта backup_remote_servers.sh на сервере внешнего хранилища. Для этого мы добавим в конфигурационный файл планировщика cron две новые записи, согласно которым скрипт резервного копирования будет запускаться дважды в день - в 3:34 и в 20:34. Чтобы добавить записи, запустите на сервере внешнего хранилища программу crontab с параметром -e .

:$ crontab -e

Программа crontab запустит используемый по умолчанию текстовый редактор, указанный в переменных среды VISUAL или EDITOR . Теперь введите две новые записи, после чего сохраните и закройте файл.

Листинг 12. Записи crontab на сервере внешнего хранилища

Запись файла crontab состоит из двух основных частей: спецификации времени выполнения и команды, подлежащей выполнению. Спецификация времени выполнения включает следующие поля:

Листинг 13. Формат записи crontab

Верификация резервных копий

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

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

Дополнительные меры обеспечения информационной безопасности

Для повышения уровня информационной безопасности можно установить и настроить на каждом сервере систему обнаружения вторжений (Intrusion Detection System, IDS), например, Snort. Система обнаружения вторжений предназначена для оповещения о попытках взлома системы, происходящих в данный момент или имевших место недавно. Наличие такой системы позволит наращивать уровень информационной безопасности за счет применения таких технологий как цифровая подпись и шифрование резервных копий.

Архивные файлы можно защитить с помощью распространенных инструментов с открытым исходным кодом, например GNU Privacy Guard (GnuPG), OpenSSL и ncrypt, однако, применять их без дополнительного уровня защиты, предоставляемого системой обнаружения вторжений, не рекомендуется (ссылки на дополнительную информацию по Snort приведены в разделе ).

Заключение

В статье было продемонстрировано удаленное выполнение скриптов на серверах и осуществление безопасного автоматического копирования файлов. Я надеюсь, что ее прочтение дало вам информацию для размышлений о том, как защитить ваши ценные данные с помощью таких инструментов с открытыми исходными кодами, как OpenSSH и Snort.

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

Если вы пользуетесь Linux, то в нем найдете на выбор много программ резервного копирования. Ниже приведен список их нескольких лучших бесплатных программ резервного копирования с открытым исходным кодом, которые можно опробовать.

Является Linux-эквивалентом Time Machine от Apple, базирующимся на GNOME. Как и многие другие утилиты резервного копирования, этот пакет создает инкрементные резервные копии файлов (сохраняет только изменения относительного некоторого первоначального состояния - прим.пер.), которые позже могут быть использованы для восстановления. Его мгновенные снимки являются копиями директория в определенный момент времени. Снимки, сделанные для файлов, которые не изменились с момента предыдущего снимка, занимают очень мало места. Это связано с тем, что вместо создания резервной копии всего файла без его изменения, в снимках используется жесткая связь с существующей резервной копией файла в ее первоначальном состоянии.

Является клоном Symantec Ghost Corporate Edition с открытым исходным кодом. Пакет базируется на использовании DRBL, образов разделов, ntfsclone, partclone и udpcast, что позволит вам получать слепок данных для резервного копирования и восстановления. В наличии есть два варианта пакета Clonezilla: Clonezilla live и Clonezilla SE (Server Edition - серверная редакция). Clonezilla live подходит для резервной копирования и восстановления одной машины. А Clonezilla SE предназначен для массового развертывания и может одновременно делать клоны многих компьютеров.

Делает копии директориев, создавая зашифрованные тома в формате tar и загружает их на удаленный или локальный файл-сервер. Поскольку Duplicity использует librsync, инкрементные архивы экономно используют место и записывают только те части файлов, которые были изменены с предыдущего резервного копирования. Поскольку Duplicity использует GnuPG для шифрования и / или подписывания этих архивы, они защищены от шпионажа и / или изменения их на сервере.

Является системой резервного копирования уровня предприятия, имеющей открытый код и предназначенной для гетерогенных сетей. Пакет создан для автоматизации задач, выполнение которые часто требует вмешательства системного администратора или оператора. В Bacula есть клиенты резервного копирования Linux, UNIX и Windows, а также можно использовать ряд профессиональных устройств резервного копирования, в том числе библиотеки ленточных накопителей. Администраторы и операторы могут конфигурировать систему при помощи консоли с командной строкой, графического интерфейса GUI и веб-интерфейса; в качестве сохраняемых данных используется информационный каталог, который может храниться в MySQL, PostgreSQL или SQLite.

(Advanced Maryland Automatic Network Disk Archiver - улучшенный автоматический архиватор сетевых дисков из Мэриленд) является системой резервного копирования, которая позволяет администратору настроить один главный сервер резервного копирования большого количества сетевых хостов на ленточные накопители или оптические носители. AMANDA использует дамп данных и / или GNU tar и может выполнять резервное копирование большого числа рабочих станций, работающих под различными версиями Unix.

Материал приведен исключительно в ознакомительных целях. Если же вы собираетесь воспроизводить действия, описанные ниже, настоятельно советуем внимательно прочитать статью до конца хотя бы один раз. Редакция 3DNews не несет никакой ответственности за любые возможные последствия.

Программ для резервного копирования в среде Linux действительно не так уж много. Часть из них для домашнего использования не очень пригодна, так как они не всегда просты в настройке, хоть и позволяют делать резервное копирование и архивацию сотен серверов. Но нам ведь нужно всего ничего — надёжно сохранить свои файлы. По-хорошему, все важные данные должны храниться отдельно от системы, а ещё лучше — на другом физическом диске. Что касается самой ОС, то, как правило, нужно делать бэкапы для корневых каталогов home да etc и изредка некоторые подкаталоги из var или usr/local. Идеальный вариант — регулярное снятие образа всей системы. Впрочем, начать стоит хотя бы с документов. Нам даже не придётся устанавливать дополнительное ПО, так как в последней версии Ubuntu по умолчанию ставится утилита Déjà Dup. Ей-то мы и займёмся.

Déjà Dup

Эта программа играет роль стандартной системы резервного копирования (наподобие той, что встроена в Windows 7), начиная с Ubuntu 11.10. К сожалению, многие пользователи не то что не хотят ставить какие-то дополнительные утилиты для бэкапа, но и встроенными в ОС возможностями не пользуются. Как правило, до первой серьёзной потери своих данных. Немного спасают сервисы облачной синхронизации данных. В них можно хранить и резервные копии для пущей надёжности. По умолчанию Déjà Dup использует для этих целей Ubuntu One , в котором бесплатно даётся 5 Гбайт.

Чтобы включить Déjà Dup, кликните по значку с шестерёнкой в правом верхнем углу основной панели, выберите пункт «Параметры системы…» и перейдите в раздел «Резервное копирование» — это и есть настройки Déjà Dup. В разделе «Носитель» указывается то место, куда будут складываться резервные копии. Утилита умеет копировать данные на FTP, SFTP, ресурсы WebDAV, в общую папку Windows (SMB) или же в любой каталог на локальной машине, а он, в свою очередь, вполне может принадлежать, например, Dropbox.

Пользователь волен добавить свои папки, которые попадут в архив, а также исключить ненужные каталоги. Можно включить автоматическое резервирование и задать срок хранения архивов. После окончания настройки рекомендуется сделать первую копию самостоятельно, а потом включить автоматический бэкап. Если вы выбрали хранение копий в Ubuntu One, то вас попросят авторизоваться. Также резервные копии можно защитить паролем. Обратите внимание, что Déjà Dup создаёт инкрементальные бэкапы, то есть сохраняются только изменённые с последнего момента синхронизации файлы.

Для хранения данных в облаках Amazon S3 или Rackspace надо дополнительно установить пакеты python-boto и python-rackspace-cloudfiles. Оба можно найти в «Центре приложений Ubuntu». Для восстановления файлов из резервной копии надо снова обратиться к разделу «Резервное копирование» в параметрах системы. Нас спросят, откуда мы будем восстанавливать данные, предложат выбрать дату и время нужного бэкапа, а также указать папку, куда будут скопированы резервные копии.

Чуть интереснее выглядят другие возможности Déjà Dup — восстановление удалённых файлов и откат к предыдущим версиям файла. Обе они интегрированы в стандартный файловый менеджер и доступны в меню «Файл» и «Правка» соответственно. Для того чтобы ими воспользоваться, надо перейти в нужную директорию или выбрать необходимый файл. Естественно, для работы этих функций должны иметься резервные копии, из которых и будет происходить восстановление или откат.

⇡ Back In Time

Если вам нужна чуть большая гибкость в настройке бэкапов, то можно воспользоваться утилитой Back In Time. Установить её можно всё в том же центре приложений, где вы найдёте версии GUI для KDE и GNOME. После установки появятся два ярлыка для запуска программы — c root-правами и без них. Первый вариант нужен только при работе с папками, к которым у вас нет прав доступа. При первом запуске откроется окно настроек. Утилита позволят создавать несколько профилей с различающимися настройками. Для начала надо будет указать каталог, куда будут сохраняться резервные копии, и частоту их создания. Затем выбрать сохраняемые папки и файлы, а также исключения. Для исключений можно задавать шаблоны имени файла или папки.

Главная же фишка Back In Time — это умное управление архивами с резервными копиями. Она также делает инкрементальные бэкапы. Автоматическое удаление архивов можно настроить так, чтобы у вас всегда были копии за разные периоды времени, но при этом место на накопителе не тратилось впустую. Среди прочих полезных опций стоит отметить возможность отслеживать изменения в файлах путём подсчёта хеш-сумм. Только учтите, что при большом числе часто меняющихся данных, а в особенности если эти данные присутствуют в виде очень больших файлов, данная опция будет создавать серьёзную нагрузку на систему.

Ну а дальше всё просто — утилита будет сама создавать бэкапы. Можно, конечно, и самому в любой момент запустить процесс резервного копирования. Все копии отображаются в виде списка в левой части окна — выбираете любую и восстанавливаете файлы и папки из неё. Back In Time по сути является удобной надстройкой над rsync. Если вам не нужны все её возможности, то используйте утилиты попроще и без автоматизации. Например, GRsync.

⇡ Duplicati

Эта кроссплатформенная утилита умудряется несколько чужеродно выглядеть во всех трёх ОС — Windows, Linux, Mac OS. Впрочем, на основных функциях это не сказывается. В стандартных репозиториях её нет, поэтому придётся скачать deb-пакет для Ubuntu и вручную установить его. Первый запуск сопровождается появлением мастера настройки бэкапа. Как обычно, нам предлагают задать его имя, выбрать резервируемые папки и файлы. Для пущей безопасности все архивы можно зашифровать в AES-256 и сгенерировать случайный и надёжный пароль. Он хоть и сохраняется в настройках программы, но всё равно нелишним будет записать его куда-нибудь.

Главная ценность Duplicati — это возможность сохранять архивы во множестве облачных сервисов, а точнее работа с API самых популярных из них и их совместимых клонов. Мы уже когда-то рассматривали использование Amazon S3 в качестве файлохранилища при работе в Windows. В качестве примера настроим Duplicati для работы с этим облаком. Нам нужны ключи доступа (Access Keys), которые можно найти в разделе Security Credentials вашего аккаунта . Копируем их в соответствующие поля, выбираем имя для нового bucket, регион размещения и, если хочется, включаем использование RRS. Нажимаем Test Connection и соглашаемся с переименованием bucket.

Помимо облачных сервисов для хранения данных, Duplicati может использовать локальные папки и FTP/SFTP/WebDAV-ресурсы, а также крайне любопытную распределённую P2P-файловую систему Tahoe-LAFS . Дальнейшие настройки профиля бэкапа — а именно: частота создания резервных копий и их тип (инкрементальные и/или полные), автоудаление старых копий, ограничения на занимаемую ширину канала и размеры файлов архива — совпадают для любого типа хранилища. Временные интервалы в этих параметрах указываются в секундах.

Для резервирования можно выбирать отдельные папки и файлы или, наоборот, исключать часть из них. В качестве шаблона для их имён не возбраняется использовать регулярные выражения. После завершения работы мастера откроется основное окно программы, где надо будет перейти в настройки (Options) и на первой вкладке указать в качестве используемого языка English, иначе в системах с русской локалью могут возникнуть некоторые проблемы. На вкладке SSH укажите путь до SFTP (/usr/bin/sftp).

Дальнейшая работа с утилитой сводится к запуску мастера, который поможет создать новый профиль для бэкапа, отредактировать или удалить уже имеющиеся профили, а также запустить процесс восстановления данных из резервной копии или же ручного создания оной. Опции восстановления стандартны — выбор профиля, даты и времени архива, отдельных файлов и папок, а также места, куда они будет восстановлены. Рекомендуем попробовать Duplicati обладателям не только Linux, но и других ОС.

Возможность случайного повреждения системы, даже такой надёжной как Linux, всегда существует. Как правило, переустановка ОС занимает много времени и сил. Чтобы избежать неприятностей подобного рода следует пользоваться резервным копированием (бэкап) Ubuntu Linux.

Создание бэкапа ubuntu через Rsync

Положительные стороны создания бэкапа убунту именно при помощи rsync заключаются в том, что для копирования и восстановления системы нет необходимости в установке дополнительных пакетов и ПО. Всё делается при помощи консоли. Но не пугайтесь работы с консолью! В нашем случае всё будет предельно просто и понятно.

Пару слов о rsync:

Данная команда является очень мощным инструментом для работы с файлами. Ознакомиться с полным списком её возможностей можно написав в консоли man rsync . Предлагаемый метод резервного копирования ubuntu через rsync является самым простым и лёгким в освоении.

Бэкап Ubuntu на личном опыте

Чтобы всё было предельно просто - расскажу как у меня происходит backup системы. Мой жесткий диск разбит на 5 разделов, из которых 2 раздела отведено под Ubuntu - системный раздел / и раздел для информации пользователей /home . Я копирую всё содержимое системного раздела / на раздел пользователей в специальную папку /home/.backup . В случае неполадок ОС Ubuntu я запускаюсь с LiveCD и просто копирую бэкап убунту на системный раздел. Основываясь на этом примере ниже будет описана процедура резервного копирования и восстановления Ubuntu Linux.

Резервное копирование (бэкап) Ubuntu

Выполняем в консоли:
sudo rsync -aulv -x / /windows/FILES/.backup/
А теперь давайте разберёмся с синтаксисом этой нехитрой команды

• sudo - получаем права суперпользователя root;
• rsync - выполняем команду резервного копирования и задаём дополнительные аргументы -aulv и -x ;
• / -раздел, который подлежит копированию (системный раздел);
• /windows/FILES/.backup/ - место куда будут скопированы файлы (раздел пользователей).

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

Восстановление Ubuntu через rsync

Допустим, у нас накрылась система и нужно восстановить убунту . Запускаем компьютер при помощи LiveCD с Linux, открываем консоль. Теперь нужно примонтировать (подключить) системный раздел и раздел пользователей, чтобы совершить восстановление системы и здесь можем пойти двумя путями. Первый способ основан на кликах мышки, а второй - на работе в консоли.

Способ №1

Открываем файловый менеджер и видим в левом углу список разделов жесткого диска на ПК. Подключаем их нажатием мышки, после чего они станут доступны для обзора, а их точка монтирования будет находится в директории /media/ . Определяем какой из разделов системный, а какой пользовательский. Недостаток такого способа в том, что разделы получат сложный адрес точки монтирования вроде /media/2F45115E1265048F . Запоминаем адрес точки монтирования системного и пользовательского разделов. Теперь переходим к непосредственному восстановлению, пропускаем раздел «Способ №2″.

Способ №2

Для более продвинутых пользователей. Плюс в том, что мы сами назначим имя точкам монтирования и сможем обойтись без громозких адресов.
1. Выводим список разделов HDD:
sudo fdisk -l
эта команда покажет нам полный список разделов, имеющихся в системе. К примеру, у меня вот такая картинка.
Устр-во Загр Начало Конец Блоки Id Система
/dev/sda1 771120 27342629 13285755 83 Linux
/dev/sda2 27342630 822190634 397424002+ 83 Linux
/dev/sda3 * 822190635 883639259 30724312+ 7 HPFS/NTFS/exFAT
/dev/sda4 883639260 976768064 46564402+ 5 Расширенный
/dev/sda5 883639323 976768064 46564371 7 HPFS/NTFS/exFAT

В столбце «Система» легко увидеть, что файловая система Linux располагается на разделах:

1. dev/sda1
2. dev/sda2

2. Монтируем Linux разделы командой mount. Для этого сперва создадим точку монтирования для каждого раздела:
sudo mkdir /media/1
sudo mkdir /media/2
Используем mount чтобы примонтировать разделы:
sudo mount dev/sda1 /media/1
sudo mount dev/sda2 /media/2
3. Определяем какой из разделов является системным, а какой есть папка пользователя. Можем либо просто зайти через файловый менеджер в примонтированные каталоги и посмотреть какой из них системный. Или же, воспользуемся командой ls (показывает список файлов по заданному адресу):
ls /media/1
ls /media/2
Если Вы не слишком опытный пользователь - подскажу, что системный раздел Linux, как правило, будет иметь следующие папки: bin, boot, dev, etc, mnt и т. д.
Допустим мы установили, что системный раздел сейчас примонтирван по адресу /media/1 .

Непосредственное восстановление

1. Копируем файлы из резервной копии. Используем такую же команду:
sudo rsync -aulv -x /media/2/.backup/ /media/1/

при использовании графического способа №1 вместо /media/1/ и /media/2/ у вас будут другие точки монтирования!

2. Отмонтируем разделы по окончанию копирования:
sudo umount /media/1
sudo umount /media/2
Перезагружаем компьютер и наслаждаемся восстановленной из бэкапа Ubuntu.