Восстановление linux из бэкапа tar

Обновлено: 23.01.2025

Прежде чем исследовать методы развертывания стандартного плана резервного копирования, специфичные для CentOS, давайте сначала обсудим типичные аспекты политики резервного копирования стандартного уровня. Первое, к чему мы хотим привыкнуть, это правило резервного копирования 3-2-1 .

3-2-1 Стратегия резервного копирования

Во всей отрасли вы часто слышите термин «резервная модель 3-2-1». Это очень хороший подход для реализации плана резервного копирования. 3-2-1 определяется следующим образом: 3 копии данных; например, у нас может быть рабочая копия; копия, помещенная на сервер CentOS, предназначенный для резервирования с использованием rsync; и повернутые резервные копии USB сделаны из данных на сервере резервного копирования. 2 разных резервных носителя. На самом деле в этом случае у нас будет три разных носителя для резервного копирования: рабочая копия на SSD ноутбука или рабочей станции, данные сервера CentOS на массиве RADI6 и внешнее резервное копирование на USB-накопители. 1 копия данных вне офиса; мы вращаем USB-накопители вне площадки каждый вечер. Другим современным подходом может быть поставщик облачного резервного копирования.

Восстановление системы

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

План многофазного восстановления и восстановления данных с использованием собственных инструментов CentOS может состоять из:

dd создавать и восстанавливать производственные образы дисков настроенных серверов

rsync для создания инкрементных резервных копий всех пользовательских данных

tar & gzip для хранения зашифрованных резервных копий файлов с паролями и заметками от администраторов. Обычно это можно записать на USB-накопитель, зашифровать и заблокировать в сейфе, к которому имеет доступ старший менеджер. Кроме того, это гарантирует, что кто-то другой будет знать жизненно важные учетные данные безопасности, если текущий администратор выиграет в лотерее и исчезнет на солнечном острове.

dd создавать и восстанавливать производственные образы дисков настроенных серверов

rsync для создания инкрементных резервных копий всех пользовательских данных

Если система выходит из строя из-за аппаратного сбоя или сбоя, следующие этапы восстановления операций будут следующими:

Создайте рабочий сервер с настроенным голым железным образом

Восстановление данных на рабочий сервер из резервных копий

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

Создайте рабочий сервер с настроенным голым железным образом

Восстановление данных на рабочий сервер из резервных копий

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

Используйте rsync для резервного копирования на уровне файлов

Исследуйте и поговорите о некоторых распространенных вариантах
Создать локальные резервные копии
Создавайте удаленные резервные копии по SSH
Восстановить локальные резервные копии

rsync назван по назначению: удаленная синхронизация и является мощной и гибкой в использовании.

Ниже приведено базовое удаленное резервное копирование rsync через ssh:

Следующая синхронизация отправила почти 2,3 ГБ данных по нашей локальной сети. Прелесть rsync в том, что он работает постепенно на уровне блоков для каждого файла отдельно. Это означает, что если мы изменим только два символа в текстовом файле размером 1 МБ, только один или два блока будут переданы через сеть при следующей синхронизации!

Кроме того, инкрементная функция может быть отключена в пользу большей пропускной способности сети, используемой для меньшей загрузки ЦП. Это может оказаться целесообразным, если постоянно копировать несколько файлов базы данных по 10 МБ каждые 10 минут на выделенной резервной локальной сети емкостью 1 ГБ. Причина заключается в следующем: они всегда будут меняться и будут передаваться постепенно каждые 10 минут и могут облагаться нагрузкой на удаленный ЦП. Поскольку общая нагрузка передачи не будет превышать 5 минут, мы можем просто синхронизировать файлы базы данных в полном объеме.

Когда использовать rsync

Локальное резервное копирование с rsync

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

Давайте сделаем ручное добавочное резервное копирование / etc / в каталоге нашего корневого пользователя.

Во-первых, нам нужно создать каталог с

Затем убедитесь, что на диске достаточно свободного места.

Только наш файл test_incremental.txt был скопирован.

Удаленное дифференциальное резервное копирование с rsync

Давайте сделаем наше первоначальное полное резервное копирование rsync на сервер с развернутым планом резервного копирования. В этом примере фактически выполняется резервное копирование папки на рабочей станции Mac OS X на сервер CentOS. Другим важным аспектом rsync является то, что его можно использовать на любой платформе, на которую был перенесен rsync.

Теперь мы создали резервную копию папки с рабочей станции на сервере с томом RAID6 с повернутым носителем аварийного восстановления, который хранится вне сайта. Использование rsync дало нам стандартное резервное копирование 3-2-1 только с одним сервером, имеющим дорогой избыточный дисковый массив и повернутые дифференциальные резервные копии.

Теперь давайте сделаем еще одну резервную копию этой же папки с помощью rsync после того, как был добавлен новый файл с именем test_file.txt .

Как видите, только новый файл был доставлен на сервер через rsync . Дифференциальное сравнение было сделано для каждого файла отдельно.

Несколько вещей, на которые следует обратить внимание: это только копирует новый файл: test_file.txt, так как это был единственный файл с изменениями. Rsync использует SSH. Нам не нужно было использовать нашу учетную запись root ни на одной машине.

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

Для автоматизации резервного копирования rsync с помощью cronjobs важно, чтобы пользователи SSH были настроены с использованием ключей SSH для аутентификации. Это в сочетании с cronjobs позволяет выполнять rsync автоматически через определенные промежутки времени.

Используйте DD для блочных изображений восстановления голого металла

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

Весь процесс создания загрузочного образа системы с помощью dd выглядит следующим образом:

Загрузка с сервера CentOS с загрузочного дистрибутива Linux
Найдите обозначение загрузочного диска для образа
Определите место, где будет храниться образ восстановления
Найдите размер блока, используемого на вашем диске
Запустите операцию изображения dd

В этом уроке ради времени и простоты мы будем создавать ISO-образ основной загрузочной записи с виртуальной машины CentOS. Затем мы будем хранить это изображение вне сайта. В случае, если наша MBR повреждена и требует восстановления, тот же процесс может быть применен ко всему загрузочному диску или разделу. Тем не менее, время и дисковое пространство, необходимое для этого урока, немного запредельные.

Администраторам CentOS рекомендуется научиться восстанавливать полностью загрузочный диск / раздел в тестовой среде и выполнять восстановление «с нуля». Это избавит от большого давления, когда в конечном итоге нужно будет завершить практику в реальной ситуации, когда менеджеры и несколько десятков конечных пользователей будут считать время простоя. В таком случае 10 минут на то, чтобы разобраться, могут показаться вечностью и потеть.

Примечание о размере блока. Размер блока по умолчанию для dd составляет 512 байт. Это был стандартный размер блока жестких дисков меньшей плотности. Современные жесткие диски с более высокой плотностью увеличились до 4096 байт (4 КБ), что позволяет использовать диски размером от 1 ТБ и более. Таким образом, мы хотим проверить размер дискового блока перед использованием dd с более новыми жесткими дисками большей емкости.

В этом руководстве вместо работы на рабочем сервере с dd мы будем использовать установку CentOS, работающую в VMWare. Мы также настроим VMWare для загрузки загрузочного ISO-образа Linux вместо того, чтобы работать с загрузочной флешкой USB.

Сначала нам нужно скачать образ CentOS под названием: CentOS Gnome ISO . Это почти 3 ГБ, поэтому рекомендуется всегда сохранять копию для создания загрузочных USB-накопителей и загрузки на виртуальные серверные установки для устранения неполадок и получения изображений с нуля.

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

Давайте настроим установку VMWare Workstation для загрузки с нашего загрузочного образа Linux. Шаги предназначены для VMWare в OS X. Однако они одинаковы для VMWare Workstation в Linux, Windows и даже Virtual Box.

Примечание. Использование решения для виртуального рабочего стола, такого как Virtual Box или VMWare Workstation, является отличным способом настройки лабораторных сценариев для изучения задач администрирования CentOS. Он обеспечивает возможность установки нескольких установок CentOS, практически без аппаратной конфигурации, позволяя человеку сосредоточиться на администрировании, и даже сохранить состояние сервера перед внесением изменений.

Теперь при загрузке наша виртуальная машина будет загружаться из загрузочного ISO-образа CentOS и разрешать доступ к файлам на сервере Virtual CentOS, который был предварительно настроен.

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

Мы нашли оба наших физических диска: sda и sdb . Каждый имеет размер блока 512 байт. Итак, теперь мы запустим команду dd, чтобы скопировать первые 512 байт для нашей MBR на SDA1.

При работе с данными с дисков мы всегда хотим включить: conv = sync, параметр noerror .

Это просто потому, что диски не являются потоками, такими как данные TCP. Они состоят из блоков, выровненных до определенного размера. Например, если у нас есть 512-байтовые блоки, для файла размером всего 300 байт все еще нужны полные 512 байт дискового пространства (возможно, 2 блока для информации inode, такой как разрешения и другая информация файловой системы).

Используйте gzip и tar для безопасного хранения

Использование Gnu Tar в CentOS Linux

В течение многих лет tar является стандартом для хранения архивных файлов в Unix и Linux. Следовательно, использование tar вместе с gzip или bzip считается наилучшей практикой для архивов в каждой системе.

переключатель	действие
-с	Создает новый архив .tar
-С	Выдержки в другой каталог
-j	Использует сжатие bzip2
-z	Использует сжатие GZIP
-v	Подробный прогресс архивирования шоу
-t	Содержит список архивов
-f	Имя файла архива
-Икс	Извлекает архив tar

Ниже приведен основной синтаксис для создания архива tar .

Замечание о механизмах сжатия с помощью tar. Рекомендуется придерживаться одной из двух распространенных схем сжатия при использовании tar: gzip и bzip2. GZIP-файлы потребляют меньше ресурсов процессора, но обычно имеют больший размер. В то время как bzip2 сжимается дольше, они используют больше ресурсов процессора; но приведет к меньшему конечному размеру файла.

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

bzip2	.tbz
bzip2	.tar.tbz
bzip2	.tb2
GZIP	.tar.gz
GZIP	.tgz

При необходимости извлечения архивов из коробки Windows или для использования в Windows рекомендуется использовать .tar.tbz или .tar.gz, так как большинство трехсимвольных расширений будут путать Windows и только администраторов Windows (однако это иногда желаемый результат)

Примечание. Вместо того, чтобы добавлять все файлы непосредственно в архив, мы заархивировали всю папку RemoteStuff . Это самый простой способ. Просто потому, что при извлечении весь каталог RemoteStuff извлекается со всеми файлами в текущем рабочем каталоге как ./currentWorkingDirectory/RemoteStuff/

Теперь давайте распакуем архив в каталог / root / home.

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

Используйте gzip для сжатия резервных копий файлов

Как отмечалось ранее, мы можем использовать bzip2 или gzip из tar с ключами командной строки -j или -z . Мы также можем использовать gzip для сжатия отдельных файлов. Однако использование одних только bzip или gzip не дает столько возможностей, сколько в сочетании с tar .

Некоторые общие параметры командной строки для gzip:

переключатель	действие
-с	Сохраняет файлы после помещения в архив
-l	Получить статистику для сжатого архива
-р	Рекурсивно сжимает файлы в каталогах
-1 до 9	Определяет уровень сжатия по шкале от 1 до 9

gzip более или менее работает на файловой основе, а не на архивной основе, как некоторые утилиты Windows O / S zip. Основной причиной этого является то, что tar уже предоставляет расширенные возможности архивирования. GZIP предназначен для обеспечения только механизма сжатия.

Следовательно, когда вы думаете о gzip , подумайте об одном файле. Когда вы думаете о нескольких файлах, подумайте об архивах tar . Давайте теперь рассмотрим это с нашим предыдущим архивом tar .

Примечание. Опытные специалисты по Linux часто будут ссылаться на архивный архив как на тарбол.

Давайте сделаем еще один архив tar из нашей резервной копии rsync .

В демонстрационных целях давайте распакуем только что созданный tar-архив и скажем gzip сохранить старый файл. По умолчанию без опции -c gzip заменит весь архив tar на файл .gz .

Попробуем проверить ключ -l с помощью gzip .

Чтобы продемонстрировать, чем gzip отличается от Windows Zip Utilities, давайте запустим gzip для папки с текстовыми файлами.

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

Увидеть? Не то, что некоторые могли ожидать. Все исходные текстовые файлы были удалены, и каждый был сжат по отдельности. Из-за этого поведения лучше всего думать о gzip в одиночку, когда нужно работать в отдельных файлах.

Работая с тарболами , давайте распакуем наш rsynced тарбол в новый каталог.

Как показано выше, мы распаковали и распаковали наш tar-архив в каталог / tmp.

Шифровать архивы TarBall

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

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

Openssl, как и GnuPG, может делать то, что мы хотим, и поставляется с CentOS. Но опять же, он не предназначен специально для того, чтобы делать то, что мы хотим, и шифрование подвергалось сомнению в сообществе безопасности.

Установите 7zip на Centos

Все просто, 7zip установлен и готов к использованию с 256-битным шифрованием AES для наших архивных архивов.

Где : добавить в архив и -p: зашифровать и запросить фразу-пароль

Теперь у нас есть архив .7z, который шифрует сжатый архив с 256-битным AES.

Примечание. 7zip использует 256-битное шифрование AES с хешем пароля и счетчика SHA-256, повторяемое до 512 Кбайт для получения ключа. Это должно быть достаточно безопасно, если используется сложный ключ.

Процесс шифрования и повторного сжатия архива может занять некоторое время с большими архивами.

Глава 22 Процедуры резервирования и восстановления данных

Резервное копирование и восстановление в Linux

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

В Linux существует много методов выполнить резервное копирование, среди них такие, как "dump", "tar", "cpio" и "dd". Также доступны утилиты базирующиеся на текстовых файлах, например "Amanda", которая разработана, чтобы добавить дружественный пользовательский интерфейс к процедуре резервного копирования и восстановления данных. И наконец, коммерческие пакеты резервного копирования, например "BRU".

Процедуры выполнения резервного копирования и восстановления данных будет отличаться в зависимости от выбранного вами решения. Из этих соображений, мы будем обсуждать здесь процедуру резервного копирования при помощи традиционных для UNIX утилит: "tar" и "dump".

Что такое резервное копирование

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

Файловая система "/proc": так как она содержит только данные, которые ядро генерирует автоматически, и нет никакого смысла сохранять их.
Файловой системы "/mnt", потому что в нее вы монтируете ваши сменные носители, подобные CD-ROM, гибким дискам и пр.
Каталоги и носители, содержащие резервные копии, такие как стримеры, CD- ROM, смонтированная файловая система NFS, удаленные/локальные каталоги и прочие виды носителей.
Программное обеспечение, которое может быть легко повторно установлено, хотя оно может иметь конфигурационные файлы, которые необходимо копировать, чтобы не выполнять работы по их настройке позже. Я рекомендую сохранять их (конфигурационные файлы программного обеспечения) на дискете.

Программа резервного копирования tar

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

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

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

Создание резервных копий с tar

С шестью лентами вы можете делать резервные копии каждый день; процедура использует ленту 1 для полного резервного копирования (Пятница 1), и ленты со 2 по 5 для добавочного резервного копирования (С понедельника по четверг). Затем, мы делаем новую полную резервную копию на ленту 6 (вторая пятница), и далее делаем добавочные копии на лентах со 2 по 5. Важно сохранить 1 в неприкосновенности, пока мы не получим полную резервную копию на ленте 6. В следующем примере, мы подразумеваем, что записываем резервные копии на SCSI ленточное устройство с именем (/dev/st0), и создаем резервную копию домашнего каталога (/home) нашей системы.

Первое, мы должны переместиться в корневой раздел. Когда "tar" создает архивные файлы, он удаляет начальный символ "/" (слеш) из пути к файлу. Это значит, что после восстановления файлы могут оказаться не на своем месте. Чтобы решить эту проблему, необходимо до изготовления резервных копий и восстановления данных переходить в корневой раздел вашей файловой системы.

Переместитесь в корневой раздел:

Важно всегда начинать с изготовления полной резервной копии, например, в пятницу:

Далее, делаем добавочные резервные копии на лентах со 2 по 5 и так далее.

Опция "c" определяет, что мы создаем архивный файл.
Опция "p" сохраняет права доступ.
Опция "N" делает добавочную резервную копию и запоминает файлы новее чем DATE.
Опция "f" говорит, что следующий аргумент будет либо имя архивного файла, либо имя устройства на которое производится запись.

Объясним как мы получили имя файла, который содержит текущую дату: просто поместите команду "date" между обратными кавычками. К основному имени добавляется суффикс "tar" для не сжатых архивов, и суффикс "tar.gz" для сжатых. Так как мы не определяем конкретное имя для файла резервной копии, то воспользуемся опцией "--label", которая позволяет записать некоторую информацию в архивный файл. В заключении мы определяем, что только файлы из каталога "/home" будут записаны на ленту.

Так как лента это устройство посимвольного ввода, мы не можем определить имя файла. Поэтому, в качестве аргумента для опции "имя файла" программы tar используется просто имя устройства, "/dev/st0". Устройство "/dev/st0" не перематывается после создания резервной копии; поэтому, мы имеем возможность записать на одну ленту несколько сессий. Вы можете, также сказать устройству "/dev/st0", автоматически перемотать ленту после окончания записи резервной копии. При работы с лентой, вы можете использовать следующие команды для перематывания и извлечения ленты из устройства:

ПРЕДОСТЕРЕЖЕНИЕ. Для уменьшения пространства занимаемого tar архивом, резервная копия может быть сжата при помощи опции "z" программы tar. К сожалению, использование этой опции может создать ряд проблем. Из природы работы сжатия следует, что если хотя бы один бит будет испорчен, то и все данные нужные для восстановления будут потеряны. Поэтому рекомендуется не использовать сжатие (опция "z") для создания резервной копии при помощи команды tar.

Если ваша резервная копия не помещается на ленте, то вам надо использовать опцию --multi-volume (-M) для создания многотомных архивов:

После того, как вы создали резервную копию, вы должны убедиться, что все OK, используя опцию --compare (-d):

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

Опция "--directory" говорит tar, что до начала резервного копирования надо перейти в следующий каталог (в нашем примере "/"). Опция "--exclude" говорит tar не создавать резервные копии заданных каталогов и файлов. Символ ".", находящийся в конце командной строки говорит tar, что он должен копировать все в текущем каталоге.

ПРЕДУПРЕЖДЕНИЕ. Когда вы создаете резервную копию вашей системы, не включайте в нее псевдофайловую систему "/proc"! Файлы "/proc" не настояшие файлы, это просто файлоподобные ссылки к структуре ядра. Также не включайте каталоги "/mnt", "/archive" и все "lost+found".

Автоматизация задачи резервного копирования при помощи tar

Всегда интересно автоматизировать задачу резервного копирования. Автоматизация предлагает огромные возможности использования вашего Linux сервере для целей, которые вы поставили. Следующий пример, представляет из себя скрипт для резервного копирования, называемый "backup.cron". Этот скрипт написан для запуска на любом компьютере, при этом, вы должны поменять только четыре переменные: COMPUTER, DIRECTORIES, BACKUPDIR и TIMEDIR. Мы считаем, что вы устанавливаете этот сценарий для запуска его в начале месяца для получения полной резервной копии, а затем используете его в течении месяца для получения добавочных копий. В нашем примере, мы создаем резервную копию в каталоге на локальном сервере (BACKUPDIR), но вы можете изменить это для использования ленты на локальном сервере или смонтированной файловой системы NFS.

Создайте скрипт резервного копирования backup.cron (touch /etc/cron.daily/backup.cron) и добавьте в него следующие строки:

Здесь приводится список файлов созданных после недели работы данного скрипта:

Если вы не запустили этот скрипт вначале месяца (1 день месяца), добавочным резервным копиям для корректной работы будет нужно время полной воскресной резервной копии. Если вы запускаете скрипт в середине недели, вам нужно создать файл со временем в TIMEDIR. Для этого выполните следующую команду:

где </backups/last-full> ваша переменная TIMEDIR, описывающая место хранения даты последней полной резервной копии, а <myserver-full-date> - это имя вашего сервера (например, deep); наш файл времени состоит из одной строки содержащей дату (например 15-Feb).

Сделайте скрипт исполняемым и измените права доступа к нему (755).

ЗАМЕЧАНИЕ. Так как этот скрипт расположен в каталоге "/etc/cron.daily", он будет автоматически выполняться в час ночи каждый день.

Восстановление файлов с tar

Более важным, чем выполнение регулярных резервных копий, является их доступность в момент, когда надо восстановить информацию! Здесь мы рассмотрим методы восстановления файлов, которые были скопированы командой "tar".

Следующая команда будет восстанавливать все файлы из архива "full-backup- Day-Month-Year.tar", который является примером резервной копии нашего каталога "home" и был создан в нашем примере описанном выше. Для восстановления полной резервной копии каталога "home" используйте следующую команду:

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

Опция "x" обозначает извлечение файлов.
Опция "p" сохраняет права доступа.
Опция "f" указывает на то, что следующим аргументом является имя архива или устройства.

Если вам не надо извлекать все файлы и каталоги из архива, вы можете указать, что вам нужно.

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

Вышеприведенная команда извлекает файлы "/home/wahib/Personal/Contents.doc" и "/home/quota.user" из архива. Если вы хотите посмотреть, какие файлы находятся в архиве, то используйте опцию --list (-t):

ПРЕДУПРЕЖДЕНИЕ. Если вы имеете в своей системе файлы с установленным битом "постоянства", то используйте команду "chattr +i", так как этот бит не сохраняется при резервном копировании при помощи команды tar.

Тестирование возможности восстановления из резервных копий

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

25 дек 2019, 10:37

Основой этой работы послужила статья: Статья
К сожалению, указанная статья, если следовать её рекомендациям, у меня привела к ошибкам в создании архива. Возможно, это связано с тем, что в современных дистрибутивах Линукса, — а я делал бэкап на Cinnamon 19.2, — изменились правила работы команды tar. В частности, команда tar у меня не восприняла ключ -C, вместо этого создав архив с именем "-С". Кроме того, упаковка и распаковка архива пошла в неправильные папки, что тоже создало определённые проблемы, с которыми мне помогли разобраться здесь на форуме.
Теперь и я хочу поделиться данной практической наработкой. Возможно, эти описания кому-то станут полезными и сэкономят новичкам часы работы.
Итак, как говорится, поехали!

Прежде всего загружаемся с установочного диска CD/DVD Линукса (после загрузки на Рабочем столе должен находиться ярлык "Install Linux Mint").
Здесь, как мне тоже советовали, можно пойти в программу "Диски" установочного диска Линукс и провести бэкап, не заморачиваясь командами терминала и командой tar. Команда "Диски" находится по этому пути: Menu (аналог кнопки "Пуск" в Windows) —> Preferences —> Disks. Далее там можно сделать бэкап нужного раздела диска. Но здесь есть один нюанс. Как выяснилось (у меня во всяком случае так), бэкап получается итоговым размером с раздел диска. То есть, если у вас Линукс стоит, например, на разделе размером 25 Гигабайт, а занимает только 6 Гигабайт, то итоговый размер бэкапа будет 25 Гигабайт. Если у вас размер жёсткого диска позволяет создавать такие бэкапы, можете воспользоваться этим, без сомнения, более простым способом создания бэкапа и восстановления из него. Я же в этой статье покажу путь создания и восстановления из бэкапа меньшего размера, чем даже размер Линукса.
Допустим, нужный раздел, где будет храниться бэкап системы Линукс у нас уже создан. Пусть сам Линукс — это /dev/sdaX, а дополнительный раздел (для бэкапа) — это /dev/sdaY. Вместо X и Y поставьте те номера, которые относятся к вашей системе. У меня, например, /dev/sdaX — это /dev/sda7, а /dev/sdaY — это /dev/sda6. У вас это могут быть другие номера разделов диска.
Если раздел для хранения бэкапа не создан, его предварительно нужно создать программой Menu —> Administration —> GParted установочного диска Линукс и отформатировать в той же файловой системе, в которой отформатирован раздел с установленным Линуксом, например, в ext4.

Создаём в корневом разделе загруженного liveCD две папки: корневую, к которой примонтируем наш Линукс, который требует бэкапа, и бэкаповскую, к которой примонтируем дополнительный логический диск, на который будем писать файл бэкапа. Делаем это так.
Запускаем терминал.

Эта команда создаёт сразу две папки: /mnt/root и /mnt/backup. В команде текст "/mnt/" нужно писать без пробелов. Пароль для sudo он не просит, в liveCD его вводить, вообще говоря, не требуется.
Монтируем оба раздела. Корневой раздел на всякий случай монтируем с опцией (-о) "read-only": Далее запускаем создание архива (в папке backup из содержимого папки root):

После этого папки в liveCD root и backup должны быть пустыми, а сам архив-бэкап системы должен находиться на дополнительном диске бэкапов Линукса, который для этого создавался и форматировался. Этот архив можно скопировать на всякий случай даже на раздел Windows и хранить его там (у меня две системы на компьютере: Windows XP и Линукс). Но для восстановления бэкапа, его следует предварительно скопировать на дополнительный диск Линукса (на /dev/sdaY).

Теперь посмотрим на то, как делается восстановление из бэкап-архива.
Загружаемся с установочного диска Линукс. Копируем бэкап-архив оттуда, где мы его храним, на дополнительный логический раздел Линукс /dev/sdaY (если этого файла архива там нет).
Создаём в терминале точки монтирования для корневого раздела и раздела, на котором хранится бэкап-архив:

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

Гайд предполагает, что / (корень) — ваш загрузочный, если вы используете разметку диска MBR .

Из доступных средств у нас — только LiveCD/ DVD / USB для резервного копирования и развертки системы. Системы резервного копирования отсутствуют.

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

Начнем мы с резервного копирования.

Шаг 0. Загружаемся с Live системы.

Шаг 1. Монтируем накопитель, на который будет производиться резервное копирование системы (директория монтирования ФС накопителя резервных копий в примере будет /media/backupdisk1, система смонтирована в /mnt).

Шаг 2. Создаем архив с резервной копией.

Команда архивации системы

tar cpJvf /media/backupdisk1/our_backup. xz --selinux --exclude /mnt/dev --exclude /mnt/proc --exclude /mnt/sys --exclude /mnt --exclude /media --exclude /mnt/lost+found --exclude /mnt/tmp /mnt/

Описание опций tar:

с — create — создать;
p — сохраняем владельцев файлов и права к файлам;
J — используем компрессию xz;
v — verbose, чтобы видеть, что происходит во время архивации;
f — указываем файл, куда мы хотим сохранить копию/архив;
— -exclude — исключить из архивации директории и файлы. Из архива исключаются каталоги, структура которых создается при загрузке операционной системы, в связи с чем нет смысла добавлять их в архив.
— -selinux — сохраняем контексты SElinux, примененные к файлам. Используйте только при наличии в системе SElinux и его поддержки tar (как правило, присутствует в актуальных системах)!

Шаг 3. Демонтируем раздел накопителя, на который архивировали систему.

Восстановление из резервной копии

Шаг 0. Загружаемся с Live системы.

Шаг 1. Неплохо бы для начала развернуть базовую систему на диске для восстанавливаемой ОС.

Или создаем разметку диска и разделы на нем.

Шаг 2. Монтируем накопитель с резервной копией (в нашем примере — /media/backupdisk1, а корень установленной ОС примонтирован в /mnt).

Шаг 3. Распаковываем копию.

Команда разархивации

tar -xvpfJ --selinux /media/backupdisk1/our-backup. xz -C /mnt/

Описание опций tar:

x — extract, вытащить данные из архива;
v — verbose, чтобы видеть, что происходит во время разархивации;
p — сохраняем владельцев файлов и права к файлам;
f — указываем, из какого файла мы хотим восстановить копию/архив;
J — указываем при распаковке, что у нас используется компрессия xz;
-C — create. Восстановить структуру каталогов, воссоздав отсутствующие.
— -selinux — сохраняем контексты SElinux, примененные к файлам. Использовать только при наличии в системе SElinux и его поддержки tar!

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

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

Для начала определитесь с тем, где вы будите хранить backup-копии. Наилучшим решением для домашнего компьютера является использование отдельного жесткого диска, но, к сожалению, не у всех есть такая возможность. Поэтому, скорее всего, вы будете сохранять копии в отдельной директории или на отдельном разделе жесткого диска и периодически переписывать их на CD-R(W) или DVD-R(W).

Вне зависимости от того, где физически будет располагаться директория для сохранения копий, далее будем предполагать, что это директория /backup.

В простейшем случае скрипт для сохранение backup-копии будет выглядеть следующим образом:

В этом скрипте нет ничего особенного, но основные принципы он демонстрирует:

Сохранение и сжатие директории /home (домашние директории пользователей) в отдельный файл;
Сохранение и сжатие директории /etc (общие системные настройки) в отдельный файл.

Рассмотрим использованные опции команды tar:

-z Сжать файл с использованием gzip -c Создать новый архив -f Использовать указанный файл

Следующий скрипт реализует более широкие возможности для сохранения backup-копии:

В данном примере сохраняются не отдельные директории, а корневая директория /, исключая /proc, /var, /mnt, /usr и, конечно, /backup. Также к имени файла добавляется дата создания резервной копии.

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

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

Осторожно со сжатыми копиями!

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

Внешние диски для архивирования резервных копий

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

Для начала подключите предварительно отформатированный HDD. Далее подразумевается, что это /dev/hdb1, т. е. первый раздел на втором диске канала IDE1. Создайте точку монтирования:

Дополните ваши скрипты для резервного копирования следующими строками:

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

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

Далее вам предстоит настроить запуск скрипта по расписанию. На самом деле нет ничего проще. Со времен ОС UNIX существует программа cron, предназначенная для выполнения действий по расписанию. Пускай она и выполняет всю работу за вас. Откройте файл /etc/crontab и запишите новое правило:

Это правило будет выполняться каждую пятницу в 1 час ночи. Для указания удобного для вас времени запишите нужные значения в соответствующих колонках. В примере предполагается, что командой резервного копирования является /usr/bin/full-backup. Замените эту команду на имя вашего скрипта.

Результат работы будет отправлен пользователю root по почте (при условии, что у вас настроен SMTP-сервер).

Восстановление из резервных копий

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

Перед извлечением файлов из резервной копии бывает необходимым просмотреть содержимое архива. Для этого укажите опцию -t команды tar. Например, следующая команда позволит просмотреть содержимое архива /backup/backup-07-March-2005.tar.gz:

Поиск нужных файлов в архиве

Не забывайте о конвейерах. Для поиска файла в архиве вы можете использовать программу GNU grep:

Для извлечения файлов из архива предназначена опция -x команды tar. Например, следующая команда восстановит все файлы из архива /backup/backup-12-March-2005.tar.gz:

Восстановление конкретных файлов

Для восстановления определенных файлов из архива укажите их имена после имени архива. Например, следующая команда восстановит файлы home/alenitchev/adt/backup.xml иetc/sendmail.cf из архива /backup/backup-17-March-2005.tar.gz:

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

Пропуск файлов при восстановлении из tar архива

Если вы не хотите перезаписывать файлы, которые уже есть в системе, используйте параметр

Чтобы начать восстановление с какого-то определенного файла в архиве, пропустив предыдущие, используйте

Читайте также: