Программы резервного копирования linux. Резервное копирование Ubuntu

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

Если вы - пользователь 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.

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, вам придется обойтись без этих удобств. Коммерческие программы предлагают широкий выбор функций. Наибольшая польза, которую могут принести коммерческие пакеты, – это предложить вам уже готовую для использования встроенную стратегию выполнения резервного копирования. Разработчики таких программ в свое время уже прошли через все те ошибки, что вам еще только предстоит сделать, и плата за их опыт невелика, по сравнению с потерей важных данных.

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

Многие задаются вопросом о том как сохранить собственные настройки системы, и личные данные так, чтобы потом в случае непредвиденных обстоятельств можно было их легко восстановить. Насколько мне известно в Windows и Mac OS X с этим проблем нет, так как средства для резервоного копирования предустановлены в обоих операционных системах. Ни в одном дистрибутиве Linux опробованных мной я не видел инструментов по умолчанию идущих с системой предоставляющих такой функционал. Если быть точным, то средства для резервного копирования в Linux есть по умолчанию, но не все новички знают о них и тем более не знают как использовать эти инструменты.

Существует три основных способа для создания резервной копии данных и системы в Linux

• Использование архиватора для создания сжатой копии системы
• Снятие образа жесткого диска
• Использование специальных, дополнительных утилит

На мой взгляд первый способ самый универсальный и применим практически в любой ситуации. Достоинства этого метода в том, что архив с резервной копией занимает не так уж много места и существует возможность выбора что включать в бэкап, а что исключить.
Для первого способа нам потребуется целевая система установленная на разделе/разделах жесткого диска и флешка/DVD диск с Live системой. Например Live CD с которого Вы ставили систему. Стоит заметить, что потребуется также раздел на который нужно сохранить данные. Его также нужно примонтировать
Итак предположим что ОС установлена на первом разделе первого жесткого диска (/dev/sda1). Загружаемся с Live CD и монтируем этот раздел скажем в /mnt

Sudo mount /dev/sda1 /mnt

Монтируем раздел на котором предполагается разместить бэкап

Sudo mkdir /backup sudo mount /dev/sda3 /backup

Используемая в Linux команда ls -a /mnt поможет проверить тот ли раздел мы смонтировали. Если вышла ошибка, то следует запустить cfdisk и найти нужный раздел после чего примонтировать его как показано выше.
Далее переходим в директорию примонтированного раздела с системой и смотрим какие директории в ней мы будем бэкапить.

Cd /mnt ls -a

Увидев список директорий включаем нужные в бэкап.

Sudo su tar -cvjpf /backup/Backup.tar.bz2 bin boot dev etc home lib lib32 lib64 media mnt opt proc root sbin sys tmp usr var

Если у Вас немного другой набор директорий, например отсутствуют каталоги lib32 и lib64, то советую просто архивировать все директории созданные не Вами. С директориями созданными Вами поступайте на свое усмотрение. В некоторых мануалах советуют исключить из бэкапа /proc, /dev, /sys, но я наученный собственным опытом скажу, что этого делать не стоит. Бэкап должен быть полным и включать все системные директории. При монтировании директорий с виртуальными файловыми системами таких как /proc и /sys их содержимое окажется пустым, но это избавит Вас от создания их вновь и присвоения им правильных разрешений (прав). Результатом выполнения этих действий будет появление в целевой директории /backup архива Backup.tar.bz2 содержащего резервную копию системы которую всегда можно восстановить.

Для того чтобы рекурсивно затарить все директории и файлы в текущей директории нужно:

Tar -cvjpf /backup/Backup.tar.bz2 .

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

Tar -cvjpf /backup/Backup.tar.bz2 . --exclude=cisco.jpg --exclude=folder

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

Sudo rm -rf /mnt/*

Копируем архив с бэкапом на целевой раздел

Sudo su cp /backup/Backup.tar.bz2 /mnt/

Переходим в нашу будущую систему и разархивируем бэкап

Cd /mnt tar -xvjpf Backup.tar.bz2

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

Sudo su dd if=/dev/sda1 bs=8M of=/backup/Backup.img

Если раздел был большой, то запасаемся терпением и идем пить чай/кофе или что то покрепче пока выполняется создание образа. Главное не пить "чего то покрепче" в больших количествах перед его восстановлением.
Восстановление еще проще: Нужно загрузиться с Live CD, примонтировать раздел на котором лежит бэкап и восстановить его командой (при условии что восстанавливаемая система по прежнему на /dev/sda1. Ошибки в лучшем случае грозят потерей коллекции прона тщательно отобранного Вами за последние годы проведенные в стадии полового созревания, а в худшем - разбитием монитора клавиатурой когда Вы осознаете чего лишились:-D).

Dd if=/backup/Backup.img bs=8M of=/dev/sda1

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

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

Оригинал: Backing up Linux and other Unix(-like) systems

Дата перевода: декабрь 2011 г.

«Люди делятся на две категории: одни уже делают бэкапы, а у других пока еще не отказывал жесткий диск», — неизвестный автор.

1. Введение

Тема резервного копирования рабочей Unix-подобной операционной системы (как правило, Linux) регулярно всплывает в списках рассылки и форумах, посвященных Linux. И неизменно кто-нибудь советует просто архивировать с помощью tar cvfz backup.tgz /bin /boot /etc ... К сожалению, для создания правильной резервной копии понадобится больше усилий. В этой статье я расскажу о многих (возможно, не обо всех) трудностях и деталях, на которые следует обратить внимание при резервном копировании.

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

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

Хотя мой личный опыт не выходит за рамки Linux, вопросы, обсуждаемые в этом тексте, должны (могут) относиться к большинству Unix-подобных систем.

2. Резервная копия — это не только данные

В правильном бэкапе сохраняются не только данные. Там содержатся и данные о данных: метаданные. Также копируются атрибуты конкретной файловой системы и файлы специальных устройств, необходимые для работы ОС. Жизненно важно, чтобы носитель резервной копии и программы для работы с ней могли обеспечить такое копирование. Например, категорически не рекомендую делать резервную копию файловой системы Ext3 (стандартная файловая система в Linux) на разделы, форматированные в FAT32/FAT16 (допотопная файловая система от Microsoft, все еще встречающаяся на USB-накопителях и подобных устройствах, хотя их можно, конечно же, форматировать в любую файловую систему). Этот раздел посвящен как раз метаданным и специальным файлам.

2.1. Метаданные файлов

На разделах с ФС Ext3 метаданные файлов включают в себя: время изменения файла, время изменения индексного дескриптора (inode), время последнего доступа, идентификаторы пользователя и группы, а также права доступа к файлам и каталогам. Если есть расширенные атрибуты, метаданных может быть намного больше, в основном за счет информации из списка управления доступом (ACL , Access Control List). Чем больше данных будет скопировано, тем лучше. Разумеется, если не сохранить и не восстановить права доступа, это приведет к неработоспособности системы. Это верно даже для таких простых вещей, как mtime (modification time, время изменения содержимого файла). Например, в дистрибутиве Gentoo Linux mtime используется для того, чтобы определить, относятся ли файлы к конкретному пакету или они были изменены потом. Если не восстановить верное время изменения файлов, система управления пакетами будет полностью неработоспособна.

В зависимости от используемого ПО могут потребоваться разные шаги для сохранения всей этой информации. Например, при использовании tar с параметрами по умолчанию нельзя сохранить верную информацию о правах доступа. Если провести быстрый тест, может показаться, что это возможно, но это обманчивое впечатление. С параметрами по умолчанию tar распаковывает файлы с настройками umask (user file creation mode mask, маска режима создания пользовательских файлов) текущего пользователя. Если текущие настройки umask достаточно свободные, то файлы могут быть восстановлены со своими настройками прав, но при более жестких параметрах umask эти ограничения будут применены и к восстановленным файлам. Чтобы это предотвратить, tar надо использовать с параметром --preserve-permissions .

Информация о владельцах файлов может храниться двумя способами: в числовом и в текстовом виде. Многие программы для резервного копирования предпочитают текстовое представление для удобства чтения человеком, но при создании резервной копии всей системы это нежелательно. Вполне вероятно, что вы будете восстанавливать систему с помощью какого-нибудь Live CD, тогда как резервная копия создавалась на самой копируемой системе. При восстановлении файлы, принадлежащие пользователю bin , получат идентификатор (ID) файловой системы, основанный на данных файла /etc/passwd с Live CD. Если это будет, например, ID 2, но тот же идентификатор в восстанавливаемой системе присвоен пользователю daemon , то файлы, принадлежащие bin , будут принадлежать daemon . Поэтому всегда следует хранить информацию о владельцах файлов в числовом виде. Для этого в tar есть параметр --numeric-owner . В rdiff-backup существует аналогичный параметр --preserve-numerical-ids , добавленный с версии 1.1.0 по моей просьбе. В dar никогда не будет поддержки текстового представления. Мы обсуждали с автором этот вопрос, и он согласился с моими аргументами.

Некоторые программы для резервного копирования (например, tar и dar ) могут восстанавливать atime (access time, время последнего доступа) после чтения файлов во время создания копии. Это делается для того, чтобы копии максимально точно соответствовали оригиналу. Этой функцией следует пользоваться с осторожностью, так как восстановление atime изменяет ctime (change time, время изменения индексного дескриптора). С этим ничего не поделаешь, так как ctime невозможно установить принудительно. В man-странице dar говорится, что NNTP-сервер Leafnode при кешировании рассчитывает, что время последнего доступа восстановлено, но обычно очень редко требуется восстанавливать atime. По моему мнению, для любой программы предполагать, что значение atime восстановлено в резервной копии — это серьезный изъян. Время доступа может меняться произвольно, даже пользователем, не имеющим доступа на запись файла. К тому же программы для автоматического индексирования, такие как Beagle, могут изменять atime. Кроме того, изменение в ctime может вызвать срабатывание отдельных программ для защиты компьютера. Как уже говорилось, ctime нельзя установить принудительно, а значит, если у файла изменено значение ctime при неизменном со времени последней проверки mtime, этот файл мог быть заменен другим, обычно это свидетельствует о внедрении руткита. Следовательно, сохранять время доступа имеет смысл, только если вы абсолютно точно знаете, что делаете. По умолчанию dar сохраняет atime. Изменения, исправляющие такое поведение, уже внесены в CVS, и скорее всего появятся в версии 2.4.0. Для старых версий следует использовать параметр --alter=atime .

2.2. Специальные файлы

2.2.1. Ссылки

Ссылки бывают двух типов: символические и жесткие. Символическая ссылка, или симлинк, — это просто указатель на другое место файловой системы. Жесткая ссылка, или хардлинк — это дополнительный указатель для inode (индексного дескриптора).

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

Жесткие ссылки требуют несколько больше внимания. Как уже говорилось, жесткая ссылка — это в принципе второе (третье, четвертое...) имя файла. Если у вас есть файл A и ссылающийся на него файл B, они ведут себя, как если бы у вас было два файла. Если оба файла по 1 ГБ, они будут занимать 1 ГБ на диске, но приложения будут считать, что они занимают 2 ГБ. Так как файл B — не просто ссылка на A, а другое имя для того же файла, можно безболезненно удалить файл A. Файл B не будет удален при удалении файла A.

Большинство приложений для резервного копирования поддерживают жесткие ссылки, но только если они все находятся в одном дереве каталогов. Если копировать каталоги /bin , /etc , /usr и т. д. отдельной командой cp -a для каждого, то информация о жестких ссылках не будет распознана и скопирована. Так как жесткие ссылки не могут указывать на файл в другой файловой системе, достаточно копировать и восстанавливать по одному разделу за раз. Например, если каталог /home вынесен на отдельный раздел, можно сделать отдельный архив с корневым каталогом / без /home и отдельный архив только с /home . Если создавать архив, включающий в себя все точки монтирования, понадобятся дополнительные действия, чтобы данные восстанавливались на нужных разделах. Если программе не мешают существующие каталоги, можно перед восстановлением данных создать точки монтирования с теми же именами в новой файловой системе. В противном случае должен помочь такой вариант: сначала восстановить данные на один раздел, а затем скопировать части на свои разделы с помощью cp -a . Не используйте mv для перемещения данных. Представьте, что будет, если программа аварийно завершится, не закончив работу.

В Linux и других Unix-подобных операционных системах широко используются жесткие ссылки, поэтому убедитесь на 100%, что целостность ссылок не нарушена.

2.2.2. Разреженные файлы

Разреженный файл (sparse file) — файл, в котором нули не записываются на диск как нули, а просто не размечаются. Благодаря этому, например, гигабайтный файл с большим количеством пустого места может занимать всего мегабайт. Такие файлы использует торрент-клиент Azureus.

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

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

2.2.3. Другие

Существуют и другие специальные файлы, такие как FIFO , именованные конвейеры (named pipes), блочные устройства и т. д. Они ничем особо не примечательны и большинство приложений знает, как с ними работать. Но надо обязательно указывать правильные параметры. Например, cp без параметра -a попытается скопировать данные именованного конвейера вместо того, чтобы воссоздать его.

Есть также и специальные каталоги: lost+found (в файловых системах Ext2/3/4). На самом деле это вообще не каталог, его невозможно создать программой mkdir . Вместо нее используйте mklost+found . Если не знаете, lost+found используется для хранения файлов, восстановленных программой e2fsck при повреждении файловой системы.

3. Что можно исключить

Чтобы сэкономить место на носителе с резервной копией, можно не сохранять некоторые каталоги. У меня в Gentoo Linux это /usr/portage/ и /var/tmp/portage .

Есть еще особые файловые системы, монтируемые в корневую, которые динамически создаются при загрузке, их не надо сохранять. В моей системе это каталоги /sys , /proc , /lost+found , /media (в котором только динамически создаваемые каталоги для съемных носителей) и /dev (потому что я использую udev ). Я также не сохраняю /mnt , но в других системах может быть необходимость в его резервном копировании.

4. Данные приложений

Создавая резервную копию работающей системы, не следует забывать о программах, которые могут изменить свои данные во время копирования. Удачный пример — это базы данных, такие как MySQL или PostgreSQL, а также данные почтовых программ (файлы mbox более уязвимы, чем maildir ). Файлы данных (обычно хранящиеся где-нибудь в /var ) могут быть подвержены изменениям в работающей системе. Это может быть вызвано обычными операциями или автоматической очисткой базы данных. Никогда не полагайтесь на файлы с данными работающей базы данных, LDAP-сервера, репозитория Subversion или любых подобных программ, которые вы используете.

Если остановить работу этих программ перед резервным копированием не представляется возможным, запланируйте задания по периодическому сохранению дампов базы данных (с помощью pg_dump для PostgreSQL, slapcat для OpenLDAP, svnadmin dump или svn-backup-dumps для Subversion и т. д.) в файлах с пометкой о времени создания. Затем можно сделать резервные копии этих файлов, это должно быть безопасно. Везде, где возможно, пользуйтесь «родными» утилитами для создания дампов, такими как pg_dump и slapcat для PostgreSQL и OpenLDAP соответственно.

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

5. Основные меры предосторожности

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

5.1. Инкрементное резервное копирование и mtime

Некоторые утилиты для резервного копирования поддерживают инкрементные копии, то есть копируют только данные, изменившиеся со времени последнего бэкапа. Отличный пример — rdiff-backup , он кроме этого ничего и не поддерживает. Будьте осторожны с инкрементным копированием и выясните, как программа определяет, изменились ли данные. Лучше всего — проверка контрольной суммы, но она занимает много времени. На втором месте надежный и быстрый способ — проверка ctime. Правда, файловая система тоже должна поддерживать ctime, но большинство систем это могут. Исключение — файловые системы, которые вы вряд ли будете использовать (например, FAT32).

Некоторые утилиты используют для отслеживания изменений в файлах только mtime или комбинацию mtime + размер. Это ненадежный метод. Например, у образов дисков, смонтированных как петлевые устройства с помощью losetup , не меняется mtime при монтировании устройства и записи на него. Вот пример из моей личной практики: я сделал образ диска, требующего серьезного исправления файловой системы, с помощью ddrescue . Для начала я решил сделать ежедневный бэкап. Мне пришло в голову проверить, изменяется ли mtime файла образа диска при записи на смонтированное петлевое устройство, потому что были подозрения, что монтирование не воспринимается системой как открытие файла. Подозрения подтвердились. Чтобы файл попал в резервную копию, приходилось сначала изменить его время модификации с помощью touch .

Еще один небольшой пример — редактирование ID3-тегов в программе Easytag. В настройках Easytag есть параметр «Сохранить время модификации файла». Если размер файла при этом не изменится, например если изменить один символ в теге, время модификации и размер будут идентичными и изменение файла не будет замечено.

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

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

5.2. Резервное копирование на другую файловую систему

Просто копировать данные на другую файловую систему — пожалуй, не лучшее решение. Команды cp -a может быть вполне достаточно для ваших нужд (при условии, что копирование происходит в файловую систему с поддержкой всего, что есть в исходной файловой системе и, в случае cp , если не используются расширенные атрибуты). Меня заботит другое: слишком легко случайно изменить файл или его метаданные, открыв и сохранив его. Надежнее сохранять данные в архивах, как это делают tar или dar .

Так как rsync тоже просто сохраняет метаданные в файловой системе, эта опасность относится и к rsync .

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

5.3. Размер архива

У многих файловых систем (или сетевых протоколов) есть серьезные ограничения на размер файла. При резервном копировании с помощью программ, создающих архивы, надо учитывать размер архива. Как правило, лучше ограничивать размер двумя гигабайтами (или, на всякий случай, чуть меньше). Файлы такого размера можно сохранять в файловых системах ISO DVD и FAT32. Я предпочитаю размер в 650 МБ, чтобы можно было записать файлы на 74-минутные компакт-диски.

Даже если вы не собираетесь хранить резервные копии на подобных файловых системах, все равно лучше разделять архивы на части, чтобы иметь возможность записать их на CD или DVD, если понадобится.

5.4. Восстановление

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

В этом отношении dar — хороший выбор, при восстановлении не требуется указывать никаких особых параметров. При использовании tar придется быть немного осторожнее.

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

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

6.1. Dar

Прежде всего — предупреждение. Настоятельно рекомендую пользоваться версией 2.3.3 (последний стабильный выпуск на момент написания статьи) или более новой, так как в ней исправлена серьезная ошибка. Подробный отчет можно прочитать в новостной рассылке dar .

Dar — хорошо продуманная программа, в ней предусмотрены решения для классических проблем. Например, она поставляется вместе со статически скомпилированным бинарником, который можно скопировать на первый диск с резервной копией. В dar поддерживается автоматическое разделение архивов на тома и есть возможность отдельно указать размер первого тома, чтобы оставить место на первом диске, например, для создания загрузочного CD. Также можно запускать какую-нибудь команду между созданием томов, так что можно записывать их на CD, вычислить информацию для контроля четности и т. д. И, что очень важно, параметры по умолчанию хорошо подобраны за исключением, пожалуй, сохранения atime (см. выше).

Я использую такую команду для сохранения своей системы на внешнем USB-диске примерно раз в неделю с помощью dar 2.2.6 (параметры, относящиеся к конкретной машине, удалены или слегка абстрагированы).

dar --execute "par2 c -r5 \"%p/%b.%n.par2\" \"%p/%b.%n.%e\"" --alter=atime --empty-dir \ --fs-root / --noconf --create НАЗВАНИЕ_АРХИВА --slice 620M --first-slice 600M -z6 \ -an -Z "*.ogg" -Z "*.avi" -Z "*.mp?" -Z "*.pk3" -Z "*.flac" -Z "*.zip" -Z "*.tgz" \ -Z "*.gz" -Z "*.gzip" -Z "*.bz2" -Z "*.bzip2" -Z "*.mov" -Z "*.rar" -Z "*.jar" \ --prune lost+found --prune usr/portage/ --prune var/tmp/portage --prune media \ --prune proc --prune mnt --prune sys

С помощью параметра --execute я вычисляю информацию для контроля четности с помощью par2 . Передаваемые программе par2 тайные знаки превращаются в имя создаваемого par2 файла и имя тома архива. Параметр --alter=atime уже обсуждался выше; --empty-dir сохраняет в архиве пустые каталоги для всех исключенных из бэкапа каталогов; -an и следующий за ним -Z по нечувствительной к регистру маске указывают, какие файлы не следует сжимать. Степень сжатия указывается с помощью -z6 . Для исключения каталогов используется --prune . Остальное должно быть понятно.

Кроме того я обычно ежедневно создаю с помощью dar резервную копию /home без сжатия. Размер получается около 6 ГБ, копирование занимает около 10 минут. Вполне приемлемо, на мой взгляд. Но по мере увеличения размера домашнего каталога я переключаюсь на rsync и затем на rdiff-backup и мирюсь с потерями времени на проверку изменений.

Восстановление из архива dar должно быть безопасно с параметрами по умолчанию (очень важный аспект, по моему мнению), но на всякий случай прочитайте man-страницу.

6.2. GNU tar

GNU tar может все, что может потребоваться для надежного резервного копирования (хотя, надо заметить, я не знаю, насколько хорошо там поддерживаются расширенные атрибуты и поддерживаются ли вообще). Однако следует быть внимательным и не забыть о параметре --numeric-owner . Это же, возможно, касается и параметра same-owner , но быстрый тест и просмотр руководства дают понять, что параметр --preserve-permissions (который включен по умолчанию для пользователя root ) это подразумевает. Если вы вдруг забыли использовать параметр --numeric-owner для команды резервного копирования, его можно задать в процессе восстановления. Его использование при резервном копировании должно, по идее, исключить необходимость его указания при восстановлении, так как с этим параметром tar не сохраняет в архиве имена владельцев в текстовом виде.

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

Еще на одну проблему tar мне указал один из читателей. В версии 1.15.1 программа повреждала разреженные файлы размером более 4 ГБ . В современных версиях tar (1.20 и выше) вроде бы нет этой проблемы, но лучше лишний раз проверить.

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

6.3. Rdiff-backup

При оценке надежности rdiff-backup надо учитывать метод отслеживания изменений, который применяется в этой программе. Если часто приходится работать с образами дисков, прочитайте пример, приведенный выше. Как-то раз мы обсуждали с автором альтернативный способ отслеживания изменений, но ему было некогда и дискуссия так ни к чему и не привела. Возможно, в будущем в программе появится надежный способ отслеживания изменений на основе контрольных сумм или ctime. Учтите, что rdiff-backup сохраняет контрольные суммы в своих метаданных с версии 1.1.1 (05.11.2005), но до сих пор не использует их для отслеживания изменений в файлах (на момент версии 1.2.1, 24.08.2008).

Кроме того, при восстановлении с помощью rdiff-backup из полной копии системы из-под другой ОС, например Live CD, не забывайте указывать параметр --preserve-numerical-ids , иначе у файлов будут неправильно указан владелец. Об этом слишком легко забыть (проверено на собственном опыте).

Между тем, если вы полностью уверены, что вас не коснется проблема с mtime, описанная выше, например в /home , можно смело пользоваться этой программой. Не исключено, что мои опасения покажутся вам преувеличенными, и вы можете копировать всю систему несмотря ни на что. Я решил, что опасность не слишком велика и пользуюсь rdiff-backup . Это очень надежная программа и одна из лучших для инкрементного копирования, на мой взгляд.

6.4. Rsync

Моя главная проблема с rsync — то, что метаданные программы создаются заново в целевой файловой системе. Это не только ограничивает использование целевой файловой системы, но и вообще странно, о чем написано выше. Кроме того, rsync — одна из тех утилит, которые проверяют наличие изменений в файлах по комбинации mtime и размера. И, так как ее параметры для надежной проверки наличия изменений в файлах (--ignore-times и особенно --checksum ) замедляют работу программы, dar без сжатия может быть предпочтительнее. Разумеется, только при резервном копировании на быстрый локальный носитель.

Здесь важно отметить, что rsync не сохраняет файлы метаданных, и поэтому сравнивает mtime и размер файла с копией. Это означает, что только при использовании параметра --times для сохранения mtime файлов проверка изменений не сработает, как было описано ранее.

У rsync есть особый ключ --archive , специально предназначенный для сохранения всех метаданных. Правда, этого параметра все равно недостаточно. Например, по умолчанию не сохраняется информация о жестких ссылках, потому что это слишком медленно. Также не сохраняются жесткие ссылки, расширенные атрибуты и списки управления доступом. Поэтому надо дополнительно указывать --hard-links , --acls и --xattrs (rsync поддерживает расширенные атрибуты с третьей версии, кажется). Также желательно добавить параметры --sparse и --numeric-ids по описанным выше причинам. Я бы добавил еще --delete --delete-excluded --delete-after , чтобы в резервную копию не попали старые файлы. Параметр --delete-after необходим, так как иначе в случае сбоя в процессе копирования файлы, переименованные после создания последней резервной копии (старый файл удален, новый создан), будут удалены до того, как новый файл скопирован. Лучше сначала скопировать новый файл, а затем удалить старый.

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

Некоторое время назад вышла третья версия rsync . Там появились интересные новые возможности, такие как поддержка списков управления доступом и расширенных атрибутов. Могут возникнуть проблемы с определением изменений, но, особенно начиная с третьей версии, программу стоит использовать (возможно, только для резервного копирования отдельных частей), потому что она весьма эффективна и продуманна.

6.5. GNU cp

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

6.6. Clonezilla

Clonezilla — специализированный Live CD для создания образов файловых систем различных типов, в том числе NTFS. За исключением некоторых странностей интерфейса, это прекрасно спроектированная программа. Она оправдывает все ожидания, например использует dd для резервного копирования MBR и области между MBR и первым разделом. Она даже запускает sync по завершении. Такое впечатление, что программа читала эту статью:) И, возможно, самое важное: можно извлекать компакт-диск при выключении или перезагрузке!

6.7. Другие инструменты клонирования разделов

Программы для клонирования разделов, такие как g4u , partimage , clonezilla (или dd ...) могут быть очень удобны, но у них (в основном) есть один существенный недостаток: они (зачастую) требуют, чтобы данные восстанавливались на идентичный диск и (или) такие же разделы. Если диск сыплется и надо найти новый, это может быть сложно.

Однако это не всегда так. Недавно я скопировал с помощью dd целый диск на другой (на 1 ГБ больше) командой dd if=/dev/sda of=/dev/sdb . На новом диске теперь есть неразмеченная область, но он работает отлично. Windows XP, установленная на этом разделе, загружается с нового диска, хотя Windows XP капризна в таких делах. В любом случае, восстановление на меньший раздел будет проблематично. Иногда можно импровизировать, но лучше этого избегать. Если вы собираетесь использовать этот метод резервного копирования, лучше удостовериться, что запасной диск имеет достаточный размер. Этого можно добиться, предполагая, что размер дисков со временем увеличивается, или пользуясь небольшими разделами (но не слишком маленькими, чтобы не допустить фрагментации).

Не слишком «умные» программы для клонирования, такие как g4u или dd , тратят огромное количество времени, так как копируют каждый блок файловой системы, в том числе и незанятые. И, если эти незанятые блоки заранее не записаны нулями, готовый образ получается очень большим.

Еще один аспект, который многим покажется неудобным — необходимость выключить компьютер перед созданием образа. Насколько мне известно, ни одна из программ не может создать образ файловой системы работающей системы. В любом случае, определенно не стоит создавать образ раздела с работающей системой с помощью dd .

7. Автоматизация

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

Вот пример, демонстрирующий важность этого момента: предположим, что мы делаем резервную копию с помощью tar . Сначала делаем новую копию, затем удаляем старую. Если дисковый кеш не синхронизирован и во время удаления старой копии отключилось питание, может выйти так, что и старая, и новая копии будут повреждены. Мне говорили, что это бессмысленно, потому что данные в кеше упорядочены последовательно и удаление после начальной команды копирования сначала вызовет запись кеша. Это не совсем так, особенно если у вас диск с NCQ /TCQ , а это большинство современных дисков. Весь смысл записи кеша в том, чтобы подготовиться к записи вне очереди.

sync ; sleep 2 mount РАЗДЕЛ_ДЛЯ_ЗАПИСИ_КОПИИ [КОМАНДА_РЕЗЕРВНОГО_КОПИРОВАНИЯ] sync ; sleep 2 [КОМАНДА_УДАЛЕНИЯ_СТАРЫХ_ФАЙЛОВ] sync ; sleep 2 umount

Запуск sync в конце тоже важен, чтобы в случае сбоя не повредить данные при размонтировании, если носитель, например, будет физически отключен.

8. Копирование файловой системы

Если есть желание создавать снимки всей файловой системы, имеет смысл использовать логические разделы, созданные с помощью LVM . Логические разделы позволяют создавать атомарные снимки всего раздела. Лучшая резервная копия — это копия на уровне файловой системы или ниже, так как позволяет сохранить все данные и метаданные, поэтому это очень надежный способ резервного копирования.

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

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

9. Выбор файловой системы

Хотя это несколько выходит за рамки предмета статьи, хотелось бы сказать пару слов и о выборе файловой системы. Многие отдают предпочтение ReiserFS, а не Ext3, из-за ее новизны или незначительных отличий. Ext3 — файловая система по умолчанию в большинстве дистрибутивов Linux. Я рекомендую оставаться на ней, если нет особых причин использовать какую-то другую. В ReiserFS, например, есть логическое журналирование. Есть информация , что это может быть опасно в случае аварийного отключения питания. К тому же, сам Ганс Райзер говорил (или говорят, что говорил), что ReiserFS оптимизирована для быстродействия, а не безошибочной работы.

Даже в новой файловой системе Ext4 есть потенциальные проблемы, связанные с отложенным размещением . В Ext3 это был необязательный параметр (data=writeback

Обновлено: 4.05.2014 - 06:41

Резервное копирование системы (Backup) является одной из важных профилактических мер по поддержание стабильности работы сервера. Хотя данная инструкция подойдёт и для desktop систем, получится своего рода "точка восстановления". Для резервного копирования нам понадобится всего-лишь утилита по работе с архивами в linux системах – tar .

Делаем резервную копию работающей системы:

1. Для Ubuntu – выполняем sudo su , для Debian – выполняем su -l root

2. Смотрим, сколько у нас системой использовано, сколько места свободно (backup будем сжимать в архив, так-что размер будет меньше, чем текущее использование системой).

root@server:~# df -h

Файловая система Размер Использовано Дост Использовано% Cмонтировано в

/dev/sda2 73G 2,1G 67G 3% /

Tmpfs 5,0M 0 5,0M 0% /lib/init/rw

Tmpfs 152M 1,4M 151M 1% /run

Udev 753M 0 753M 0% /dev

Tmpfs 303M 0 303M 0% /run/shm

/dev/sdb1 147G 26G 114G 19% /web

В данном примере вся система установлена на раздел /dev/sda2 и занимает 2.1G, в корень этого раздела мы и будем копировать дамп, т.к. доступно ещё 67G.

3. Переходим в корень системы cd /

4. Выполняем копирование работающей системы (Внимание!!! Исключаем из копирования разделы /proc /lost+found /sys и сам архив /backup.tgz, + в данном примере исключаем раздел /web). Для чистоты бэкапа рекомендую вам почистить логи в /var/log , и удалить кеш архивов apt-get clean.

tar cvpzf backup.tgz –exclude=/proc –exclude=/lost+found –exclude=/backup.tgz –exclude=/mnt –exclude=/sys –exclude=/web /

5. Смотрим ls -alh

теперь можно спрятать куда-нибудь в надежное место архив backup.tgz на случай сбоев работы сервера, а потом с лёгкостью восстановить систему в короткие сроки.

Восстановление системы Debian/Ubuntu (да и любого дистрибутива Linux) из созданного бэкапа:

Если вы делаете восстановление системы на то-же оборудование, с теми-же разделами жестких дисков, то процесс займёт буквально несколько минут.

1. Загружаемся с Live CD Linux (например Ubuntu, хотя можно и по легче выбрать образ, без графического интерфейса). Копируем backup системы в корень.

2. Распаковываем архив в корень раздела

tar xvpfz backup.tgz /

3. Теперь прописываем загрузочную область (Из личного опыта, если вы делали разметку GParted утилитой, то в начале диска обязательно оставьте несколько не задействованных мегабайт, иначе grub2 не установится).

grub-install –root-directory=/mnt/ /dev/sda2

(–root-directory=/mnt/ в данном случае указывает, что для корня считать точку /mnt , т.к. туда у нас временно смонтирован раздел sda2)

4. Создаем пустые каталоги /proc /sys . Перезагружаемся и внимательно смотрим на логи, которые выводит система при загрузке.

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

1. Распаковываем архив.

2. Смотрим, как в системе Live CD определилось оборудование, в частности разделы жёстких дисков.

3. При старте компьютера (до загрузки ОС) заходим в редактор grub2 и правим конфиг в соответствии с менами разделов жёстких дисков.

4. Если система не может запуститься из-за "отсутствие файловой системы", значит нужно пересобирать initrd загрузчик (это загрузчик, который определяет всё оборудование, а потом далее передаёт ядру ОС управление и дальнейшую загрузку системы) с необходимыми модулями, выполнять это можно загрузившись с Live CD, примонтировав разделы /proc и /sys к системе, в которую мы будем компилировать /mnt/proc /mnt/sys , а далее авторизоваться, как будто бы работает система chroot /mnt

В принципе это самый простой способ для резервного копирования рабочей системы, никакие акронисов, никакик утилит для работы с клонированием разделов не надо, всё достаточно просто и быстро. При желании, можно сделать правило, на запуск скрипта в 01:00 ночи, который бы делал дамп системы к примеру 1 раз в неделю.