Возможность случайного повреждения системы, даже такой надёжной как Linux, всегда существует. Как правило, переустановка ОС занимает много времени и сил. Чтобы избежать неприятностей подобного рода следует пользоваться резервным копированием (бэкап) Ubuntu Linux.
Положительные стороны создания бэкапа убунту именно при помощи rsync заключаются в том, что для копирования и восстановления системы нет необходимости в установке дополнительных пакетов и ПО. Всё делается при помощи консоли. Но не пугайтесь работы с консолью! В нашем случае всё будет предельно просто и понятно.
Данная команда является очень мощным инструментом для работы с файлами. Ознакомиться с полным списком её возможностей можно написав в консоли man rsync . Предлагаемый метод резервного копирования ubuntu через rsync является самым простым и лёгким в освоении.
Чтобы всё было предельно просто - расскажу как у меня происходит backup системы. Мой жесткий диск разбит на 5 разделов, из которых 2 раздела отведено под Ubuntu - системный раздел / и раздел для информации пользователей /home . Я копирую всё содержимое системного раздела / на раздел пользователей в специальную папку /home/.backup . В случае неполадок ОС Ubuntu я запускаюсь с LiveCD и просто копирую бэкап убунту на системный раздел. Основываясь на этом примере ниже будет описана процедура резервного копирования и восстановления Ubuntu Linux.
Выполняем в консоли:
sudo rsync -aulv -x / /windows/FILES/.backup/
А теперь давайте разберёмся с синтаксисом этой нехитрой команды
Я специально поставил точку в начале имени директории, чтобы она была невидимой. А также указал, что владельцем директории является суперпользователь и доступ к ней только у него, чтобы лишний раз туда не лазить.
Допустим, у нас накрылась система и нужно восстановить убунту . Запускаем компьютер при помощи LiveCD с Linux, открываем консоль. Теперь нужно примонтировать (подключить) системный раздел и раздел пользователей, чтобы совершить восстановление системы и здесь можем пойти двумя путями. Первый способ основан на кликах мышки, а второй - на работе в консоли.
Открываем файловый менеджер и видим в левом углу список разделов жесткого диска на ПК. Подключаем их нажатием мышки, после чего они станут доступны для обзора, а их точка монтирования будет находится в директории /media/ . Определяем какой из разделов системный, а какой пользовательский. Недостаток такого способа в том, что разделы получат сложный адрес точки монтирования вроде /media/2F45115E1265048F . Запоминаем адрес точки монтирования системного и пользовательского разделов. Теперь переходим к непосредственному восстановлению, пропускаем раздел «Способ №2″.
Для более продвинутых пользователей. Плюс в том, что мы сами назначим имя точкам монтирования и сможем обойтись без громозких адресов.
1. Выводим список разделов HDD:
sudo fdisk -l
эта команда покажет нам полный список разделов, имеющихся в системе. К примеру, у меня вот такая картинка.
Устр-во Загр Начало Конец Блоки Id Система
/dev/sda1
771120 27342629 13285755 83 Linux
/dev/sda2
27342630 822190634 397424002+ 83 Linux
/dev/sda3 * 822190635 883639259 30724312+ 7 HPFS/NTFS/exFAT
/dev/sda4 883639260 976768064 46564402+ 5 Расширенный
/dev/sda5 883639323 976768064 46564371 7 HPFS/NTFS/exFAT
В столбце «Система» легко увидеть, что файловая система Linux располагается на разделах:
2. Монтируем Linux разделы командой mount. Для этого сперва создадим точку монтирования для каждого раздела:
sudo mkdir /media/1
sudo mkdir /media/2
Используем mount чтобы примонтировать разделы:
sudo mount dev/sda1 /media/1
sudo mount dev/sda2 /media/2
3. Определяем какой из разделов является системным, а какой есть папка пользователя. Можем либо просто зайти через файловый менеджер в примонтированные каталоги и посмотреть какой из них системный. Или же, воспользуемся командой ls (показывает список файлов по заданному адресу):
ls /media/1
ls /media/2
Если Вы не слишком опытный пользователь - подскажу, что системный раздел Linux, как правило, будет иметь следующие папки: bin, boot, dev, etc, mnt и т. д.
Допустим мы установили, что системный раздел сейчас примонтирван по адресу /media/1
.
1. Копируем файлы из резервной копии. Используем такую же команду:
sudo rsync -aulv -x /media/2/.backup/ /media/1/
при использовании графического способа №1 вместо /media/1/ и /media/2/ у вас будут другие точки монтирования!
2. Отмонтируем разделы по окончанию копирования:
sudo umount /media/1
sudo umount /media/2
Перезагружаем компьютер и наслаждаемся восстановленной из бэкапа Ubuntu.
Возможность случайного повреждения системы, даже такой надёжной как Linux, всегда существует. Как правило, переустановка ОС занимает много времени и сил. Чтобы избежать неприятностей подобного рода следует пользоваться резервным копированием (бэкап) Ubuntu Linux. Я не буду останавливаться на различных способах создания резервной копии Ubuntu, а расскажу метод, которым пользуюсь сам и советую другим. Мне его посоветовал один мой друг. Вы также можете посмотреть о создании резервной копии всех установленных программ в системе в этой статье . Но этот способ лучше использовать не для бэкапа системы, а в тех случаях, когда нам нужно установить аналогичное ПО на много компов, имеющих одинаковую ОС и конфигурацию.
при использовании графического способа №1 вместо /media/1/ и /media/2/ у вас будут другие точки монтирования!2. Отмонтируем разделы по окончанию копирования: sudo umount /media/1 sudo umount /media/2 Перезагружаем компьютер и наслаждаемся восстановленной из бэкапа Ubuntu.
Резервное копирование системы очень важно, поскольку если у вас есть резервная копия всех файлов, настроек или даже системы полностью, то вы можете ее восстановить в случае возникновения проблем. Несмотря на стабильность Linux, эта система может ломаться, например, после обновления или когда вы экспериментировали и сделали что-то не так.
Если вы делаете резервное копирование Ubuntu, то потом сможете все очень просто восстановить, даже если система была почти убита. Уже существует множество программ для создания резервных копий как файлов, так и всего диска, одна из самых популярных из них - это . Но мы не будем их сегодня рассматривать. В этой статье мы поговорим о том, как выполнить резервное копирование системы без сторонних программ, с помощью системных команд. Это может быть полезнее в некоторых случаях.
Рассмотрим самые распространенные способы копирования среди администраторов и обычных пользователей.
Самый простой способ резервного копирования Ubuntu, кстати, именно эту возможность использует MintBackup в LinuxMint, это получение списка всех установленных пакетов. Да, тут вы не сохраните всю конфигурацию, зато сможете очень быстро восстановить все установленные программы.
Если учесть, что большинство конфигурационных файлов находятся в домашней папке пользователя, а она не стирается при переустановке, то остальные файлы не такая уже большая проблема. А такая резервная копия будет занимать всего несколько килобайт. Для выполнения резервной копии наберите такую команду:
dpkg --get-selections | grep -v deinstall > backup.txt
sudo dpkg --set-selections < backup.txt
sudo apt-get -y update
$ sudo apt-get dselect-upgrade
Файл со списком пакетов нужно поместить в текущую папку. Таким образом, вы очень быстро вернете все ранее установленные программы с минимальными затратами времени и в то же время получите чистую систему.
Резервное копирование таким способом более надежно, поскольку вы не просто создаете список установленных программ, а делаете архив из всей файловой системе. Фактически, вы можете потом развернуть этот архив на любой машине и получить полноценную операционную систему после настройки драйверов.
Таким способом часто создаются резервные копии систем на серверах и для него достаточно просто использовать утилиту tar и не нужны сторонние программы. Для создания архива используйте такую команду:
sudo tar czf /backup.tar.gz --exclude=/backup.tar.gz --exclude=/home --exclude=/media --exclude=/dev --exclude=/mnt --exclude=/proc --exclude=/sys --exclude=/tmp /
В этой команде все достаточно просто несмотря на ее запутанность. Опция c означает, что нужно создать архив (Create), z - включает сжатие Gzip. Затем с помощью опции -f мы указываем файл, в который нужно сохранить результат. Затем с помощью серии опций --exclude мы исключаем из архива сам файл архива, домашний каталог и директории с виртуальными файловыми системами. В самом конце указываем папку, с которой стоит начать сбор данных - /. Вот и все. Процесс займет очень много времени, но когда он завершится, вы получите полную резервную копию системы в корневом каталоге.
Если система повреждена, вам нужно загрузиться с LiveCD/USB, и примонтировать корневой каталог в /mnt/. Затем подключите носитель с резервной копией и выполните команду для распаковки:
sudo tar xf /run/media/имя_носителя/backup.tar.gz -C /mnt
Команда быстро распакует все, что было сохранено и вам останется только перезагрузить компьютер, чтобы вернуться к своей основной системе. Здесь не восстанавливается только загрузчик, нужно отдельно если он был поврежден.
Этот способ очень похож на второй, но здесь архив не создается, а данные просто переносятся в другую папку. Это может более полезно при простом копировании операционной системы в другое место. Команда выглядит вот так:
rsync -aAXv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} / /папка/назначения
Набор опций -aAX включают передачу в режиме архива, что гарантирует полное копирование символических ссылок, устройств, разрешений и расширенных атрибутов, при условии, что их поддерживает целевая файловая система. Опция --exclude, как и раньше, исключает из копии виртуальные файловые системы.
После завершения копирования вам останется отредактировать /etc/fstab и заменить в нем адрес корневого раздела на новый. А также создать новый конфигурационный файл для загрузчика, автоматически или вручную.
Позволяет создать полную копию раздела или даже всего диска. Это самый надежный, но в то же время потребляющий большое количество памяти способ выполнить резервное копирование системы Ubuntu. Утилита просто переносит весь диск по одному байту в образ. Команда выглядит вот так:
sudo dd if=/dev/sda4 of=~/backup.img
Здесь /dev/sda4 - это ваш корневой раздел. После завершения выполнения команды вы получите готовый образ, затем, чтобы восстановить систему из этой копии достаточно поменять опции местами и указать путь к файлу копии:
sudo dd if=~/backup.img of=/dev/sda4
Правда, процесс может занять достаточно много времени, в зависимости от скорости работы вашего диска.
Преимущество Squashfs в том, что это полноценная файловая система в одном файле, которую можно очень быстро примонтировать и быстро извлечь нужные файлы. Кроме того, файловую систему можно открыть привычными менеджерами архивов. Для создания образа со всей системы используйте:
sudo mksquashfs / /root-backup.sqsh -e root-backup.sqsh home media dev run mnt proc sys tmp
Теперь, чтобы примонтировать созданный образ будет достаточно набрать такую команду:
sudo mount /root-backup.sqsh /mnt/ -t squashfs -o loop
А уже отсюда вы можете извлечь любой файл или перенести все это в реальную файловую систему с помощью cp -p.
Резервное копирование Ubuntu 16.04 очень важно для поддержания вашей операционной системы в нормальном состоянии. В случае любой неожиданной ситуации вы сможете все восстановить. Если вас интересуют графические программы для бэкапа, вы можете попробовать remastersys или
Никаких отговорок: безопасное распределенное сетевое резервное копирование своими руками
Если вы - пользователь Linux, то в вашем распоряжении уже имеются исключительно мощные инструменты для создания специализированных решений резервного копирования. Решения, описанные в данной статье, позволяют выполнять как простое, так и более продвинутое сетевое резервное копирование, используя инструменты с открытыми исходными кодами, входящие в состав практически любого дистрибутива Linux.
Чтобы упростить освоение материала, в данной статье используется пошаговый подход.
Мы начнем с простого, но эффективного механизма архивирования, а затем перейдем к расширенному решению для распределенного резервного копирования. Взгляните на удобный скрипт arc, позволяющий создавать резервные копии из командной строки Linux.
Скрипт arc принимает в качестве параметра путь к файлу или каталогу, после чего создает архивный файл, имя которого содержит текущую дату. Например, для архивирования каталога beoserver скрипту arc необходимо передать путь к нему, после чего будет сформирован сжатый архив, имеющий имя приблизительно следующего вида: beoserver.20040321-014844.tgz
Упорядочить архивные файлы поможет включение в их имена даты и времени с помощью команды date . Дата имеет следующий формат: год, месяц, день, час, минуты, секунды - секунды, вероятно, в нашем случае уже лишние. О параметрах команды date можно узнать из ее руководства, просмотреть которое можно командой man date . Кроме того, в листинге 1 мы используем параметр -v (verbose, подробно) команды tar . Команда tar , запущенная с данным параметром, отображает имена всех архивируемых файлов. Если этого не требуется, параметр -v можно убрать.
Простая схема резервного копирования весьма полезна, но она требует ручного выполнения операций. Лучшие отраслевые методики рекомендуют регулярно выполнять резервное копирование, хранить резервные копии на разных носителях и в разных местах. Базовый принцип заключается в том, чтобы избегать зависимости от единственного носителя или места хранения носителей.
Мы будем решать эту проблему в следующем примере, основанном на некоторой распределенной сети, схема которой, приведенная на рисунке 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 сгенерирует незашифрованные ключи. Нетрудно догадаться, что это - не самая лучшая идея. В ответ на запрос парольной фразы следует ввести текстовое сообщение разумной длины, состоящее из алфавитно-цифровых символов, а не ограничиваться обыкновенным односложным паролем.
Поскольку каталог.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.
После установки новых открытых ключей мы сможем заходить на каждый из серверов, используя парольную фразу, указанную при создании открытого и секретного ключей. А пока войдите на каждый из серверов и добавьте содержимое файла offsite.pub в конец файла authorized_keys, находящегося в каталоге.ssh. Это можно сделать с помощью текстового редактора или команды cat:
На следующем шаге мы примем дополнительные меры безопасности. Сначала мы изменим права доступа к.ssh таким образом, чтобы доступ к данному каталогу на чтение, запись и выполнение имел только его владелец. Затем мы убедимся, что доступ к файлу authorized_keys имеет только его владелец. И наконец, мы удалим за ненадобностью ранее загруженный файл открытого ключа offsite.pub. Очень важно правильно назначить права доступа, поскольку сервер OpenSSH может отказать в использовании ключей, для файлов которых заданы небезопасные права доступа.
После выполнения этого процесса на сервере 2 мы перейдем на сервер внешнего хранилища для проверки работы нового способа доступа, основанного на парольной фразе. Сделать это можно, выполнив следующую команду на сервере внешнего хранилища:
$ ssh -v [email protected]
Параметр -v , включающий режим вывода подробных сообщений, позволяет отображать отладочную информацию в ходе проверки доступа вашей учетной записи к удаленному серверу с использованием новой парольной фразы вместо первоначального пароля. В отладочную информацию входят сведения, недоступные пользователю в иных условиях, в том числе высокоуровневая информация о работе процесса аутентификации. В ходе обычной работы указывать параметр -v нет необходимости, но при проверке соединения это очень полезно.
ssh-агент играет роль шлюза, по требованию предоставляющего безопасный доступ к ключам. После запуска ssh-агент работает в фоновом режиме и может использоваться такими программами пакета OpenSSH как, например, ssh или scp. С его помощью программа ssh может использовать заранее расшифрованный ключ вместо того, чтобы запрашивать парольную фразу при каждой необходимости.
Давайте взглянем на программу ssh-agent поближе. 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.
Теперь при получении доступа к 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":
К данному моменту мы узнали, как работают некоторые программы пакета 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 смогут осуществлять безопасный доступ к удаленным машинам без ввода пароля. Теперь наше решение совмещает преимущества повышенной безопасности и простоты использования.
Нашей следующей задачей является написание скриптов, выполняющих операции, необходимые для резервного копирования. Целью работы данных скриптов будет создание полной резервной копии баз данных, находящихся на серверах server1 и server2. На каждом из серверов в рассматриваемом примере установлена СУБД MySQL. Соответственно для экспорта нескольких таблиц в виде SQL-скрипта мы будем использовать утилиту mysqldump, работающую в командной строке.
На сервере 2 мы разместим аналогичный скрипт, осуществляющий резервное копирование уникальных таблиц установленной на нем БД. Для каждого из скриптов необходимо задать признак исполняемого файла, выполнив команду:
:$ chmod +x dbbackup.sh
Разместив копии файла dbbackup.sh на серверах 1 и 2, мы возвращаемся на сервер внешнего хранилища, где создаем скрипт, выполняющий их перед запуском процесса удаленного копирования сжатых архивов (.tgz).
Скрипт 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 . Теперь введите две новые записи, после чего сохраните и закройте файл.
Запись файла crontab состоит из двух основных частей: спецификации времени выполнения и команды, подлежащей выполнению. Спецификация времени выполнения включает следующие поля:
Рекомендуется регулярно проводить проверку резервных копий чтобы убедиться в правильной работе процесса. Автоматизация процессов помогает избавиться от ненужной рутины, но заменить добросовестного отношения к делу она не может. Если ваши данные заслуживают резервного копирования, то время от времени имеет смысл проводить выборочную проверку качества его выполнения.
Возможно, стоит создать задачу планировщика cron, которая по меньшей мере раз в месяц напоминала бы вам о необходимости проверки резервных копий. Кроме того, неплохо было бы менять ключевую пару по истечении определенного периода; напомнить вам об этом может также задача планировщика cron.
Для повышения уровня информационной безопасности можно установить и настроить на каждом сервере систему обнаружения вторжений (Intrusion Detection System, IDS), например, Snort. Система обнаружения вторжений предназначена для оповещения о попытках взлома системы, происходящих в данный момент или имевших место недавно. Наличие такой системы позволит наращивать уровень информационной безопасности за счет применения таких технологий как цифровая подпись и шифрование резервных копий.
Архивные файлы можно защитить с помощью распространенных инструментов с открытым исходным кодом, например GNU Privacy Guard (GnuPG), OpenSSL и ncrypt, однако, применять их без дополнительного уровня защиты, предоставляемого системой обнаружения вторжений, не рекомендуется (ссылки на дополнительную информацию по Snort приведены в разделе ).
В статье было продемонстрировано удаленное выполнение скриптов на серверах и осуществление безопасного автоматического копирования файлов. Я надеюсь, что ее прочтение дало вам информацию для размышлений о том, как защитить ваши ценные данные с помощью таких инструментов с открытыми исходными кодами, как OpenSSH и Snort.
С егодня мы хотели переустановить одну из виртуальной машины, которая работает с сервере Ubuntu 16.04 LTS. Перед установкой, мы попытались сделать резервную копию всей системы. При поиске простого способа сделать это, нашли убедительное решение в вики – странице Arch Linux. Мы никогда не думали, что это все гораздо проще. Мы копировали весь корень с помощью команды Rsync в одно касание. Да, это просто команда в одну строку. Хотя там очень много инструментов для резервного копирования ваших систем, этот метод намного проще и удобнее. Кроме того, этот метод лучше, чем клонирование диска с помощью команды dd . Потому что это не имеет значения, если ваш жесткий диск другого размера, или использует другую файловую систему. Этот метод будет работать во всех случаях.
В этом кратком руководстве мы объясним, как сделать резервную копию всей системы Linux с помощью утилиты Rsync.
Во- первых, вставьте резервный носитель (внешний жесткий диск или другой носитель). Затем найдите букву диска с помощью команды «fdisk -l». В нашем случае, идентификатор диска /dev/sdb1 . Смонтируйте диск в любое место по вашему выбору.
Sudo mount /dev/sdb1 /mnt
Для резервного копирования всей системы, все, что вам нужно сделать, это открыть терминал и выполнить следующую команду в качестве пользователя root :
Sudo rsync -aAXv / --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} /mnt
Эта команда создаст резервную копию всего каталога / , за исключением каталогов /dev, /proc, /sys, /tmp, /run, /mnt, /media, /lost+found.
Разобьем вышеупомянутую команду и посмотрим, что делает каждый аргумент.
Пожалуйста, помните, что вы должны исключить каталог назначения , если он существует в локальной системе. Это позволит избежать бесконечного цикла.
Чтобы восстановить резервную копию, просто поменяйте местами путь источника и назначения в команде выше.
Пожалуйста, помните, что это подходит только для локальных и автономных систем . Если ваша система активно имеет доступ к некоторым другим системам в сети, это не лучшее решение. Так, содержание этих систем может быть постоянно обновляется каждую минуту, и некоторые файлы могут изменяться в процессе Rsync. Скажем, например, когда Rsync достигнет файла 2, содержимое предыдущего файла (File 1) может быть изменено. Это оставит вас с ошибкой зависимостей, когда вам нужно будет использовать эту резервную копию. В таких случаях, резервное копирование на основе снимка является лучшим подходом. Поскольку система получит «заморозку» перед началом процесса резервного копирования и позволит его «разморозить», когда заканчивает процесс резервного копирования, так что все файлы будут совместимы.
И это все. Надеюсь это поможет. Если вы найдете наши гиды полезной, пожалуйста, поделитесь ими в социальных, профессиональных сетей, так что другие пользователи также могут извлечь из них выгоду. Мы будем продолжать отправлять более хорошие питания каждый день. Оставайтесь с нами, чтобы прочитать удивительные питания.
