linux скрипт бэкапа файлов
Cron в Ubuntu. + bash-cкрипт резервного копирования
Для начала создадим какой-нибудь простой 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 /
Этот скрипт копирует конфигурационные файлы и архивирует их в папку, в названии которой присутствует дата и время сохранения. Назовём его ‘ backup-script ‘ а лежать он у нас будет в домашнем каталоге (/home/user/). Теперь нам надо чтобы этот скрипт запускался, ну допустим, каждые 10 минут. Для этого введём команду
Этой командой мы открываем для редактирования файл crontab для данного пользователя, в моём случае это user. Если нашему скрипту нужны права супер пользователя, то нужно редактировать 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
Ну вот и всё, в заключение пару примеров:
0 */ 3 * * 2,5 / home / user / backup-script
#Каждые три часа только по вторникам и пятницам
15 */ 3 * * * / home / user / backup-script
#Каждые три часа в 15 минут
45 15 * * 1 / home / user / backup-script
#По понедельникам в 15:45
13 13 13 * 5 / home / user / backup-script
#в пяnницу 13 числа в 13 часов 13 минут
30 00 * * 0 / home / user / backup-script
#Раз в неделя по воскресеньем в 00:30
Warl0ck’s Blog
Про GNU/Linux и софт вообще
Backup в Linux: Самописные скрипты v2
Как и обещал, переписал с нуля пост о бэкапе. Честно говоря, это первый пост, на написание которого я потратил полтора дня (с перерывами конечно), а не 5 минут. Поэтому хотелось бы прочитать отзывы о стиле изложения и какие-то конкретные замечания.
Разумеется, создавать резервные копии данных и целых разделов в Linux можно разными способами. Можно пользоваться коммерческими или бесплатными системами резервного копирования, можно вручную архивировать корневой раздел, можно пользоваться утилитами вроде dd или rsync. А можно написать либо позаимствовать написанный кем-то раньше скрипт, который будет создавать резервные копии самостоятельно. О последнем способе я и хочу написать в этом посте.
Создание резервных копий.
Для начала создадим каталог, куда будут сохраняться архивы. У меня они сохраняются в домашний каталог. Это удобно потому, что у меня 2 логических диска, / и /home и даже при переустановке системы можно форматировать корневой раздел не форматируя /home. И, конечно же, программы при переустановке системы сохраняют все настройки, так как хранятся настройки в домашнем каталоге.
— тильдой обозначается домашний каталог текущего пользователя, то есть вместо mkdir
/backup я мог бы написать mkdir /home/имя_пользователя/backup (естественно, вместо имя_пользователя подставьте свое имя пользователя)
Можете создать каталог где-нибудь еще, только не забудьте потом в самом скрипте в строке cd /home/имя_пользователя/backup /home/имя_пользователя/backup заменить на ваш путь.
Теперь напишем скрипт, который создавал бы резервные копии указанных каталогов в корневом разделе. Автор скрипта — не я, я его нашел и переписал кое-что в нем под себя.
Запускаем текстовый редактор
имя файла, понятное дело, может быть любым, но не забудьте тогда поменять его на свое и в других местах.
и пишем там такие строки
Делаем этот файл выполняемым
Запускать архивирование можно вручную командой
что в принципе оправдано на домашнем компьютере, где не надо часто делать резервные копии. Неплохо было бы периодически копировать архивные копии на флешку, даже если у вас каталог /home расположен на отдельном логическом разделе.
Автоматизация резервного копирования.
Если же вам необходимо запускать автоматически этот скрипт, либо просто лень, то можно автоматизировать запуск. Запланируем, например, запуск скрипта раз в два дня в 17:30. Для этого нам понадобится отредактировать файл /etc/crontab.
Формат записи в этом файле такой:
Минуты (0-59) часы (0-23) день месяца (1-31) месяц (1-12 либо краткое название, например jan, feb…) день недели (0-7, где 0 и 7 обозначают воскресенье; либо краткое название-mon, sun…) имя пользователя, от которого выполняется команда выполняемая команда.
Звездочка (*) обозначает «любой».
Можно использовать дефис (1-3 будет означать, что будет выполняться каждую 1, 2 и 3ю единицу времени), либо перечисление через запятую (2, 3, 5, 10 — соответствующие единицы времени).
Можно использовать смешанные сочетания из дефисов и запятых (1-3, 5, 10 — каждая 1, 2, 3, 5 и 10я единицы времени)
А, например, вот такая */3 строка будет значить, что задание будет выполняться каждую третью единицу времени.
Подробнее о формате записей можно почитать, например, тут
Итак, нам нужно запускать скрипт раз в два дня в 17:30. Смотрим на формат, и пишем такую строчку:
30 17 */2 * * root mybackup >> /dev/null
Если вы хотите запускать скрипт чаще, чем раз в сутки, то нужно переписать сам скрипт так, чтобы, при создании имени файлов, писалась не только дата, но и время, иначе архивы, сделанные в один день, будут друг друга перезаписывать.
Извлечение из резервной копии.
Извлекать из резервной копии можно, например, загрузившись с Live-CD, или из-под другой ОС Linux. Оба этих вариантов ничем не отличаются, так что рассмотрим только вариант с Live-CD. Кстати, многие Live-CD автоматически ищут и монтируют файловые системы, так что, если у вас такой дистрибутив — можно сразу перейти к извлечению архивной копии, монтировать и размонтировать в этом случае ФС не надо.
Загружаемся с любого Live-CD дистрибутива. Если у вас используется файловая система Ext4, то дистрибутив должен быть с поддержкой этой ФС.
Монтирование файловых систем:
Создадим каталог, в который будет монтироваться корневая файловая система
Название, понятное дело, может быть любым, каталог в принципе тоже, но, по стандартам, /mnt — тот каталог, в который монтируются разные файловые системы.
Примонтируем корневую файловую систему в созданный каталог
ext4 — тип файловой системы. Естественно, у вас она может быть другой. Если это так — замените на свой тип.
/dev/sda9— логический раздел, который соответствует корневой ФС. То есть тот, у которого точка монтирования — /.
Нас интересует строка
и, если домашние каталоги размешены на отдельном разделе, эта:
В случае, если у вас, как у меня, каталог /home находится на отдельном логическом разделе, а архив вы не скопировали предварительно на флешку, то нужно точно так же, как и /, примонтировать /home.
Если же вы скопировали архив на флешку (воткните флешку кстати, если на ней архив;) или /home не на отдельном логическом диске, то это все делать не надо.
Извлечение из архива:
Переходим в каталог, в который примонтировали корневую файловую систему
и разархивируем архивную копию
tar xvpjf /mnt/home/имя_пользователя/backup/имя_файла.tar.bz2
/mnt/dom/имя_пользователя/backup/ — это путь до файла. У меня бэкап хранился в директории /home/имя_пользователя/backup/, а логический диск с /home я примонтировал в каталог /mnt/dom. Естественно, у вас это могут быть другие пути.
Отмонтируем примонтированные файловые системы после окончания извлечения из архива
sudo umount /mnt/koren
sudo umount /mnt/dom
Перезагружаемся и извлекаем диск.
Ссылки: Скрипт, использованный в посте, взят отсюда
Простой способ резервного копирования Linux-сервера с выгрузкой файлов по FTP
Здравствуйте.
О важности регулярного резервного копирования уже сказано очень много слов. В этой статье мы предлагаем вниманию читателей примеры простых скриптов для бэкапа файлов и баз данных MySQL с последующей выгрузкой архивов на удаленный FTP-сервер.
Несмотря на то что мы в NQhost предлагаем решения по сохранению snapshot’ов VPS-контейнеров, процесс бэкапа собственными силами — безусловно важнейшая вещь.
Хозяйство
Виртуальный или физический сервер с установленной Linux-ОС, веб-сервером и базами данных MySQL.
Файлы веб-сервера располагаются в директориях
/home/site1
/home/site2
/home/site3
Задача
Создание скрипта для резервного копирования файлов и баз данных с сохранением на удаленном FTP-сервере и запуск его каждый день.
Решение
Для простоты примера работать мы будем из-под root`а, директория для хранения бэкапов файлов — /root/backup/server, а для дампов MySQL — /root/backup/mysql
Backup файлов
Здесь приводится пример скрипта для бэкапа файлов, для наглядности пояснения даны в квадратных скобках на русском языке.
#!/bin/sh
### System Setup ###
BACKUP=/root/backup/server
### FTP ###
FTPD=»/»
FTPU=»username» [имя пользавателя (логин) удаленного ftp-cервера]
FTPP=»megapassword» [пароль доступа к удаленному ftp-серверу]
FTPS=»my_remote_backup.ru» [собственно, адрес ftp-сервера или его IP]
### Binaries ###
TAR=»$(which tar)»
GZIP=»$(which gzip)»
FTP=»$(which ftp)»
## Today + hour in 24h format ###
NOW=$(date +%Y%m%d) [задаем текущую дату и время, чтобы итоговый файл выглядел в виде server-YYYYMMDD.tar.gz]
Результатом работы данного скрипта будет созданный файл в директории /root/backup/server вида server-ГГГГММДД.tar.gz содержащий в себе tar-архивы директорий /etc, /home/site1, /home/site2 и /home/site3
Этот же файл будет загружен на FTP-сервер, который мы указали в начале скрипта.
Backup баз MySQL
Этим скриптом мы выгружаем базы данных MySQL (делаем т.н. «дампы). Каждая база выгружается в отдельный файл.
#!/bin/sh
# System + MySQL backup script
### System Setup ###
BACKUP=/root/backup/mysql
### Mysql ### [параметры доступа к нашим базам MySQL]
MUSER=»root»
MPASS=»megapassword»
MHOST=»localhost»
### FTP ###
FTPD=»/»
FTPU=»username» [имя пользавателя (логин) удаленного ftp-cервера]
FTPP=»megapassword» [пароль доступа к удаленному ftp-серверу]
FTPS=»my_remote_backup.ru» [собственно, адрес ftp-сервера или его IP]
### Binaries ###
TAR=»$(which tar)»
GZIP=»$(which gzip)»
FTP=»$(which ftp)»
MYSQL=»$(which mysql)»
MYSQLDUMP=»$(which mysqldump)»
## Today + hour in 24h format ###
NOW=$(date +%Y%m%d)
Десятимиллионный скрипт резервного копирования
Это статья-мануал по скрипту резервного копирования, написанному мной. Скрипт написан на python для Linux. Кому интересно прошу под хабракат.
Возможности
Установка
В /etc/apt/source.list добавить:
И выполнить в терминале:
Обновление пакета выполняется командой:
ИЛИ
Вручную скачать пакет командой:
ИЛИ
Для дистрибутивов, отличных от Ubuntu/Debian выполнить:
И скопировать файлы ddd и py4backup в директорию с бинарными файлами (обычно /usr/bin), файл py4backup_lib.py в директорию библиотек python. Также потребуется поставить зависимости вручную. Необходим python 3.x, btrfs-tools (btrfs-progs), lvm2, rsync. В папке examples/ вы найдете примеры конфигурационных файлов. Их необходимо скопировать в /etc/py4backup/
Настройка
После установки необходимо скопировать конфигурационные файлы из примера. Для этого выполните:
И откройте файл py4backup.conf на редактирование текстовым редактором.
Для boolean параметров допустимо использование True/False, yes/no или 1/0.
Отделять параметр от его значения можно символами ‘=’ или ‘:’.
Каждый параметр должен находится в своей секции. Название секции пишется перед набором параметров в квадратных скобках (‘[]’)
Порядок следования параметров в секции и секций не важен. Если параметр не указан в конфигурационном файле, то используется стандартное значение.
Пример конфигурационного файла:
Рассмотрим параметры подробней:
[MAIL]: здесь определяются параметры отправки уведомлений через email.
send_mail_reports: включает/выключает отправку email отчетов после выполнения задания.
login: логин для входа на smtp сервер.
passwd: пароль для входа на smtp сервер.
sendto: получатели уведомления. Можно вписать несколько адресов через пробел.
server: доменное имя или IP адрес smtp сервера.
port: порт smtp сервера.
tls: включает/выключает использование TLS шифрования.
[DD]: здесь указываются параметры создания резервных копий с помощью программ DD и DDD.
bs: размер блока для программы DD (Используется для создания полных копий LVM томов). Можно указывать размер в байтах, килобайтах (k) и мегабайтах (M). Влияет на скорость создания копии. Оптимальное значение- 32M.
ddd_bs: размер блока для программы DDD (Используется для создания дифференциальных копий LVM томов). Можно указывать размер в байтах. Чем больше размер, тем больше места занимает дифференциальная копия, но тем быстрее она создается. Оптимальное значение- 4096.
ddd_hash: алгоритм хеширования блоков. Возможен выбор между md5, crc32 и None. MD5 сильнее нагружает процессор, чем crc32 и занимает больше места, но в случае использования md5 намного меньше шанс коллизий.
None выключает создание чек сумм. Время создания резервной копии, ее размер и нагрузка на процессор минимальны, но в случае повреждения резервной копии вы не будете знать об этом. Не рекомендуется к использованию.
[LOGGING]: настройка ведения журнала заданий.
logpath: путь до журнала. Если вы используете не стандартное размещение журнала не забудьте поменять настройки logrotate.
enable_logging: включает/выключает ведение журнала.
log_with_time: включает/выключает добавление к каждой записи журнала даты и времени.
traceback: включает/выключает добавление traceback’ов в лог при ошибках. Полезно при отладке.
command_output: включает/выключает добавление в лог консольного вывода команд. Полезно при отладке.
Задания
Общие сведения
Список заданий находится в файле /etc/py4backup/jobs.conf
Пример задания:
Типы резервного копирования
Рассмотрим их поближе.
file-full
file-diff
Создает дифференциальную резервную копию от источника (sopath) и последней полной копией, найденной в папке назначения (dpath). Если полная копия не будет найдена выполнение задания завершиться ошибкой.
Список параметров аналогичен типу ‘file-full’.
btrfs-full
Данный тип аналогичен типу ‘file-full’, но перед созданием резервной копии делается снапшот резервируемой директории и копия снимается уже со снапшота.
Для этого типа резервного копирования необходимо указание параметра snpath. В папке, указанной в snpath будет создан временный снапшот исходной папки (sopath). Причем указанный там путь должен находится на одной файловой системе с папкой, указанной в sopath. Обратите внимание, что копируется только содержимое данного subvolume файловой системы. Все примонтированные папки и вложенные subvolume будут проигнорированы. Список остальных параметров аналогичен типу ‘file-full’.
btrfs-diff
При этом типе рез. копирования сначала с исходной папки (sopath) снимается снапшот, а затем создается дифференциальная копия от снапшота и последней полной копией, найденной в папке назначения (dpath). Если полная копия не будет найдена выполнение задания завершиться ошибкой.
Так же, как и для типа ‘btrfs-full’ необходимо, что бы папка для снапшота (snpath) находилась на одной файловой системе с исходной папкой (sopath).
Обратите внимание, что копируется только содержимое данного subvolume файловой системы. Все примонтированные папки и вложенные subvolume будут проигнорированы. Список остальных параметров аналогичен типу ‘file-full’
btrfs-snap
Данный тип создает снапшоты от исходной папки, указанной в sopath в папку снапшотов, указанную в snpath.
Для данного типа не работают параметры exclude, include, dpath. Так же, как и для типа ‘btrfs-full’ необходимо, что бы папка для снапшотов (snpath) находилась на одной файловой системе с исходной папкой (sopath).
Обратите внимание, что копируется только содержимое данного subvolume файловой системы. Все примонтированные папки и вложенные subvolume будут проигнорированы.
lvm-full
Этот тип предназначен для создания полных копий LVM томов. Рассмотрим некоторые особенности данного типа. В параметре sopath указывается путь до Logical Volume Group (VG). Например:
sopath = /dev/main_vg/
По умолчанию скрипт сделает копию всех томов, находящихся в данном VG.
Параметр dpath указывает где сохранять резервную копию. Указывать удаленные хосты в качестве назначения резервной копии нельзя. Для того, что бы сделать копии только нужных томов можно использовать параметры include и exclude.
Параметр exclude указывает какие тома исключить из резервной копии. Кроме того он принимает кодовое слово all, обозначающее, что надо исключить все тома.
Параметр include указывает какие тома нужно включить в резервную копию. Имеет приоритет над exclude. Например:
сделает резервную копию только томов mail и root. А следующий пример сделает копию всех томов, кроме тома mail:
lvm-diff
И последний (для версии 1.5) тип резервного копирования предназначен для создания дифференциальных копий LVM томов.
Скрипт ищет в папке назначения (dpath) последнюю полную резервную копию и если находит, создает дифференциальную копию между ней и снапшотом текущего состояния. В папке назначения при этом появятся 2 файла *-diff.dd и *-diff.ddm Они ОБА необходимы для восстановления.
Все параметры аналогичны типу lvm-full
Запуск
Восстановление
Вот мы и подошли к самому интересному. Резервное копирование само по себе ничего не стоит, без возможности быстро восстановить резервную копию. В данном разделе я опишу типичные кейсы восстановления из резервных копий, созданных скриптом.
Файловые бэкапы
В обоих случаях в папке назначения вы получите полную копию данных, готовую к использованию.
Восстановление снапшотов
Таким образом мы во первых сделали наши данные доступными для записи и обезопасили их. Даже когда скрипт согласно ротации удалит снапшот от 2014-06-19 наш свежесозданный снапшот будет цел.
Восстановление полных бэкапов LVM
Тут все совсем просто.
Необходимо создать новый LVM том, размера равного или больше резервной копии и скопировать на него резервную копию с помощью dd.
Пример:
Восстановление дифференциальных бэкапов LVM
И мы хотим восстановить резервную копию за 2014-06-19 на устройство /dev/main_vg/volume Для этого выполним команду:
Предположим полная копия была перемещена в папку /backup_old/:
После восстановления ddd выведет список поврежденных блоков с указанием файла, где находится поврежденный блок. Запись full23 указывает на повреждение блока номер 23 в файле полной копии, а запись diff24 на повреждение блока 24 в дифференциальной копии.
Tips & Tricks
bash: Бэкап без лишнего ПО
Бэкап важной информации — каждый системный администратор сталкивается с такой задачей. Задача казалось бы тривиальная и у многих читателей интереса не вызовет. Но, например, мне бы такая статья в определенный момент помогла бы весьма сильно, поэтому считаю, что этой статье быть.
Задача: Бэкап данных в локальную директорию и на отдельный сервер, с использованием минимума стороннего ПО, логированием и оповещением администратора в jabber при сбоях. Все основные функции большинства ПО для автоматического бэкапа, но без установки оного, а следовательно без его багов (что, собственно, и привело к подобной идее).
А теперь к делу.
Для начала создадим и откроем скрипт
Теперь в скрипте добавим строку
Объявим некоторые переменные.
TN — TASKNAME — имя задания.Используется для вывода в лог и определения названия файла.
Так как заданий несколько (ежемесячное, еженедельное, ежедневное) и писать на каждый случай скрипт было лень, я создал универсальный, в котором надо просто раскомментить нужные строки. Наименование заданий писать надо без пробелов, желательно в латинице, если не хотите проблем с кодировкой и неправильными параметрами команд.
OF — Output File — имя выходного файла. Получается из переменной TN, то есть имени задания.
Объявляем переменную с путем к файлу лога, и далее все сообщения об ошибках и остальном будем выводить в лог.
Сделаем запись в лог о начале бэкапа (дата, время, имя задания)
Заменяем стандартный разделитель своим
SRCD — SouRCe Directory — каталог с данными для бэкапа
Теперь можно перечислять несколько каталогов, разделителем будет перенос строк как мы сами указали строкой выше
TGTD — TarGeT Directory — каталог в который будут складываться бэкапы
Естественно мы понимаем что хранить важные бэкапы только на источнике как минимум легкомысленно. Поэтому оставим копию и на удаленном ресурсе, который будем отдельно монтировать с помощью mount и fstab. Сразу поясню почему я использовал mount и fstab, а не один mount — я монтирую этот каталог и в других своих скриптах, а как сказал один из знакомых программистов — хороший программист не будет писать один и тот же код дважды (как-то так, дословно не помню, но надеюсь смысл донес).
Сам процесс архивирования в варианте «Создать новый архив»
и в варианте «Обновить файлы в старом архиве»
В переменной «?» ханится статус выполнения последней команды. Сохраним его, чтобы воспользоваться позже.
Возвращаем стандартный разделитель к исходному значению
Теперь добавим условие — если процесс упаковки в архив tar закончился с ошибкой, отправляем сообщение админу, удаляем неудачный файл бекапа. Иначе продолжаем дальше — монтируем сетевую шару и кидаем в нее копию архива. После каждой операции проверяем результат выполнения, пишем логи, и либо продолжаем, либо извещаем админа и прерываем процедуру.
В процессе мы копируем архив из локального хванилища в удаленное. Естественно, проверяем, что каждая операция успешно завершена, и пишем все в логи.
Для отсылки сообщения администратору я использую XMPP сообщение, так как в организации поднят Jabber-сервер, и я больше люблю получить быстрое сообщение о сбое, чем лезть в почту, вбивая пароли, тыкая на ссылки, и ожидая пока браузер мне все отобразит. В любом случае никто не мешает вам использовать sendmail вместо sendxmpp.
Файл /usr/local/etc/XMPP_settings следующего содержания:
В файле fstab строка описывающая подключение шары Windows
Теперь осталось только добавить задание в cron. Это можно сделать с помощью файла /etc/crontab, но я, в силу привычки к GUI, оставшейся в наследство от виндовс, пользую вэб-интерфейсы для таких случаев. Команда должна выполняться с правами рута, то бишь, к примеру, sudo bash backup_script. Добавляя команду в cron можно определить что она будет сразу выполняться от имени root`а
В ходе обсуждений затронули проблему разрастания логов. Пошел по простейшему (на мой взгляд) пути: будем хранить только последние N строк лога, например 300. В скрипт добавятся две строки, в которых мы сохраним последние 300 строк лога во временный файл, потом затрем им лог