Linux резервное копирование скрипт

Как делать автоматические бэкапы сервера в Облачном хранилище

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

Есть много различных инструментов для работы с объектными хранилищами, например:

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

Требования для выполнения примера

В качестве консольного клиента используем S3cmd с инструментом для автоматизации crontab.

Для начала работы потребуется:

1. Облачный или выделенный сервер с установленной Ubuntu версии не ниже 18.04.
2. Настроенный S3cmd.
3. Пользователь в Облачном хранилище, созданный согласно инструкции Создание нового пользователя.

Создание скрипта для резервного копирования

В данной инструкции рассмотрим создание базового bash-скрипта, который создает резервную копию файла или каталога с помощью tar и далее загружает эту резервную копию в Облачное хранилище с помощью утилиты командной строки s3cmd.

Откройте на своем сервере домашнюю директорию:

С помощью редактора nano создайте пустой файл, например, с именем bkupscript:

Начните писать скрипт резервного копирования в текстовом редакторе с шебанга. Шебанг — это директива интерпретатора, которая позволяет запускать скрипты или файлы данных как команды и выглядит как последовательность из двух символов: решетки и восклицательного знака. Включая шебанг в начало скрипта, мы говорим оболочке запускать команды файла в bash.

Назначение переменных

Добавьте в скрипт переменные прямо под шебангом в верхней части текстового файла:

• DATETIME содержит метку времени, которую нужно прикрепить к имени полученного файла, чтобы каждый файл, резервная копия которого хранится в пространстве, имел уникальное имя. Эта временная метка создается путем вызова команды date и форматирования вывода для отображения двух последних цифр года (% y), двух цифр месяца (% m), двух цифр дня (% d), час (% H), минуты (% M) и секунды (% S);
• SRC — это исходный путь для файла или папки, в которую мы делаем резервную копию. $1 указывает, что мы берем это значение из первого параметра, переданного скрипту;
• DST — место назначения файла. В нашем случае это имя пространства, в которое мы загружаем резервную копию. Это имя будет получено из второго параметра, переданного в скрипт, как указано в $2;
• GIVENNAME — выбранное пользователем имя для файла назначения. Результирующее имя файла будет начинаться с GIVENNAME, и к нему будет добавлено DATETIME. Это имя происходит от третьего параметра, переданного скрипту $3.

Вывод сообщений

Добавьте функцию showhelp в скрипт резервного копирования для вывода сообщений в случае сбоя работы скрипта:

Сбор файлов

Прежде чем скрипт сможет передавать что-либо в выбранное пространство, ему сначала необходимо собрать нужные файлы и объединить их в единый пакет, который мы можем загрузить. Это выполняется с помощью утилиты tar, условных операторов и функции tarandzip:

Когда вызывается инструкция if, скрипт выполняет команду tar и ожидает результата. Если команда выполнена успешно, будут выполнены строки после оператора then:

• вывод сообщения о том, что процесс tar успешно завершился;
• возвращение кода ошибки 0, чтобы часть кода, вызывающая эту функцию, знала, что все работает нормально.

Часть else этого скрипта будет выполняться только в том случае, если команда tar обнаружит ошибку при выполнении:

• вывод сообщения о том, что команда tar не выполнена;
• возвращение кода ошибки 1, что указывает на то, что что-то пошло не так.

Заканчивайте скрипт if/then/else фразой fi , что на языке bash означает, что предложение if закончилось.

Завершенная функция tarandzip будет выглядеть так:

Перенос файлов в объектное хранилище

Добавим в скрипт резервного копирования функцию передачи файла movetoSpace в выбранное пространство с помощью команды s3cmd. Используем s3cmd и переменные, которые мы объявили ранее, для создания команды, которая будет помещать файлы резервных копий в выбранное пространство:

• /bin/s3cmd вызывает s3cmd — инструмент командной строки, используемый для управления сегментами хранилища объектов;
• put используется s3cmd для загрузки данных в бакет;
• $ GIVENNAME- $ DATETIME.tar.gz — это имя резервной копии, которая будет загружена в пространство. Он состоит из четвертой и первой объявленных нами переменных, за которыми следует .tar.gz, и создается функцией tarandzip;
• s3: // $ DST ; — место, куда мы загружаем файл;
• s3: // — это схема типа URI, используемая для описания мест хранения объектов в сети, а $DST; — это третья переменная, которую мы объявили ранее.

Добавьте уведомления о том, что процесс переноса файлов начался:

Поскольку команда будет либо успешной, либо неудачной (это означает, что она либо загрузит файлы в выбранное пространство, либо нет), можно сообщить пользователям, сработала ли она, повторив одну из двух строк, содержащихся в if/then/else, например:

В целом функция movetoSpace должна выглядеть так:

Настройка управления потоком

Предполагая, что скрипт настроен правильно, он при запуске должен прочитать команду ввода, присвоить значения из нее каждой переменной, выполнить функцию tarandzip, а затем выполнить функцию movetoSpace.

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

Мы можем упорядочить отлов ошибки, добавив в конец файла условную инструкцию if / then / else:

Первый оператор if в приведенном выше разделе проверяет, что третья переданная переменная не пуста. Это происходит следующим образом:

• [] — квадратные скобки означают, что то, что находится между ними, является тестом. В этом случае проверка заключается в том, чтобы конкретная переменная не была пустой;
• ! — в данном случае этот символ означает «нет»;
• -z — эта опция указывает на пустую строку и в сочетании с ! мы запрашиваем не пустую строку;
• $ GIVENNAME указывает, что строка, которая не должна быть пустой, является значением, присвоенным переменной $GIVENNAME. Этой переменной присваивается значение, переданное третьим параметром, при вызове скрипта из командной строки. Если мы передадим сценарию менее 3 параметров, в коде не будет третьего параметра для присвоения значения $GIVENNAME, он назначит пустую строку и этот запуск завершится ошибкой.

Пример скрипта

Завершенный скрипт выглядит следующим образом:

После проверки скрипта закройте файл сочетанием клавиш CTRL+Х и сохраните внесенные изменения клавишей Y+ENTER перед выходом из nano.

Автоматизация резервного копирования с помощью Crontab

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

Сделайте скрипт исполняемым:

Отредактируйте файл crontab, чтобы скрипт запускался каждую минуту:

При первом запуске команды crontab -e будет предложено выбрать редактор из списка:

Можно выбрать nano по умолчанию или любой другой текстовый редактор.

Перейдя в crontab, добавьте следующую строку внизу скрипта:

Закройте файл сочетанием клавиш CTRL+Х и сохраните внесенные изменения клавишей Y+ENTER.

Если оставить задание cron запущенным без каких-либо изменений, новый файл будет копироваться в выбранное пространство каждую минуту. Убедившись, что cron работает успешно, перенастройте crontab для резервного копирования файлов с нужным интервалом.

Источник

bash: Бэкап без лишнего ПО

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

Задача: Бэкап данных в локальную директорию и на отдельный сервер, с использованием минимума стороннего ПО, логированием и оповещением администратора в jabber при сбоях. Все основные функции большинства ПО для автоматического бэкапа, но без установки оного, а следовательно без его багов (что, собственно, и привело к подобной идее).

А теперь к делу.

Для начала создадим и откроем скрипт

Теперь в скрипте добавим строку

Объявим некоторые переменные.
TN — TASKNAME — имя задания.Используется для вывода в лог и определения названия файла.
Так как заданий несколько (ежемесячное, еженедельное, ежедневное) и писать на каждый случай скрипт было лень, я создал универсальный, в котором надо просто раскомментить нужные строки. Наименование заданий писать надо без пробелов, желательно в латинице, если не хотите проблем с кодировкой и неправильными параметрами команд.

OF — Output File — имя выходного файла. Получается из переменной TN, то есть имени задания.

Объявляем переменную с путем к файлу лога, и далее все сообщения об ошибках и остальном будем выводить в лог.

Сделаем запись в лог о начале бэкапа (дата, время, имя задания)

Есть проблема в том что если указывать в параметрах команд (напр. tar) имена каталогов с пробелами, скрипт срабатывает с ошибкой. Решение найдено на просторах интернета — операционная система linux использует пробел в качестве стандартного разделителя параметров команды. Переопределим стандартный разделитель (хранится в переменной $IFS) отличным от пробела, например \n – знаком переноса строки.
Запоминаем старое значение стандартного разделителя

Заменяем стандартный разделитель своим

SRCD — SouRCe Directory — каталог с данными для бэкапа
Теперь можно перечислять несколько каталогов, разделителем будет перенос строк как мы сами указали строкой выше

TGTD — TarGeT Directory — каталог в который будут складываться бэкапы

Естественно мы понимаем что хранить важные бэкапы только на источнике как минимум легкомысленно. Поэтому оставим копию и на удаленном ресурсе, который будем отдельно монтировать с помощью mount и fstab. Сразу поясню почему я использовал mount и fstab, а не один mount — я монтирую этот каталог и в других своих скриптах, а как сказал один из знакомых программистов — хороший программист не будет писать один и тот же код дважды (как-то так, дословно не помню, но надеюсь смысл донес).

Сам процесс архивирования в варианте «Создать новый архив»

и в варианте «Обновить файлы в старом архиве»

Во втором случае лучше вместо $OF использовать конктретное имя файла потому что у меня например ежедневно апдэйтится еженедельный архив, а их $TN (имена задания) не совпадают, соответственно и $OF.

В переменной «?» ханится статус выполнения последней команды. Сохраним его, чтобы воспользоваться позже.

Возвращаем стандартный разделитель к исходному значению

Теперь добавим условие — если процесс упаковки в архив 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 строк лога во временный файл, потом затрем им лог

Источник

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

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

Введение

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

Из статьи вы узнаете как я подхожу к этому вопросу и защищаю бэкапы всех своих ресурсов надежно и безопасно в системах Linux.

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

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

Основа безопасности бэкапов

Правильность и безопасность бэкапов включает в себя несколько простых правил:

1. Хранение бэкапов за продолжительный период времени. Вариантов почему лучше хранить бэкапы долго множество. Например, удалили какой то материал, но решили восстановить спустя некоторое время или необходимо найти ошибку когда появилась проблема которую обнаружили не сразу.
2. Забарать бэкапы сторонним сервером. В идеале лучше использовать под резервные копии специальный сервер использующийся только для бэкапов. В случае если копии бэкапов отправляются с самого сервера где делаются бэкапы это опасно, так как в случае взлома или вируса вы можете потерять все копии.
3. Мониторинг как создание бэкапа так и аналитика его размеров. Как бы вы не пытались отслеживать периодически сами как делаются бэкапы по закону подлости, когда они потребуются, обнаружите что они или не делаются или испорчены.

Ниже я по порядку опишу все свои действия которые использую на практике. Будут использованы стандартные программы используемые во всех версиях Linux.

Создание бэкапов на сервере

Самое надежное это когда производится создание резервных копии на самом сервере, так как это гарантирует что вы не получите проблем возникших с удаленным подключением к сторонним ресурсам. Например, при использовании бэкапа на Yndex Disk у меня периодически были ошибки при создании бэкапа.

Структура папок для бэкапов

Создавать папки можно где угодно. Например, мне больше нравится создавать их в корне папку backup и держать там всё что связанно с резервными копиями.

Создадим необходимые папки куда будем класть бэкапы

В итоге мы получили следующие папки:

• /backup — папка где будет находиться всё что связано с резервными копиями;
• /backup/bin — папка где будут находиться скрипты запускаемые по расписанию;
• /backup/infoit.com.ua/day — папка где будут лежать ежедневные бэкапы;
• /backup/infoit.com.ua/month — папка где будут лежать ежемесячные бэкапы;
• /backup/infoit.com.ua/source — папка в которой я храню копии которые были начальными. Например, в случае когда ресурс переносится с другого сервера или возвращается в жизнь после продолжительного перерыва в работе.

Backup и его периодичность

Всегда сложно выбрать какой необходим период хранения и интервал резервного копирования. Для меня удобней организовать резервное копирование по следующей схеме:

• Дневные копии — хранить 30 дней,
• Месячные копии — хранить год.

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

Создание скриптов для бэкапов

Создадим два скрипта для ежедневного и ежемесячного бэкапа.

Создадим скрипт который будем ежедневно запускать по расписанию:

Для ежемесячных бэкапов создадим такой скрипт:

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

После создания скриптов сделаем их исполнительными выполнив необходимую команду:

Добавление заданий в cron

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

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

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

Открываем необходимый файл и добавляем нужный код:

Согласно команде каждый день в 1:20 бедет выполнятся скрипт для создания ежедневного бэкапа и ежемесячно первого числа в 1:25 будет создаваться ежемесячная резервная копия.

Перезагрузим cron в системе CentOS для применения изменений:

Проверка создания бэкапов

Убедится что все работает правильно можно только запустив скрипт у посмотреть результат его работы.

Мне больше нравится брать код непосредственно из файла crontab, так как это последнее место которое выявит ошибки связаные с правильностью написания пути к скрипту.

Из вывода видно какие файлы забекапились и что база данных тоже успешно зарезервиловалась.

Осталось дождаться времени выполнения и проверить как отрабатывает команду cron.

Посмотреть результат работы cron можно заглянув в файл:

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

Создание копии backups используя rsync

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

Подключается к серверу с которого надо забирать бэкапы будем по сертификату. Для копирования будем использовать утилиту rsync.

Именно на этом сервере производится мониторинг правильности создания бэкапов и их размеры средствами программы для мониторинга Zabbix.

Узнать как работать со свободным программным комплексом для мониторинга вы можете из раздела Мониторинг Zabbix.

Возможности Zabbix удовлетворят любые потребности для осуществления любых параметров практически любой системы.

Подключение по сертификату

Более подробно о том как настраивать механизм подключения по сертификаты можете найти в статье RSA или авторизация SSH по ключу.

Скопируем на подключаемый ресурс необходимую часть ключа:

После успешного выполнения пробуем подключиться:

В случае успеха идём дальше.

Для безопасности можно создать пользователя на ресурсе откуда забираете данные и ограничить его только в папке откуда забираем резервные копии.

Создание скрипта для выполнения rsync

Создадим необходимый скрипт:

Скрипт задокументирован и выберите параметры исходя из ваших требований.

Расшифрую параметры указанные в коде:

• a — режиме архива;
• v — увеличение детализации;
• z — сжатие данных файла во время передачи;
• h — вывод чисел в удобочитаемом формате;
• e — используем ssh подключение.

После создания скриптов сделаем их исполнительными выполнив необходимую команду:

Добавление задания в cron

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

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

Открываем необходимый файл и добавляем нужный код:

Согласно команде каждый день в 6:30 бедет выполнятся скрипт который будет забирать резервные копии согласно вашим пожеланиям.

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

В случае вывода ошибки при выполнении скрипта:

Смотрите правильность указания всех путей и параметров или выполните в консоли команду rsync —help и разбирайте в параметрах команды.

Использование Yndex.Disk для backups

При регистрации домена мне нравится переводить его управление на Yandex. Для бэкапов создаю отдельный почтовый ящик на домене и туда копирую бэкапы сайта. Удобно передовать заказчику управление доменом и резервные копии в одном месте.

Yandex.Disk дает возможность подключится с помощью WebDav. Необходимо добавить пакет davfs2 для работы по WebDav.

К сожалению на данный момент невозможно передавать данные большого размера по WebDav на Yandex.

Вы можете установить на систему консольный клиент от Yandex и проводить резервное копирование с помощью его.

Официальная страница руководства пользователя имеет понятное описание по установке и использованию на разных системах.

Более подробно с описанием сервиса Yandex Disk вы можете ознакомиться перейдя в раздел техподдержки Яндекса.

Установка Davfs2

Рассмотрим настройку на примере системы CentOS 7.

Подключим репозиторий Еpel:

Установим пакет davfs2:

Настройка WebDav для Yandex.Disk

Создадим папку куда будем монтировать:

Чтобы не путаться в конце я указываю логин почты на котором находиться диск.

Смонтируем Yandex.Disk в необходимую папку:

Диск смонтировался в указанную папку.

Отмантировать диск можно командой:

Введение вручную данных при монтировании не всегда удобно и для удобства мы автоматизируем этот процесс.

Отредактируем файл /etc/davfs2/secrets, добавив в конец строку с данными для авторизации:

Так мы можем задать любое количество строчек с необходимыми ресурсами Yandex.Disk.

В случае если вы хотите чтобы диск монтировался при перезагрузке системы то в etc/fstab необходимо добавить строчку:

Теперь при перезагрузке сервера диск автоматически монтируется.

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

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

Создание скрипта для работы с Yandex.Disk

Создалим скрипт для выполнения копирования резервных копий на Yandex.Disk:

Скрипт выполнит следующие действия:

1. Сомнтирует удаленый Yandex.Disk;
2. Сделает зеркало с папки /backup/infoit.com.ua/day;
3. Отмонтирует Yandex.Disk;
4. Очистит кэш создаваемый при работе davfs2.

Очищать кэш созданный при работе davfs2 надо обязательно иначе место на диске быстро закончиться.

После создания скриптов дадим необходимые права для всех файлов в папке backup:

Добавление задания в cron

Откроем для редактирования /etc/crontab файл откуда выполнятся задания:

Перезагрузим cron в системе CentOS 7 для применения изминений:

Проверки осуществляем по аналогии с предыдущими главами.

Заключение

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

Источник