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

Бэкап Linux и восстановление его на другом железе

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

На прошлой неделе мы настраивали FreePBX под debian 7.8, нанимали фрилансера. В процессе настройки оказалось, что сервер (да, я так называю обычный PC) не хочет грузится с HDD при подключенных USB 3G модемах, которые мы используем для звонков на мобильные, колупание BIOSа не помогло. Непорядок. Решил, что нужно перенести его на другую железяку. Так появилось сразу две связанные задачи:

• сделать бэкап сервера;
• восстановить бэкап на другом железе.

Гугление не дало внятных ответов, как это сделать, пришлось собирать информацию кусками и пробовать. Всякие acronis’ы отбросил сразу, ибо не интересно.

Опыт общения с linux-системами у меня небольшой: настройка VPN сервера на open-vpn, ftp-сервера и еще пара мелочей. Сам себя я характеризую как человека умеющего читать маны и править конфиги 🙂

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

Начинаем копать теорию:

Второй способ требует наличия внешнего жесткого диска объемом не меньше раздела, который архивируем. Да и что с ним потом делать, непонятно, хранить на полочке? Остановился на tar, чуть сложнее в реализации, нужно будет создать MBR, но время создания/восстановления архива существенно меньше, хранить бэкап проще, полтора гига можно закинуть в облако и скачать, когда будет нужно. Записывать его можно на ту же live-флэшку, с которой буду грузиться.

Итак, план действия:

1. Создание бэкапа

Грузимся с live-флэшки, у меня это debian-live-7.8.0-amd64-standard.

Переключаемся на root:

Монтируем раздел, который будем архивировать, у меня это sda1, чтобы случайно не наломать дров, монтируем только для чтения. Посмотреть все свои разделы можно при помощи команд ls /dev | grep sd или df -l

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

Все готово для создания архива

Здесь у нас параметры: c — создать архив, v — выводить информацию о процессе, z — использовать сжатие gzip, p — сохраняем данные о владельцах и правах доступа, f — пишем архив в файл, путь к файлу, —exclude — исключаем из архива каталог (я исключил каталоги с записями разговоров и каталог с бэкапами FreePBX), /mnt/ — каталог, который архивируем.

Ждем… у меня вся подготовка и создание архива заняли 10 минут. Будь флэшка быстрее, уложился бы в 7-8 минут.

Складываем архив в надежное место за пределами офиса.

Восстановление бэкапа на другом железе

2. Размечаем диск, создаем файловую систему

Грузимся с live-флэшки, у меня все та же debian-live-7.8.0.

Переключаемся на root:

Размечаем диск. Мне понравилась утилита с псевдографическим интерфейсом cfdisk. Там все просто и понятно.

Удаляем все имеющиеся разделы. Я создал два новых раздела, один на 490 Gb под / (sda1) и 10 Gb под swap (sda2) в конце диска, т.к. он практически не будет задействован. Проверим типы разделов. Который под систему должен иметь тип 83 Linux, второй — 82 Linux swap / Solaris. Помечаем системный раздел загрузочным (bootable), сохраняем изменения и выходим.

Cоздаем файловую систему на первом разделе.

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

Монтируем отформатированный раздел

Распаковываем архив прямо с флэшки

Параметр —same-owner — сохраняет владельцев у распаковываемых файлов, x — извлекаем из архива, v — выводить информацию о процессе, p — сохраняем права доступа, f — указываем файл, который распаковываем, C — распаковываем в категорию.

4. Создаем MBR на новом диске.

Чтобы корректно создать загрузочную запись, монтируем рабочие каталоги к нашему будущему root-каталогу, у меня это /mnt. Каталоги /dev и /proc сейчас используются live-системой, используем параметр bind, чтобы они были доступны сразу в двух местах:

Переключаемся на новую систему используя chroot:

Делаем swap-раздел для новой системы:

Подключаем его же:

Чтобы grub работал, нужно указать ему правильные UUID разделов в fstab, сейчас там прописаны разделы предыдущей системы:

Открываем второй терминал (Alt+F2) под root:

И видим текущие UUID разделов.

Вручную переписываем их в fstab переключаясь между Alt+F1 и Alt+F2. Да, муторно, но попытки копировать занимали у меня больше времени, чем переписывание. Сохраняем fstab.

Устанавливаем grub2. У меня один физический диск, поэтому ставим его на sda:

На чистый диск должно встать без ошибок. Обновляем информацию из fstab:

Возвращаемся в Live-систему:

Размонтируем все каталоги:

Если вылазят процессы, которые используют эти каталоги, убиваем их используя fuser.

Все, поехали. Грузимся с жесткого диска:

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

5. Тестирование и устранение неполадок.

Показывет интерфейсы eth1 и lo, гугление сказало, что gateway можно прописать только подключению eth0, остальные рассчитаны только на работу внутри сети.

Похоже, отсутствие eth0 вызвано способом переноса системы. Находим файл, который отвечает за нумерацию интерфейсов, смотрим туда:

Действительно, там два активных интерфейса, определенных MAC’ами. Комментируем первый, второму прописываем eth0.

Перезапуск /etс/init.d/networking не помог, поэтому перезагружаемся:

Подключаем донглы, проверяем, все работает.
Спасибо за внимание.

Источник

linux-notes.org

Хотелось бы рассказать как можно было бы сделать бэкап полной системы на примере centOS 7.

Если вам нужно создать backup всей вашей системы, то необходимо выполнить команду:

Этой команды хватит чтобы создать бекап. Поговорим о том что же в этой команде написано:

• Запускаем команду от рута и создадим так званый тарбол (утилита tar с опцией «c») и заархивируем его в архив gz (опция «z»).
• С опцией «—exclude» исключим из нашего архива все системные папки и файлы устройств и наш архив (чтобы он рекурсивно не начал запаковывать сам в себя).
• По окончанию, получим в корневой директории наш сжатый архив системы в my_backup.tgz файле.

Бекап мы то сделали, но наверное нужно еще и научится разворачивать его. Как это сделать? Ну, для начала, нужна будет всё-таки работающая система. Можно выполнить установку системы или просто загрузиться с Live CD/DVD). Я, буду думать что у всех есть уже готовая установленная и готова к работе система на которой хотим сделать развертку my_backup архива.

Для этого необходимо выполнить команду:

ВСЕ! ГОТОВО! На этом тема «как сделать бэкап всей системы в centos» завершена.

11 thoughts on “ как сделать бэкап всей системы в centos ”

# tar xvpfz /backup.tgz -C/
tar (child): /backup.tgz: Функция open завершилась с ошибкой: Нет такого файла или каталога
tar (child): Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error is not recoverable: exiting now

вот такую штуку мне пишет, когда пытаюсь разархивировать

У Вас:
# tar xvpfz /backup.tgz -C/

Это ошибка, последний слеш слит с командой.

Нужно:
# tar xvpfz /backup.tgz -C /

Нужно быть внимательней 😉

Просто имя файла указано не верно. При создании файл назывался my_backup.tgz, а при распаковке просто backup.tgz =)

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

идея хорошая но при восстановлении не пашет, подскажите рабочую альтернативу?

А как восстановить этот архив с лайв?

1. Заливаем созданный архив ( у меня название my_backup.tgz) на нужный сервер.
2. Выполняем:

PS: Путь где лежит архив может отличаться!

3. Выполняем перезагрузку ОС и смотрим что получилось.

привет!
спасибо за помощь!
команда бекап архивирование работает

— подскажите, можно ли разархивировать сверху рабочего сервера, т.е там , где устанавлены все ПО и сайт?
(и если да, может подсказать команду крон, чтобы по времени архив создавался и если возможно, чтобы последние копии сохранялись, а предыдущие удалялись.
Или для этого необ.ПО ставить?)

— или это работает только в случае, когда диск отформатирован?

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

Можно команду в крон добавить, например вот такую:

lib/udev/path_id
tar: Exiting with failure status due to previous errors

у меня такая ошибка

Добавить комментарий Отменить ответ

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Источник

Centos

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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

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

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

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

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

План восстановления на «голое железо» — это просто план, разработанный администратором CentOS, для обеспечения работы жизненно важных систем со всеми нетронутыми данными. Предполагая 100% системный сбой и потерю всего предыдущего системного оборудования, администратор должен иметь план для достижения времени безотказной работы с минимальными затратами времени на обработку пользовательских данных. Монолитное ядро, используемое в Linux, на самом деле значительно упрощает восстановление с использованием системных образов с использованием системных образов. Где Windows использует архитектуру микроядра.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В этом уроке мы обсудим rsync различными способами —

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

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

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

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

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

Ниже приведены наиболее распространенные ключи с rsync —

переключатель	действие
-a	Режим архива и предполагает -r, -p, -t, -g, -l
-d	Синхронизировать только дерево каталогов, без файлов
-р	Рекурсивно в каталог
-l	Копировать символические ссылки как символические ссылки
-п	Сохранить разрешения
-г	Сохранить группу
-v	Подробный вывод
-z	Сжатие по сети
-ИКС	Сохранить расширенные атрибуты
-А	Сохранить ACL
-t	Сохранить временные метки
-W	Передача всего файла, а не инкрементальных блоков
-u	Не перезаписывайте файлы на цели
—прогресс	Показать прогресс передачи
—удалять	Удалить старые файлы на цели
—max-size = XXX	Максимальный размер файла для синхронизации

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

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

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

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

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

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

/ root для синхронизированной резервной копии —

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

Мы хороши для синхронизации всего нашего каталога / etc / —

Наш синхронизированный каталог / etc / —

Теперь давайте сделаем инкрементную rsync —

Только наш файл 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 — это утилита для Linux, которая существует с самого начала появления ядра Linux и GNU Utilities.

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

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

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

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

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

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

Ниже приведены общие параметры командной строки и параметры для dd —

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

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

Сначала давайте настроим виртуальный CD-ROM и прикрепим наш ISO-образ для загрузки вместо установки виртуального сервера CentOS —

Теперь установите загрузочный диск —

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

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

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

Лучший способ сделать это —

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

Conv = sync используется, когда байты должны быть выровнены для физического носителя. В этом случае dd может получить ошибку, если точные выравнивания 4K не читаются (скажем … файл, который составляет всего 3K, но должен занимать минимум один блок 4K на диске. Или, просто чтение ошибки и файл не может быть прочитан дд.) Таким образом, dd с conv = sync, noerror будет заполнять 3K тривиальными, но полезными данными на физическом носителе с выравниванием блоков 4K. Пока не отображается ошибка, которая может завершить большую операцию.

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

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

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

gzip и tar — две утилиты, к которым должен привыкнуть администратор CentOS. Они используются для гораздо большего, чем просто распаковка архивов.

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

Tar — это утилита архивирования, похожая на winrar в Windows. Его название Tape Archive, сокращенно tar, подводит итог утилиты. tar возьмет файлы и поместит их в архив для логического удобства. Следовательно, вместо десятков файлов, хранящихся в / etc. мы могли бы просто «скопировать» их в архив для удобства резервного копирования и хранения.

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

Ниже приведен список общих параметров командной строки и параметров, используемых с tar —

переключатель	действие
-с	Создает новый архив .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 (однако это иногда желаемый результат)

Давайте создадим сжатый архив tar из наших удаленных резервных копий, скопированных с рабочей станции Mac —

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

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

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

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

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

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

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

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

7zip — это простая установка после загрузки и конфигурирования наших репозиториев EHEL в CentOS.

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

Теперь давайте используем 7z для шифрования нашего архива gzip паролем. Синтаксис для этого довольно прост —

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

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

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

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

7zip — это расширенное предложение с большим количеством функций, чем gzip или bzip2. Тем не менее, это не так стандартно с CentOS или среди мира Linux. Таким образом, другие утилиты должны использоваться как можно чаще.

Источник