Многие задаются вопросом о том как сохранить собственные настройки системы, и личные данные так, чтобы потом в случае непредвиденных обстоятельств можно было их легко восстановить. Насколько мне известно в Windows и Mac OS X с этим проблем нет, так как средства для резервоного копирования предустановлены в обоих операционных системах. Ни в одном дистрибутиве Linux опробованных мной я не видел инструментов по умолчанию идущих с системой предоставляющих такой функционал. Если быть точным, то средства для резервного копирования в Linux есть по умолчанию, но не все новички знают о них и тем более не знают как использовать эти инструменты.
Существует три основных способа для создания резервной копии данных и системы в Linux
- Использование архиватора для создания сжатой копии системы
- Снятие образа жесткого диска
- Использование специальных, дополнительных утилит
На мой взгляд первый способ самый универсальный и применим практически в любой ситуации. Достоинства этого метода в том, что архив с резервной копией занимает не так уж много места и существует возможность выбора что включать в бэкап, а что исключить.
Для первого способа нам потребуется целевая система установленная на разделе/разделах жесткого диска и флешка/DVD диск с Live системой. Например Live CD с которого Вы ставили систему. Стоит заметить, что потребуется также раздел на который нужно сохранить данные. Его также нужно примонтировать
Итак предположим что ОС установлена на первом разделе первого жесткого диска (/dev/sda1). Загружаемся с Live CD и монтируем этот раздел скажем в /mnt
Sudo mount /dev/sda1 /mnt
Монтируем раздел на котором предполагается разместить бэкап
Sudo mkdir /backup sudo mount /dev/sda3 /backup
Используемая в Linux команда ls -a /mnt поможет проверить тот ли раздел мы смонтировали. Если вышла ошибка, то следует запустить cfdisk и найти нужный раздел после чего примонтировать его как показано выше.
Далее переходим в директорию примонтированного раздела с системой и смотрим какие директории в ней мы будем бэкапить.
Cd /mnt ls -a
Увидев список директорий включаем нужные в бэкап.
Sudo su tar -cvjpf /backup/Backup.tar.bz2 bin boot dev etc home lib lib32 lib64 media mnt opt proc root sbin sys tmp usr var
Если у Вас немного другой набор директорий, например отсутствуют каталоги lib32 и lib64, то советую просто архивировать все директории созданные не Вами. С директориями созданными Вами поступайте на свое усмотрение. В некоторых мануалах советуют исключить из бэкапа /proc, /dev, /sys, но я наученный собственным опытом скажу, что этого делать не стоит. Бэкап должен быть полным и включать все системные директории. При монтировании директорий с виртуальными файловыми системами таких как /proc и /sys их содержимое окажется пустым, но это избавит Вас от создания их вновь и присвоения им правильных разрешений (прав). Результатом выполнения этих действий будет появление в целевой директории /backup архива Backup.tar.bz2 содержащего резервную копию системы которую всегда можно восстановить.
Для того чтобы рекурсивно затарить все директории и файлы в текущей директории нужно:
Tar -cvjpf /backup/Backup.tar.bz2 .
Обращаю внимание, что символ "." это не опечатка. В данном случае содержимое архива не будет иметь абсолютных путей и предпочтительнее, особенно в процессе восстановления.
Для того чтобы исключить какие либо файлы и директории из создаваемого бэкапа нужно их указать. Исключение возможно как файлов, так и директорий, а также по паттернам. Подробнее читайте в man tar.
Tar -cvjpf /backup/Backup.tar.bz2 . --exclude=cisco.jpg --exclude=folder
Восстановление бэкапа тоже дело не хитрое. Для успешного восстановления нам понадобится все тот же Live CD, сам бэкап и некоторое количество времени. Загружаемся с Live CD и монтируем разделы по уже известной схеме описанной выше. Если Вы не переносите бэкап на другой жесткий диск, то имеющуюся систему нужно предварительно удалить.
Sudo rm -rf /mnt/*
Копируем архив с бэкапом на целевой раздел
Sudo su cp /backup/Backup.tar.bz2 /mnt/
Переходим в нашу будущую систему и разархивируем бэкап
Cd /mnt tar -xvjpf Backup.tar.bz2
Перейдем к другому способу
который менее удобен по причине возможно большого размера образа и невозможностью выбросить из него заведомо ненужных данных. Плюс же этого способа состоит в том, что созданный образ является абсолютно точной копией существующей системы повторяющий и файловые системы и все данные в них содержащихся. Данный способ еще используют для дефрагментации файловых систем которые не имеют собственных утилит для этого.
В этом способе нужно загрузиться с Live CD и примонтировать раздел диска на который мы хотим сохранить образ. Монтировать раздел системы который мы хотим забэкапить - монтировать не нужно! Прошу обратить на это внимание. Создаем образ следующей командой
Sudo su dd if=/dev/sda1 bs=8M of=/backup/Backup.img
Если раздел был большой, то запасаемся терпением и идем пить чай/кофе или что то покрепче пока выполняется создание образа. Главное не пить "чего то покрепче" в больших количествах перед его восстановлением.
Восстановление еще проще: Нужно загрузиться с Live CD, примонтировать раздел на котором лежит бэкап и восстановить его командой (при условии что восстанавливаемая система по прежнему на /dev/sda1. Ошибки в лучшем случае грозят потерей коллекции прона тщательно отобранного Вами за последние годы проведенные в стадии полового созревания, а в худшем - разбитием монитора клавиатурой когда Вы осознаете чего лишились:-D).
Dd if=/backup/Backup.img bs=8M of=/dev/sda1
После завершения выполнения задачи Вы получите точную копию той системы которая была на момент создания резервной копии.
Третьим способом создания/восстановления резервных копий я абсолютно не пользовался за ненадобностью. Могу лишь предположить, что используя этот метод Вам не удастся контролировать содержимое бэкапа и такой софт потянет еще множество различных зависимостей нужных для его работы. Если все вышеописанное показалось Вам сложным, то можно попробовать самостоятельно найти в Google или репозитории использумомого дистрибутива такой софт. На вскидку можно посоветовать
Я работаю в организации с маленьким штатом, деятельность тесно связана с IT и у нас возникают задачи по системному администрированию. Мне это интересно и частенько я беру на себя решение некоторых.
На прошлой неделе мы настраивали FreePBX под debian 7.8, нанимали фрилансера. В процессе настройки оказалось, что сервер (да, я так называю обычный PC) не хочет грузится с HDD при подключенных USB 3G модемах, которые мы используем для звонков на мобильные, колупание BIOSа не помогло. Непорядок. Решил, что нужно перенести его на другую железяку. Так появилось сразу две связанные задачи:
- сделать бэкап сервера;
- восстановить бэкап на другом железе.
Опыт общения с linux-системами у меня небольшой: настройка VPN сервера на open-vpn, ftp-сервера и еще пара мелочей. Сам себя я характеризую как человека умеющего читать маны и править конфиги:)
Ниже я описываю свой частный случай и почему я поступил именно так. Надеюсь, новичкам будет полезно, а бородатые админы улыбнутся вспомнив молодость.
Начинаем копать теорию:
По созданию бэкапов уйма статей, я для себя отметил два способа: tar - упаковывает и сжимает все файлы, при этом не сохраняется MBR, мой бэкап будет весить около 1.5 Gb; - делает полную копию раздела, включая MBR и всю область, где нет файлов, архив будет равен размеру раздела, в моем случае ~490 Gb.Второй способ требует наличия внешнего жесткого диска объемом не меньше раздела, который архивируем. Да и что с ним потом делать, непонятно, хранить на полочке? Остановился на tar, чуть сложнее в реализации, нужно будет создать MBR, но время создания/восстановления архива существенно меньше, хранить бэкап проще, полтора гига можно закинуть в облако и скачать, когда будет нужно. Записывать его можно на ту же live-флэшку, с которой буду грузиться.
Итак, план действия:
- создание бэкапа;
- форматирование, разметка диска, создание файловой системы;
- восстановление бэкапа;
- создание MBR;
- тестирование и устранение неполадок.
1. Создание бэкапа
Грузимся с live-флэшки, у меня это debian-live-7.8.0-amd64-standard.Переключаемся на root:
Sudo su
Монтируем раздел, который будем архивировать, у меня это sda1, чтобы случайно не наломать дров, монтируем только для чтения. Посмотреть все свои разделы можно при помощи команд ls /dev | grep sd
или df -l
Mount -o ro /dev/sda1 /mnt
Наша флэшка уже примонтирована, но в режиме только чтения, нужно перемонтировать для чтения-записи, чтобы писать туда бэкап.
Mount -o remount,rw /dev/sdb1 /lib/live/mount/medium
Все готово для создания архива
Tar -cvzpf /lib/live/mount/medium/backupYYYYMMDD.tgz --exclude=/mnt/var/spool/asterisk/monitor --exclude=/mnt/var/spool/asterisk/backup /mnt/
Здесь у нас параметры: c - создать архив, v - выводить информацию о процессе, z - использовать сжатие gzip, p - сохраняем данные о владельцах и правах доступа, f - пишем архив в файл, путь к файлу, --exclude - исключаем из архива каталог (я исключил каталоги с записями разговоров и каталог с бэкапами FreePBX), /mnt/ - каталог, который архивируем.
Ждем… у меня вся подготовка и создание архива заняли 10 минут. Будь флэшка быстрее, уложился бы в 7-8 минут.
Отмонтируем диск:
Umount /mnt
… и перезагружаемся.
Reboot
Складываем архив в надежное место за пределами офиса.
Восстановление бэкапа на другом железе
2. Размечаем диск, создаем файловую систему
Грузимся с live-флэшки, у меня все та же debian-live-7.8.0.Переключаемся на root:
Sudo su
Размечаем диск. Мне понравилась утилита с псевдографическим интерфейсом cfdisk. Там все просто и понятно.
Cfdisk
Удаляем все имеющиеся разделы. Я создал два новых раздела, один на 490 Gb под / (sda1) и 10 Gb под swap (sda2) в конце диска, т.к. он практически не будет задействован. Проверим типы разделов. Который под систему должен иметь тип 83 Linux, второй - 82 Linux swap / Solaris. Помечаем системный раздел загрузочным (bootable), сохраняем изменения и выходим.
Cоздаем файловую систему на первом разделе.
Mkfs.ext4 /dev/sda1
3. Распаковываем архив.
Монтируем отформатированный разделMount /dev/sda1 /mnt
Распаковываем архив прямо с флэшки
Tar --same-owner -xvpf /lib/live/mount/medium/backupYYYYMMDD.tgz -C /mnt/
Параметр --same-owner - сохраняет владельцев у распаковываемых файлов, x - извлекаем из архива, v - выводить информацию о процессе, p - сохраняем права доступа, f - указываем файл, который распаковываем, C - распаковываем в категорию.
4. Создаем MBR на новом диске.
Чтобы корректно создать загрузочную запись, монтируем рабочие каталоги к нашему будущему root-каталогу, у меня это /mnt. Каталоги /dev и /proc сейчас используются live-системой, используем параметр bind, чтобы они были доступны сразу в двух местах:Mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
Переключаемся на новую систему используя chroot:
Chroot /mnt
Делаем swap-раздел для новой системы:
Mkswap /dev/sda2
Подключаем его же:
Swapon /dev/sda2
Чтобы grub работал, нужно указать ему правильные UUID разделов в fstab, сейчас там прописаны разделы предыдущей системы:
Nano /etc/fstab
Открываем второй терминал (Alt+F2) под root:
Sudo su
Вызываем:
Blkid
И видим текущие UUID разделов.
Вручную переписываем их в fstab переключаясь между Alt+F1 и Alt+F2. Да, муторно, но попытки копировать занимали у меня больше времени, чем переписывание. Сохраняем fstab.
Устанавливаем grub2. У меня один физический диск, поэтому ставим его на sda:
Grub-install /dev/sda
На чистый диск должно встать без ошибок. Обновляем информацию из fstab:
Update-grub
Возвращаемся в Live-систему:
Exit
Размонтируем все каталоги:
Umount /mnt/dev
umount /mnt/proc
umount /mnt
Если вылазят процессы, которые используют эти каталоги, убиваем их используя fuser.
Все, поехали. Грузимся с жесткого диска:
Reboot
Здесь статья должна была закончиться, но у меня возникли проблемы с подключением к интернету. Сервер видит сеть, видит компьютеры в ней, но в интернет не ходит… а это как бы важно для телефонии.
5. Тестирование и устранение неполадок.
ifconfig -aПоказывет интерфейсы eth1 и lo, гугление сказало, что gateway можно прописать только подключению eth0, остальные рассчитаны только на работу внутри сети.
Похоже, отсутствие eth0 вызвано способом переноса системы. Находим файл, который отвечает за нумерацию интерфейсов, смотрим туда:
Nano /etc/udev/rules.d/70-persistent-net.rules
Действительно, там два активных интерфейса, определенных MAC’ами. Комментируем первый, второму прописываем eth0.
Перезапуск /etс/init.d/networking не помог, поэтому перезагружаемся:
Reboot
Подключаем донглы, проверяем, все работает.
Спасибо за внимание.
Программы, используемые для выполнения полного резервного копирования путем дублирования исходных данных, называются программами резервного копирования. Очевидно, что главной целью резервного копирования является создание порядка из хаоса с помощью восстановления важных файлов в случае возникновения аварийной ситуации. В некоторых популярных программах резервного копирования используются sql, удаленный доступ к системе и копирование файлов на другую систему.
Если вы пользуетесь Linux, то в нем найдете на выбор много программ резервного копирования. Ниже приведен список их нескольких лучших бесплатных программ резервного копирования с открытым исходным кодом, которые можно опробовать.
Является Linux-эквивалентом Time Machine от Apple, базирующимся на GNOME. Как и многие другие утилиты резервного копирования, этот пакет создает инкрементные резервные копии файлов (сохраняет только изменения относительного некоторого первоначального состояния - прим.пер.), которые позже могут быть использованы для восстановления. Его мгновенные снимки являются копиями директория в определенный момент времени. Снимки, сделанные для файлов, которые не изменились с момента предыдущего снимка, занимают очень мало места. Это связано с тем, что вместо создания резервной копии всего файла без его изменения, в снимках используется жесткая связь с существующей резервной копией файла в ее первоначальном состоянии.
Является клоном Symantec Ghost Corporate Edition с открытым исходным кодом. Пакет базируется на использовании DRBL, образов разделов, ntfsclone, partclone и udpcast, что позволит вам получать слепок данных для резервного копирования и восстановления. В наличии есть два варианта пакета Clonezilla: Clonezilla live и Clonezilla SE (Server Edition - серверная редакция). Clonezilla live подходит для резервной копирования и восстановления одной машины. А Clonezilla SE предназначен для массового развертывания и может одновременно делать клоны многих компьютеров.
Делает копии директориев, создавая зашифрованные тома в формате tar и загружает их на удаленный или локальный файл-сервер. Поскольку Duplicity использует librsync, инкрементные архивы экономно используют место и записывают только те части файлов, которые были изменены с предыдущего резервного копирования. Поскольку Duplicity использует GnuPG для шифрования и / или подписывания этих архивы, они защищены от шпионажа и / или изменения их на сервере.
Является системой резервного копирования уровня предприятия, имеющей открытый код и предназначенной для гетерогенных сетей. Пакет создан для автоматизации задач, выполнение которые часто требует вмешательства системного администратора или оператора. В Bacula есть клиенты резервного копирования Linux, UNIX и Windows, а также можно использовать ряд профессиональных устройств резервного копирования, в том числе библиотеки ленточных накопителей. Администраторы и операторы могут конфигурировать систему при помощи консоли с командной строкой, графического интерфейса GUI и веб-интерфейса; в качестве сохраняемых данных используется информационный каталог, который может храниться в MySQL, PostgreSQL или SQLite.
(Advanced Maryland Automatic Network Disk Archiver - улучшенный автоматический архиватор сетевых дисков из Мэриленд) является системой резервного копирования, которая позволяет администратору настроить один главный сервер резервного копирования большого количества сетевых хостов на ленточные накопители или оптические носители. AMANDA использует дамп данных и / или GNU tar и может выполнять резервное копирование большого числа рабочих станций, работающих под различными версиями Unix.
Обновлено: 4.05.2014 - 06:41
Резервное копирование системы (Backup) является одной из важных профилактических мер по поддержание стабильности работы сервера. Хотя данная инструкция подойдёт и для desktop систем, получится своего рода "точка восстановления". Для резервного копирования нам понадобится всего-лишь утилита по работе с архивами в linux системах – tar
. Делаем резервную копию работающей системы:
1. Для Ubuntu – выполняем sudo su , для Debian – выполняем su -l root 2. Смотрим, сколько у нас системой использовано, сколько места свободно (backup будем сжимать в архив, так-что размер будет меньше, чем текущее использование системой). root@server:~# df -h
Файловая система Размер Использовано Дост Использовано% Cмонтировано в /dev/sda2 73G 2,1G
67G 3% / Tmpfs 5,0M 0 5,0M 0% /lib/init/rw Tmpfs 152M 1,4M 151M 1% /run Udev 753M 0 753M 0% /dev Tmpfs 303M 0 303M 0% /run/shm /dev/sdb1 147G 26G 114G 19% /web В данном примере вся система установлена на раздел /dev/sda2 и занимает 2.1G, в корень этого раздела мы и будем копировать дамп, т.к. доступно ещё 67G. 3. Переходим в корень системы cd /
4. Выполняем копирование работающей системы (Внимание!!! Исключаем из копирования разделы /proc /lost+found /sys и сам архив /backup.tgz, + в данном примере исключаем раздел /web). Для чистоты бэкапа рекомендую вам почистить логи в /var/log , и удалить кеш архивов apt-get clean. tar cvpzf backup.tgz
–exclude=/proc –exclude=/lost+found –exclude=/backup.tgz –exclude=/mnt –exclude=/sys –exclude=/web /
5. Смотрим ls -alh теперь можно спрятать куда-нибудь в надежное место архив backup.tgz на случай сбоев работы сервера, а потом с лёгкостью восстановить систему в короткие сроки. Восстановление системы Debian/Ubuntu (да и любого дистрибутива Linux) из созданного бэкапа: Если вы делаете восстановление системы на то-же оборудование, с теми-же разделами жестких дисков, то процесс займёт буквально несколько минут. 1. Загружаемся с Live CD Linux (например Ubuntu, хотя можно и по легче выбрать образ, без графического интерфейса). Копируем backup системы в корень. 2. Распаковываем архив в корень раздела tar xvpfz backup.tgz /
3. Теперь прописываем загрузочную область (Из личного опыта, если вы делали разметку GParted утилитой, то в начале диска обязательно оставьте несколько не задействованных мегабайт, иначе grub2 не установится). grub-install
–root-directory=/mnt/ /dev/sda2 (–root-directory=/mnt/ в данном случае указывает, что для корня считать точку /mnt , т.к. туда у нас временно смонтирован раздел sda2) 4. Создаем пустые каталоги /proc /sys . Перезагружаемся и внимательно смотрим на логи, которые выводит система при загрузке. Если же вы переносите систему на другое устройство, то здесь будет немного сложнее. Подробно по памяти описать не смогу, но в общих чертах примерно так: 1. Распаковываем архив. 2. Смотрим, как в системе Live CD определилось оборудование, в частности разделы жёстких дисков. 3. При старте компьютера (до загрузки ОС) заходим в редактор grub2 и правим конфиг в соответствии с менами разделов жёстких дисков. 4. Если система не может запуститься из-за "отсутствие файловой системы", значит нужно пересобирать initrd загрузчик (это загрузчик, который определяет всё оборудование, а потом далее передаёт ядру ОС управление и дальнейшую загрузку системы) с необходимыми модулями, выполнять это можно загрузившись с Live CD, примонтировав разделы /proc и /sys к системе, в которую мы будем компилировать /mnt/proc /mnt/sys , а далее авторизоваться, как будто бы работает система chroot /mnt В принципе это самый простой способ для резервного копирования рабочей системы, никакие акронисов, никакик утилит для работы с клонированием разделов не надо, всё достаточно просто и быстро. При желании, можно сделать правило, на запуск скрипта в 01:00 ночи, который бы делал дамп системы к примеру 1 раз в неделю.
Автор статьи - сайт
Итак, мы имеем удаленный хост под управлением ubuntu, с некоторым массивом довольно критичных данных. Довольно логичным было бы настроить бэкап прямо на удаленном хосте, с помощью tar по крону, rsyns и т.д. Но, т.к. место на виртуальном выделенном хостинге довольно дорого и использовать его лучше по делу, идеально было бы, чтобы данные автоматически копировались на какую нибудь локальную машину, место на которой хоть отбавляй. В моем случае это файловый сервис в офисе, под управлением все той же Ubuntu.
Установка
Устанавливаем rsnapshot:$ sudo apt-get install rsnapshot
Если вы используете не debian-подобный дистрибутив, rsnapshot наверняка тоже есть в репозиториях вашего дистрибутива. Для CentOS, при включенных RPMForge это делается, например, так:
# yum install rsnapshot
Теперь нам нужно создать директорию, где мы собираемся хранить наши «снимки»:
$ sudo mkdir /var/snapshots
Настройка
Теперь можно перейти к настройке, собственно, rsnapshot:$ sudo nano /etc/rsnapshot.conf
Вместо nano вы можете использовать любой другой редактор, например vi, или gedit, если работаете в GNOME.
Настроить нужно следующие параметры:
Snapshot_root - директория, в которую вы хотите сохранять "снимки".
Interval xxx yy - ххх - название интервала(например hourly, daily), yy - количество снимков для каждого. Например:
interval hourly 6
interval daily 7
Означает, что мы хотим хранить 6 ежечасных копий и 7 ежемесячных. Если уже доступно указанное количество копий, rsnapshot будет заменить старую более новой.
Расскомментируйте cmd_cp. cmd_ssh расскоментируйте и измените на
Cmd_ssh /usr/bin/ssh
Настройка бэкапа осуществляется командой backup <откуда> <куда>:
#Добавляем папку /etc/ с локальной машины в папку localhost/
backup /etc/ local/
#Добавляем папку /var/svn с удаленной машины в папку remotehost/
backup [email protected]:/var/svn/ remotehost/
Помните, что в конфигурационном файле недопустимы пробелы - используйте только табы.
Пробный запуск
Запустим rsnapshot:$ rsnapshot hourly
Второй параметр означает интервал, который мы задали в конфигурационном файле.
Команда может выполняется продолжительное время. После выполнения, смотрим, что она создала:
$ ls -l /var/snapshots
Пока что в директории должен быть один каталог: hourly.0. При следующем запуске rsnapshot будет создавать каталоги hourly.1, hourly.2 и т.д., пока не упрется в максимум, указанный нами в конфигурационном файле.
Настройка cron
В Ubuntu автоматически создается файл /etc/cron.d/rsnapshot со следующим содержанием:0 */4 * * * root /usr/bin/rsnapshot hourly
30 3 * * * root /usr/bin/rsnapshot daily
0 3 * * 1 root /usr/bin/rsnapshot weekly
30 2 1 * * root /usr/bin/rsnapshot monthly
Вот и все. Теперь у вас 6 раз в сутки должен автоматически создаваться снимок данных с вашего удаленного сервера. Данные в сохранности, да еще и географически распределены.
Кстати, 6 раз в сутки не означает, что размер будет в 6 раз больше, чем если копировать всего 1 раз в сутки. Если в промежутки между копированиями не будет изменений в файлах, то общий размер копий почти не изменится.
Дополнительная информация
С помощью параметра backup_script можно также настроить резервное копирование баз данных MySQL, да и вообще всего, чего угодно. Я не описывал сей процесс, т.к. у меня он не используется и ничего конкретного сказать не могу.Подробнее можно почитать в гугле. По запросу rsnapshot вылезает куча релевантных ссылок, правда на английском языке.
