Скрипт резервного копирования файлов ubuntu
Как и обещал, переписал с нуля пост о бэкапе. Честно говоря, это первый пост, на написание которого я потратил полтора дня (с перерывами конечно), а не 5 минут. Поэтому хотелось бы прочитать отзывы о стиле изложения и какие-то конкретные замечания.
Разумеется, создавать резервные копии данных и целых разделов в Linux можно разными способами. Можно пользоваться коммерческими или бесплатными системами резервного копирования, можно вручную архивировать корневой раздел, можно пользоваться утилитами вроде dd или rsync. А можно написать либо позаимствовать написанный кем-то раньше скрипт, который будет создавать резервные копии самостоятельно. О последнем способе я и хочу написать в этом посте.
Создание резервных копий.
Для начала создадим каталог, куда будут сохраняться архивы. У меня они сохраняются в домашний каталог. Это удобно потому, что у меня 2 логических диска, / и /home и даже при переустановке системы можно форматировать корневой раздел не форматируя /home. И, конечно же, программы при переустановке системы сохраняют все настройки, так как хранятся настройки в домашнем каталоге.
/backup я мог бы написать mkdir /home/имя_пользователя/backup (естественно, вместо имя_пользователя подставьте свое имя пользователя)
Можете создать каталог где-нибудь еще, только не забудьте потом в самом скрипте в строке cd /home/имя_пользователя/backup /home/имя_пользователя/backup заменить на ваш путь.
Теперь напишем скрипт, который создавал бы резервные копии указанных каталогов в корневом разделе. Автор скрипта — не я, я его нашел и переписал кое-что в нем под себя.
Запускаем текстовый редактор
имя файла, понятное дело, может быть любым, но не забудьте тогда поменять его на свое и в других местах.
и пишем там такие строки
Делаем этот файл выполняемым
Запускать архивирование можно вручную командой
что в принципе оправдано на домашнем компьютере, где не надо часто делать резервные копии. Неплохо было бы периодически копировать архивные копии на флешку, даже если у вас каталог /home расположен на отдельном логическом разделе.
Автоматизация резервного копирования.
Если же вам необходимо запускать автоматически этот скрипт, либо просто лень, то можно автоматизировать запуск. Запланируем, например, запуск скрипта раз в два дня в 17:30. Для этого нам понадобится отредактировать файл /etc/crontab.
Формат записи в этом файле такой:
Итак, нам нужно запускать скрипт раз в два дня в 17:30. Смотрим на формат, и пишем такую строчку:
Если вы хотите запускать скрипт чаще, чем раз в сутки, то нужно переписать сам скрипт так, чтобы, при создании имени файлов, писалась не только дата, но и время, иначе архивы, сделанные в один день, будут друг друга перезаписывать.
Извлечение из резервной копии.
Загружаемся с любого Live-CD дистрибутива. Если у вас используется файловая система Ext4, то дистрибутив должен быть с поддержкой этой ФС.
Монтирование файловых систем:
Создадим каталог, в который будет монтироваться корневая файловая система
Название, понятное дело, может быть любым, каталог в принципе тоже, но, по стандартам, /mnt — тот каталог, в который монтируются разные файловые системы.
Примонтируем корневую файловую систему в созданный каталог
sudo mount -t ext4 /dev/sda9 /mnt/koren
Если не знаете, как размечен ваш диск, наберите в консоли df -h. Получите примерно такой результат:
Нас интересует строка
и, если домашние каталоги размешены на отдельном разделе, эта:
В случае, если у вас, как у меня, каталог /home находится на отдельном логическом разделе, а архив вы не скопировали предварительно на флешку, то нужно точно так же, как и /, примонтировать /home.
sudo mkdir /mnt/dom
sudo mount -t ext4 /dev/sda10 /mnt/dom
Если же вы скопировали архив на флешку (воткните флешку кстати, если на ней архив;) или /home не на отдельном логическом диске, то это все делать не надо.
Извлечение из архива:
Переходим в каталог, в который примонтировали корневую файловую систему
и разархивируем архивную копию
tar xvpjf /mnt/home/имя_пользователя/backup/имя_файла.tar.bz2
Отмонтируем примонтированные файловые системы после окончания извлечения из архива
sudo umount /mnt/koren
sudo umount /mnt/dom
Иногда системным администраторам, программистам, web-дизайнерам и много кому ещё нужно запускать одни и те же команды или скрипт с некоторой периодичностью. Для таких целей используется специальная утилита Cron , встроенная во все дистрибутивы Unix. Пользоваться Cron’ом необычайно легко. Сейчас расскажу как.
Для начала создадим какой-нибудь простой bash-скрипт, например скрип резервного копирования и архивирования конфигурационных файлов, в моём случае конфигурационных файлов Apache2 и ftp-сервера.
mkdir / home / user / bash-scripts / backup
cp / etc / apache2 / apache2.conf / home / user / bash-scripts / backup / apache2.conf-backup
cp / etc / apache2 / sites-available / site / home / user / bash-scripts / backup / site-backup
cp / etc / proftpd / proftpd.conf / home / user / bash-scripts / backup / proftpd.conf-backup
tar cvvzf "/home/user/bash-scripts/backup-`date +%F-%X`.tar.gz" / home / user / bash-scripts / backup /
rm -r / home / user / bash-scripts / backup
Этот скрипт копирует конфигурационные файлы и архивирует их в папку, в названии которой присутствует дата и время сохранения. Назовём его ‘ backup-script ‘ а лежать он у нас будет в домашнем каталоге (/home/user/). Теперь нам надо чтобы этот скрипт запускался, ну допустим, каждые 10 минут. Для этого введём команду
Этой командой мы открываем для редактирования файл crontab для данного пользователя, в моём случае это user. Если нашему скрипту нужны права супер пользователя, то нужно редактировать crontab суперпользователя. Делается это командой
sudo crontab -u root -e
Ну и если заменить root а логин другого пользователя, мы будем редактировать его crontab .
Сразу напишу, чтобы посмотреть файл crontab введите команду.
Файл crontab имеет следующую структуру:
поле1 поле2 поле3 поле4 поле5 команда
Значения первых пяти полей:
1.минуты— число от 0 до 59
2.часы — число от 0 до 23
3.день месяца — число от 1 до 31
4.номер месяца в году — число от 1 до 12
5.день недели — число от 0 до 7 (0-Вс,1-Пн,2-Вт,3-Ср,4-Чт,5-Пт,6-Сб,7-Вс)
Все поля обязательны для заполнения. Не сложно догадаться что первые 5 отвечают за определения периодичности запуска команды, а последняя собственно команда или полный путь к скрипту. Таким образом, чтобы запустить наш скрипт резервного копирования раз в 10 минут надо вписать следующую строчку.
*/ 10 * * * * / home / user / backup-script
* - значит все возможные варианты, / служит для определения периодичности выполнения задания. Если нужно будет выполнять скрипт раз в 3 часа впишите в значения часы */3 а в минуты просто *, если раз в сутки — впишите */23 , ну почти сутки. Так же в одно поле можно вводить несколько значений через запятую, например если хотите выполнять скрипт 1ого, 5ого, и 25ог числа каждого месяца введите 1,5,25 вместо третей звёздочки. Ещё можно вводить промежуток времени, если ,допустим, в часы ввести 12-17 то скрипт будет выполняться с 12 до 17 включительно раз в час.
Ну вот и всё, в заключение пару примеров:
0 */ 3 * * 2,5 / home / user / backup-script
15 */ 3 * * * / home / user / backup-script
45 15 * * 1 / home / user / backup-script
13 13 13 * 5 / home / user / backup-script
30 00 * * 0 / home / user / backup-script
Резервное копирование системы очень важно, поскольку если у вас есть резервная копия всех файлов, настроек или даже системы полностью, то вы можете ее восстановить в случае возникновения проблем. Несмотря на стабильность Linux, эта система может ломаться, например, после обновления или когда вы экспериментировали и сделали что-то не так.
Если вы делаете резервное копирование Ubuntu, то потом сможете все очень просто восстановить, даже если система была почти убита. Уже существует множество программ для создания резервных копий как файлов, так и всего диска, одна из самых популярных из них - это CloneZilla. Но мы не будем их сегодня рассматривать. В этой статье мы поговорим о том, как выполнить резервное копирование системы без сторонних программ, с помощью системных команд. Это может быть полезнее в некоторых случаях.
Резервное копирование Ununtu
Рассмотрим самые распространенные способы копирования среди администраторов и обычных пользователей.
Способ 1. Список пакетов
Самый простой способ резервного копирования Ubuntu, кстати, именно эту возможность использует MintBackup в LinuxMint, это получение списка всех установленных пакетов. Да, тут вы не сохраните всю конфигурацию, зато сможете очень быстро восстановить все установленные программы.
Если учесть, что большинство конфигурационных файлов находятся в домашней папке пользователя, а она не стирается при переустановке, то остальные файлы не такая уже большая проблема. А такая резервная копия будет занимать всего несколько килобайт. Для выполнения резервной копии наберите такую команду:
dpkg --get-selections | grep -v deinstall > backup.txt
Далее, скопируйте полученный файл в надежное место. Когда система сломается, переустановите ее с установочного носителя, а затем просто выполните команды:
sudo dpkg --set-selections < backup.txt
sudo apt -y update
sudo apt-get dselect-upgrade
Файл со списком пакетов нужно поместить в текущую папку. Таким образом, вы очень быстро вернете все ранее установленные программы с минимальными затратами времени и в то же время получите чистую систему.
Способ 2. Создание архива
Резервное копирование таким способом более надежно, поскольку вы не просто создаете список установленных программ, а делаете архив из всей файловой системе. Фактически, вы можете потом развернуть этот архив на любой машине и получить полноценную операционную систему после настройки драйверов.
Таким способом часто создаются резервные копии систем на серверах и для него достаточно просто использовать утилиту 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
Команда быстро распакует все, что было сохранено и вам останется только перезагрузить компьютер, чтобы вернуться к своей основной системе. Здесь не восстанавливается только загрузчик, восстановить Grub нужно отдельно если он был поврежден.
Способ 3. Резервное копирование в rsync
Этот способ очень похож на второй, но здесь архив не создается, а данные просто переносятся в другую папку. Это может более полезно при простом копировании операционной системы в другое место. Команда выглядит вот так:
Набор опций -aAX включают передачу в режиме архива, что гарантирует полное копирование символических ссылок, устройств, разрешений и расширенных атрибутов, при условии, что их поддерживает целевая файловая система. Опция --exclude, как и раньше, исключает из копии виртуальные файловые системы.
После завершения копирования вам останется отредактировать /etc/fstab и заменить в нем адрес корневого раздела на новый. А также создать новый конфигурационный файл для загрузчика, автоматически или вручную.
Способ 4. Создание образа раздела
Команда dd linux позволяет создать полную копию раздела или даже всего диска. Это самый надежный, но в то же время потребляющий большое количество памяти способ выполнить резервное копирование системы Ubuntu. Утилита просто переносит весь диск по одному байту в образ. Команда выглядит вот так:
sudo dd if=/dev/sda4 of=
Здесь /dev/sda4 - это ваш корневой раздел. После завершения выполнения команды вы получите готовый образ, затем, чтобы восстановить систему из этой копии достаточно поменять опции местами и указать путь к файлу копии:
Правда, процесс может занять достаточно много времени, в зависимости от скорости работы вашего диска.
Способ 5. Создание Squashfs образа
Преимущество 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 или timeshift. Надеюсь, эта информация была полезной для вас.
Оцените статью:
(15 оценок, среднее: 4,73 из 5)Об авторе
28 комментариев
теперь ждёмс статью со способами автоматического бэкапа без скриптописания и статью о том как работать со снапшотами btrfs
Спасибо, за статью.
Как раз исследовал этот вопрос и тут как раз Вы.
Команда "$ dpkg --get-selections | grep -v deinstall > backup.txt" не найдена. (Zorin на остнове Ubuntu 14.04) Есть ли другое решение?
спасибо. Получился в дом. папке "backup.txt", который пуст. Что-то не так с моей системой, ничего проинсталлировать не могу, apt-get update тоже не работает. Если не найду причину, придеться переустанавливать систему. Эх..
Похоже, xneur првратил два минуса подряд в тире. Минус-пробел-минус, пробел стереть. Или xneur отключить/настроить.
Спасибо, точно так оно и было (с "Минус-пробел-минус"). Backup был установлен. Как, имея его теперь, лучше переинсталлировать глючную систему?
>(Zorin на остнове Ubuntu 14.04) Есть ли другое решение?
Понаставляют всяких болгеносов, а потом мучаются..
А есть ли утилиты, которые позволяют делать backup системы, но с расчетом, чтобы каждый раз не был Full, а также поддерживал бы дифференциальный?Понятно, что всякие дополнительные мощные средства как Symantec, Acronis, Veeam и др. умеют это делать, но именно чтобы были утилиты небольшие по размеру и желательно из репов и бесплатные?
можно попробовать Aptik
Возможности
Поддержание/восстановление пакетов приложений и PPA
Поддержание/восстановление установленных пакетов
Поддержание/восстановление иконок из директории /usr/share/icons и тем из директории /usr/share/themes
Поддержание/восстановление настроек приложений. Оно сохраняет zip-архивы разделов конфигураций приложений из домашней директории в местоположение резервных копий.
Поддержание/восстановление пользователей и групп. Создает резервные копии пользователей и групп и восстанавливает их на новой системе
Поддержание/восстановление записей. Создает резервные копии записей в директориях /etc/fstab и /etc/crypttab и восстанавливает их на новой системе
Поддержание/восстановление данных в директории Home. Создает резервные копию данных пользовательской директории Home и восстанавливает ее на новой системе
Запланированные задачи. Создает резервные копии записей файлов заданий crontab для всех пользователей и восстанавливает их на новой системе
Зашифрованные резервные копии. Резервные копии, содержащие личную информацию, шифруются с использованием AES-128.
Отдельные или периодические операции. Можно создавать копии как одного, так и нескольких объектов
Поддержка всех видов Ubuntu и производных (Linux Mint, Elementary OS и т.д.).
Доступна для Ubuntu 17.04 Zesty/16.10 Yakkety/16.04 Xenial/14.04 Trusty/12.04 Precise/Linux Mint 18/17/13/и других производных Ubuntu.
Для установки следующие команды:
sudo add-apt-repository ppa:teejee2008/ppa
sudo apt-get update
sudo apt-get install aptik
Я использую "Luckybackup", графическая среда для rsync!
установка: sudo add-apt-repository ppa:luckybackup-maintainers/ppa
sudo apt-get update
sudo apt-get install luckybackup
НУ что сказать, работает! Правда были проблемы с cron, в приложении есть возможность создания но не запуска)
Решил установкой "Gnome Shedule"
sudo apt-get install gnome-schedule
Sheduler подтянул задания на выполнение и всё!
А есть вариант этой проги, но не GUI? У нас X-сервер нигде не установлен.
Как же могли забыть такую простую и, в то же время, незаменимую Redo Backup ?? о_0
А почему ни слова не сказано про fsarchiver? Утилита намного лучше, удобней и понятней в эксплуатации, чем клонезилла, я только fsarchiver-ом и пользуюсь, нареканий лет за 6 работы на моей машине никаких!
Имеет ли смысл делать резервную копию в Bacula Backup System в Webmin? Если да, то как? Нигде не нашел внятную инструкцию.
У Bacula есть свой же Web- интерфейс, через него обычно все и работает.
Есть же штатная Backups еще.
И Systemback. правда восстанавливать систему пока еще ни разу не пришлось, в отличие от Windows)
Здравствуйте! Спасибо за статью, для чайника познавательно! Скажите, а есть программы для создания бекапа по расписанию? Типа acronis
"РЕЗЕРВНОЕ КОПИРОВАНИЕ UNUNTU"
Мелочь, но исправьте.
автор, а можно поподробнее про СОЗДАНИЕ SQUASHFS ОБРАЗА пожалуйста, что бы восстановить какая полная команда будет? и откуда, не понятно ничего. опиши, если не трудно
Зачем для 1 способа используются "$ sudo apt-get -y update $ sudo apt-get dselect-upgrade" ведь тут нет обращения к репозиториям?
Способ 2. Создание архива. Корневая папка будет LiveCD, а не нашей системы, которой надо копию сделать. Надо сначала смонтировать корневой раздел нашей системы в какую либо папку внутри mnt (например, mount/root), а уже потом этот раздел копировать в файл на флешке или внешнем жестком диске. Но тогда встает другая проблема. В архивный файл попадет структура mnt/root и при разархивировании будет не корневой раздел а mount/root/корневой_раздел
В начале статьи добавьте, перед:
sudo dpkg --set-selections < backup.txt
выполнить:
sudo apt-get install dselect && sudo dselect update
Добрый день! Данный способ не сработал.
sudo tar czf /backup.tar.gz --exclude=/backup.tar.gz --exclude=/home --exclude=/media --exclude=/dev --exclude=/mnt --exclude=/proc --exclude=/sys --exclude=/tmp /
Результат:
tar: Удаляется начальный `/' из имен объектов
tar: Удаляются начальные `/' из целей жестких ссылок
tar: /var/snap/canonical-livepatch/98/livepatchd.sock: сокет проигнорирован
tar: /var/snap/canonical-livepatch/98/livepatchd-priv.sock: сокет проигнорирован
tar: /run/wpa_supplicant/wlo1: сокет проигнорирован
tar: /run/irqbalance/irqbalance484.sock: сокет проигнорирован
tar: /run/uuidd/request: сокет проигнорирован
tar: /run/snapd-snap.socket: сокет проигнорирован
tar: /run/snapd.socket: сокет проигнорирован
tar: /run/dbus/system_bus_socket: сокет проигнорирован
tar: /run/cups/cups.sock: сокет проигнорирован
tar: /run/avahi-daemon/socket: сокет проигнорирован
tar: /run/acpid.socket: сокет проигнорирован
tar: /run/user/1000/doc: Функция stat завершилась с ошибкой: Отказано в доступе
tar: /run/user/1000/gvfs: Функция stat завершилась с ошибкой: Отказано в доступе
tar: /run/user/1000/keyring/ssh: сокет проигнорирован
tar: /run/user/1000/keyring/pkcs11: сокет проигнорирован
tar: /run/user/1000/keyring/control: сокет проигнорирован
tar: /run/user/1000/snapd-session-agent.socket: сокет проигнорирован
tar: /run/user/1000/pulse/native: сокет проигнорирован
tar: /run/user/1000/pk-debconf-socket: сокет проигнорирован
tar: /run/user/1000/gnupg/S.gpg-agent: сокет проигнорирован
tar: /run/user/1000/gnupg/S.gpg-agent.ssh: сокет проигнорирован
tar: /run/user/1000/gnupg/S.gpg-agent.extra: сокет проигнорирован
tar: /run/user/1000/gnupg/S.gpg-agent.browser: сокет проигнорирован
tar: /run/user/1000/gnupg/S.dirmngr: сокет проигнорирован
tar: /run/user/1000/bus: сокет проигнорирован
tar: /run/user/1000/systemd/private: сокет проигнорирован
tar: /run/user/1000/systemd/notify: сокет проигнорирован
tar: /run/user/1000/inaccessible/sock: сокет проигнорирован
tar: /run/systemd/fsck.progress: сокет проигнорирован
tar: /run/systemd/journal/io.systemd.journal: сокет проигнорирован
tar: /run/systemd/journal/socket: сокет проигнорирован
tar: /run/systemd/journal/stdout: сокет проигнорирован
tar: /run/systemd/journal/dev-log: сокет проигнорирован
tar: /run/systemd/journal/syslog: сокет проигнорирован
tar: /run/systemd/userdb/io.systemd.DynamicUser: сокет проигнорирован
tar: /run/systemd/private: сокет проигнорирован
tar: /run/systemd/notify: сокет проигнорирован
tar: /run/systemd/inaccessible/sock: сокет проигнорирован
tar: /run/udev/control: сокет проигнорирован
tar: /: файл изменился во время чтения
tar: Завершение работы с состоянием неисправности из-за возникших ошибок
Могли бы вы сказать причины почему могло такое произойти и как можно это решить ?
За ранее спасибо!
Друзья, проблема. Автоматическое сохранение (бэкап) сохранил базы данных в формате .ZST
Phpmyadmin у меня их восстанавливать отказывается. Других сохранений из DB нет. Что делать? Как правильно впихнуть в базу данных информацию из них? Действую с Ubuntu Server
Не так давно, мы размещали статью о подключении популярных бесплатных облачных хранилищ на сервере с CentOS 7. В этой статье мы покажем, как можно использовать данные хранилища для резервного копирования данных с вашего сервера. Я использую эти скрипты для дополнительного резервного копирования файлов сайта и базы данных со своего Linux VPS сервера.
Backup данных на OneDrive изLinux CentOS
Мы будем выполнять резервное копирование сайта и базы данных, а также выполнять проверку на «возраст» бэкапа (удалять бэкапы недельной давности) и отправлять на почту отчет с полной информацией выполнения скрипта. Собственно, сам bash скрипт:
Предварительно перед написанием статьи, я создал уже несколько бэкапов, чтобы можно было продемонстрировать, что скрипт работает корректно (удаляет старые бэкапы и закачивает новые).
Я запустил 3 раза вручную. Были созданы несколько резервных копий, после чего они все успешно были отправлены в облако:
ls -la /root/OneDrive/backup/
Проверяем облако, все три архива с резервными копиями здесь:
Следующим шагом, я удалил созданные резервные копии с директории на сервере и снова запустил скрипт. Вывод содержимого директории на сервере:
ls -la /root/OneDrive/backup/
Пройдя в веб-интерфейс OneDrive я увидел, что резервные копии удалили и оттуда, автоматически.
Так же после выполнения скрипта, мне пришло письмо на почту:
Вот и все, на этом резервное копирование на OneDrive окончено.
Резервное копирования на Google Диск.
С резервным копированием в Google Диск в се вышло не так просто как с OneDrive, хотя сама настройка довольно простая. Основная проблема возникла с удалением старых бэкапов с Google Drive, так как на сервер не монтируется директория хранилища. Но после долгого изучения справки drive help, удалось модернизировать наш уже ранее используемый скрипт.
Остальные шаги в скрипте я не расписывал, так как они повторяются с предыдущими.
Запустив скрипт, он выполнился:
С веб-интерфейса его так же видно, как и с консоли:
Таким образом мы получаем скрипт, который выполняет проверку на наличие старых бэкапов в облаке Google Диск, удаляет их если они попадают под требования, после чего создает резервную копию сайта и отправляет ее в это же облако.
Скрипт бекапа на Яндекс.Диск из Linux
Данное облачное хранилище я оставил на закуску, так как резервное копирование в Яндекс.Диск является самым простым, т.к. мы смонтировали облачное хранилище Яндекс через WebDav как отдельное дисковое утсройство . Способ все тот же, мы запускаем скрипт, только лишь с небольшой разницей, не нужно делать синхронизацию или заливку файлов специальными командами, работаем как с обычным серверным каталогом. Синхронизация каталога выполняется с помощью rsync. Скрипт будет иметь вид:
Все тоже самое, только без лишних команд. Если у вас другие пути до облачных хранилищ, меняйте в скрипте на свои.
В конце статьи хотелось бы добавить. Я разместил указанные скрипты в отдельную директорию и запускают их по крону. Если дисковое пространство на ваших облачных дисках позволяет часто создавать бэкапы, создавайте их как можно чаще, я рекомендую не реже одного раза в 3 дня. Используйте ресурсы облачных хранилищ на все 100%.
Примеры заданий в кроне:
0 0 * * 6 /root/bin/backup.sh — запускаем скрипт бэкапа каждую субботу в 00-00
0 0 */3 * * /root/bin/backup.sh — запускаем скрипт бэкапа каждые 3 дня в 00-00
И так далее, настройте бэкапы как вам удобно, когда нагрузка на сервере минимальна.
Когда всё готово для организации резервного копирования (продумана схема, настроен rsync-клиент и сервер, составлен перечень требующих архивации файлов и каталогов на каждой рабочей станции), неплохо бы всё это дело автоматизировать. Действительно, не заводить же себе будильник и запускать на каждой станции команду? :-) В этой статье я расскажу о том, как приготовить простой bash-скрипт определённой универсальности, который можно будет разместить на всех рабочих станциях и серверах данные с которых подлежат резервному копированию. После размещения файла скрипта вам останется лишь сообщить планировщику (я использую cron для решения подобных задач) расписание запуска и спокойно курить в сторонке, пока все участники вашей сети будут заботиться сами о себе. То есть, о ваших данных, конечно же!
Схема сети
Немного вернёмся в прошлое и рассмотрим схему моей сети, в которой работает описываемый в этой статье скрипт. В приводимом примере есть два Ethernet-сегмента, связанные между собой более медленным каналом связи через OpenVPN. Сетевой доступ извне полностью ограничен, поэтому возможность использовать в rsync ssh-туннель не используется. Между Ethernet-сегментами всю работу по шифрованию трафика берёт на себя VPN-туннель.
Итак, в каждом сегменте есть сервер и несколько рабочих станций. Количество рабочих станций в принципе значения не имеет, хотя и изображено у меня только две. Схема резервного копирования достаточно проста: все рабочие станции каждого сегмента сети выполняют backup на «свои» сервера, который в свою очередь обмениваются копиями данных между собой.
Разделяй и властвуй
Жизнь давно научила меня при реализации подобных решений на bash (да и не только), не засовывать всё в один файл. Очень важно на этапе реализации чётко разделить программную часть скрипта и его изменяющуюся от системы к системе часть. Очевидно, что перечень архивируемых каталогов и файлов, а также адрес назначения копирования и будут той самой изменяющейся частью. А вот сам «движок» будет везде одинаков, что позволит в будущем, дополнив ваш скрипт новыми возможностями, бездумно скопировать его на все рабочие станции и сервера, не затронув при этом списка копируемых файлов и каталогов и целевого сервера.
Файл конфигурации
Громковато сказано, но по-другому назвать это никак не могу. Итак, выше мы определились, что перечень копируемых файлов и каталогов, а также путь к серверу мы будем хранить в отдельном файле. Этот файл представляет собой обычный bash-скрипт, который будет выполняться из «основного» как только это понадобится. В нём определён адрес сервера и перечень подлежащих копированию файлов в виде массива. Выглядеть это может примерно так:
В переменной DSTURL хранится путь к rsync-серверу и модулю, в который будет производиться архивация данных. Переменная SRCDIRS представляет собой массив со списком каталогов и, возможно, файлов подлежащих копированию. Обратите внимание, что пути к каталогам не заканчиваются слешами!. В массиве EXCLUDEPATTERNS перечислены шаблоны имён файлов, которые rsync будет пропускать при выполнении синхронизации. Сам файл я разместил в /usr/local/etc/rsyncb.conf.
Скрипт
А вот и сам скрипт, выполняющий всю работу.
Скрипт предельно прост. Логику работы я попытался описать в комментариях. Обратите внимание на то, что для синхронизации серверов между собой, во-первых, не создаются дополнительные каталоги в целевом rsync-модуле, а во-вторых, используется дополнительный параметр -R, указывающий rsync использовать относительные имена файлов при копировании.
Установка скрипта
Всё, что осталось сделать — это разместить файлы скрипта на рабочих станциях и серверах и создать задание для cron. Файл конфигурации, как было сказано выше, я рекомендую разместить в /usr/local/etc/rscynb.conf, а файл скрипта — в /usr/local/bin/rsyncb.sh. Не забудьте установить бит, разрешающий запуск скрипта:
После того, как всё установлено и настроено обязательно произведите пробный запуск. Если всё пройдёт успешно, то можно добавить задание в cron:
В приведённом примере запуск скрипта будет выполняться раз в сутки, в два часа ночи. Как уже говорилось выше, не делайте одинаковым время запуска скрипта на всех системах! Особенно это касается синхронизации между собой серверов.
Замечания
- если в вашей сети несколько или более чем несколько участвующих в процессе резервного копирования рабочих станций, то неплохо бы задуматься о том, чтобы не запускать копирование одновременно со всех них. Не забывайте, что ресурсы серверов не резиновые и на них могут рассчитывать другие процессы и пользователи. Таким образом, постарайтесь равномерно распределить время запуска backup-скриптов на ваших рабочих станциях.
To do
- в предлагаемой реализации резервного копирования нет «обратной связи». То есть, если на какой-то рабочей станции удаляется файл, то на сервере он продолжает храниться. Это одновременно хорошо и плохо. Хорошо потому, что вспомнив через год о каком-то нужном вам файле, который вы в порыве или нечаянно удалили, вы всегда сможете вернуть его обратно. Не совсем приятная сторона такого подхода заключается в том, что свободное дисковое пространство отнюдь не резиновое и настанет тот день или ночь, когда копировать новый данные будет уже некуда. Поэтому неплохо бы продумать и реализовать механизм удаления устаревших резервных копий. Как самый простой вариант: например, раз в месяц запускать отдельный скрипт-"чистильщик", который и будет удалять все несуществующие на рабочей станции копии данных. Ну а в идеале, конечно, нужно чтобы перед удалением неактуальных копий сперва выполнялась проверка на предмет времени последнего изменения копии. Это нужно для того, чтобы не получилось следующее. Запуск процесса «чистки» у вас запланирован на 1 число каждого месяца, а 31-го декабря с бокалом водки в руке вы на рабочей станции удаляете /etc или что-нибудь в этом духе. А второго января будет уже поздно пить «Боржоми». Но если скрипт будет не тупо удалять все неактуальные копи, а сперва просматривать время последнего доступа к файлу, отсчитывать, скажем, месяц, и лишь тогда удалять — вот это будет самое оно.
Backup в Linux: пишем скрипт : 5 комментариев
Крайне доходчивая статья. Спасибо.
Я заметил странное поведение rsync. Возможно, конечно, что это я не прав и пытаюсь получить крайне экзотический результат, но:
В вашем примере в модуле с помощью скрипта в команду rsync подставляется имя хоста
т.е. на сервере создается папка с именем компьютера. Это работает и у меня.
rsync: mkdir «/d/test» (in redactor-1) failed: No such file or directory (2)
Да, клиент запускается на Windows. В качестве сервера выступает FreeNAS.
EliGh, а $/$/$ существует до того, как начинается процесс синхронизации?
Если $/$ существует, то $ создается и все проходит штатно. По ссылке выше есть логи в разных режимах. Поэтому, пока приходится заранее создавать нужную структуру папок. Но это как-то не правильно, я считаю.
Такое впечатление, что rsync не может создать более одного уровня вложения папок именно при старте, ведь затем он же копирует вложенные папки.
Отличный манул! Честно. Под Lenny всё забегало в 20 минут. Для freeBSD пришлось убить дополнительно 3 часа). Начав хотя бы с того, что bash пришлось ставить руками.
Читайте также: