Linux and windows backup

Централизованное резервное копирование данных Windows и *nix серверов средствами Bacula

Приветствую всех хаброжителей!

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

Думаю вполне резонным будет предположение, что данная тема уже набила оскомину, но все же я рискну поделиться своим опытом. На суд читателя будет представлена клиент-серверная реализация схемы резервного копирования. В качестве инструмента я выбрал open source проект Bacula. По более чем полугодовому опыту его использования остаюсь доволен своим выбором.

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

Под хабракатом я опишу все демоны подробно

В моем случае резервному копированию подлежат:

1. Конфигурационные файлы различных демонов со всех серверов.
2. MySQL базы данных.
3. Документооборот с файлового сервера Windows.
4. Различные важные данные с nix серверов(движки сайтов/форумов, etc..)

1.Описание демонов Bacula

Система построена по технологии клиент-сервер, и для передачи данных использует протокол TCP. Резервные копии создаются в собственном, полностью открытом формате.

Система резервирования данных Bacula состоит из четырёх основных элементов: Director Daemon, Storage Daemon, File Daemon и Bacula Console. Все эти элементы реализованы в виде самостоятельных приложений.

Director Daemon (DD) – это центральный элемент системы, осуществляющий управление её остальными компонентами. В его задачи входит управление процессом резервирования/восстановления данных, обеспечение интерфейса управления для администраторов и многое другое. Говоря проще – это диспетчер, который инициирует все процессы и отслеживает ход их выполнения.

Storage Daemon (SD) – приложение, отвечающее за чтение/запись данных непосредственно на устройства хранения информации. Принимает управляющие команды от DD, а также резервируемые данные от/к File Daemon.

File Daemon (FD) – этот элемент ещё можно назвать Агентом. Ведь именно он работает в рамках операционной системы, данные которой необходимо резервировать. File Daemon выполняет всю рутину, осуществляя обращение к резервируемым файлам и их дальнейшую передачу к SD. Также на стороне FD выполняется шифрование резервных копий, если это определено конфигурацией.

Bacula Console (BC) – интерфейс администратора сиcтемы. По своей сути, это командный интерпретатор для управления Bacula. Строго говоря, Bacula Console может быть расширена с помощью графических систем управления, которые, как правило, являются всего лишь надстройкой над BC. К таким системам можно отнести Tray Monitor и Bat. Первая устанавливается на компьютере администратора системы и осуществляет наблюдение за работой системы резервирования, а вторая обеспечивает возможность управления посредством графического интерфейса.

Bacula Catalog – база данных, в которой хранятся сведения обо всех зарезервированных файлах и их местонахождении в резервных копиях. Каталог необходим для обеспечения эффективной адресации к требуемым файлам. Поддерживаются MySql, PostgreSql и SqLite.
Такое структурное деление позволяет организовать очень гибкую систему резервирования, когда Storage Daemon разворачивается на выделенном сервере с несколькими устройствами хранения данных. Также Bacula Director может управлять несколькими экземплярами SD, обеспечивая резервирование части данных на одно устройство хранения, а части – на другое.

2. ОС и железо

Теперь, когда у читателя сформировалось представление о работе демонов Bacula, я перейду к описанию того, как я реализовал всю эту красоту у себя.
В качестве аппаратного обеспечения для DD, SD и Bacula Catalog у меня выступает PC со следующими характеристиками

Устройство	Модель	количество	Емкость/Частота
HDD	Hitachi HDS723020BLA642	3	2Tb
CPU	AMD Phenom(tm) II X4 970 Processor	1	3500 Mhz
Motherboard	Gigabyte GA-880GA-UD3H	1	—
RAM	3541 Mb

О используемых на сервере ОС и версиях ПО

Хранением данных занимаются несколько software(mdadm) RAID массивов.
Под систему три партиции на трех дисках, грузится можно с любого из них, под бекапы один массив из двух партиций.

Имя массива	из каких партиций	точка монтирования	Файловая система	Уровень массива
md0	/dev/sda1,/dev/sdb1,/dev/sdc1	boot	ext2	1
md1	/dev/sda2,/dev/sdb2,/dev/sdc2	/	ext3	1
md2	/dev/sda3,/dev/sdb3	/backup	ext4	1

3. Описание схемы резервного копирования и настроек демонов Bacula

Всего у меня сконфигурированы 19 клиентов Bacula, но подробно я остановлюсь на описании бекапа сервера биллинга и документов с файлового сервера Windows. Фокус на эти два сервера обусловлен тем, что остальные клиенты настроены аналогично, и на примере этих серверов-клиентов можно строить свои конфигурации.

Резервное копирование сервера биллинга это, по сути, бекап базы данных mysql и конфигурационных файлов демонов.
BD позволяет выполнять локальный скрипт на клиенте как до, так и после задания.
Каждую ночь, при старте задания на бекап сервере, запускается локальный(на самом сервере биллинга) скрипт, который создает архив базы биллинга, далее этот архив забирает BD и помещает на соответствующий пул томов(на самом деле операциями с чтением/записью управляет SD, но это сейчас не важно). Сразу же после выполнения задания запускается еще один скрипт, который в свою очередь, перемещает созданный архив в отдельную папку на сервере биллинга, для пущей надежности. Таким образом архив БД будет как у Bacula, так и локально на сервере биллинга(да, я параноик). Подробнее эти механизмы и скрипты будут описаны ниже.

С файлового сервера Windows сохраняем весь необходимый документооборот. В воскресенье создается Full бекап, каждый последующий день, с понедельника по субботу, Diff бекапы.

Теперь о конфигурационных файлах демонов Bacula. Начнем с самого объемного — bacula-dir.conf.
Файлы конфигурации всех демонов Bacula состоят из описаний, так называемых, ресурсов. Каждый из ресурсов характеризует определенный функционал демона.
Я буду комментировать каждую строчку в конфиге, поэтому далее будут следовать блоки-ресурсы файлов Bacula(bacula-dir.conf, bacula-sd.conf, bacula-fd.conf), если что-то нужно объяснить более подробно укажите это в комментариях.
Ресурс Dirtector

Ресурс catalog, описываем подключение к БД

Для каждого клиента в заданиях указаны Pool и Storage.
Pool, извините за тавтологию, это пул томов(volume) на который размещаются резервные копии данных клиентов. У меня тома — это файлы в формате bacula, размещенные на software raid массиве. Для разных клиентов могут быть определены разные пулы томов. К примеру у меня созданы 6 пулов, для разных типов клиентов. В примере ниже описан лишь один из них, для данных биллинга.
Storage описывает какие физические устройства будут использованы в качестве томов.
(Storage BGB-ST описан в конфиге SD)
Ресурс Pool

Задание на примере бекапа базы данных биллинга.
Ресурс Client

Само задание.
Ресурс Job

Я обещал подробнее остановиться на скриптах выполняющихся до и после задания.
Скрипт до задания

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

Ресурс FileSet(что бекапим, а что нет)

Расписание запуска задания.
Ресурс Schedule

Подробно комментировать ресурсы для резервного копирования документов с сервера Windows я не буду, приведу соответствующую часть конфига bacula-dir.conf полностью

Конфигурационный файл BD на этом завершен. Переходим к конфигурации SD — описанию файла bacula-sd.conf

Ресурс Director(связь с BD описанном в конфиге bacula-dir.conf)

Начинается описание различных девайсов, всего у меня используется 4 разных девайса. Я приведу в качестве примера два, для биллинга и для Windows.
Ресурс Device для биллинга.

Ресурс Device для файлового сервера Windows

Конфигурационный файл bconsole.conf, доступ в консоль Bacula.

Не забудьте создать соответствующие Storage папки и назначить bacula владельцем этих папок.
Совет из комментариев

@/usr/local/etc/bacula/fileset.conf
Конфиги можно разделить на разные файлы,
Options < signature = MD5 compression = GZIP >
и включить компрессию.

Конфигурирование серверной части завершено.

Важно отметить, что каждый из клиентов должен резолвить fqdn имя сервера в его ip адрес! Обеспечте это средствами dns или пропишите в hosts!

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

4. Пример процедуры востановления

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

В портажах Gentoo я её не нашел, поэтому собирал из исходников.
Конфигурационный файл bat.conf полностью аналогичен bconsole.conf, приведенному ранее.
Итак, к примеру я хочу востановить архив базы данных биллинга за определенное число. Алгоритм, которым пользуюсь я, таков:
1. Открываем bat и находим нужное задание

2. вводим команду list files jobid=3059 для того чтобы убедиться что в задании есть нужные файлы

3. Теперь переходим в консоль(мне так удобнее просто=)). В консоли я восстановлю архив биллинга на другого клиента

4. Ждем успешного выполнения задания, статус можно отслеживать в том же bat

Еще несколько скриншотов

Благодарю всех кто дочитал мой опус до конца.
В качестве завершения позволю себе еще несколько советов.
Важно не только делать бекапы и отслеживать что они выполнились без ошибок, но так же и регулярно их разворачивать и проверять. Подобная практика даёт еще +100 к указанным в начале спокойствию, крепкости нервов и здоровью. Так же очень хорошей практикой является регулярное резервное копирование базы данных bacula и bsr файлов.

Источник

Бэкап сетевой шары (samba) в Linux по мотивам Windows Server Backup

Введение

Чем хороша служба Windows Server Backup и теневые копии? Они входят в поставку Windows Server и не требуют доплаты (если не использовать облачную архивацию), а также хорошо справляются с возложенными на них задачами. Для простых сценариев использования — очень достойное решение. А доступ к теневым копиям через диалог свойств файла — вообще очень удобен. Теперь попробуем сделать аналогично для файлового сервера Linux с Samba.

Доступ к предыдущим версиям файлов

Эту возможность нам дает модуль Samba shadow_copy2. Его надо прописывать в секции сетевого ресурса в файле smb.conf:

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

Теперь, если внутри папки path = /mnt/.share мы создадим подпапку @GMT-2016.12.25-10.17.52
то у нас ничего не выйдет. Добавим такие настройки в секции [general]:

Теперь в свойствах сетевой шары, в разделе предыдущих версий, мы увидим нашу «копию». Обратите внимание, время указывается в UTC и преобразуется в локальное по часовому поясу.

Создание архивов и snapshot

Иметь механизм доступа к копиям без механизма их создания — бесполезно. В этом нам поможет следующий скрипт (есть и официальный аналог):

#!/bin/bash # # LVM-ThinVolume BackUp with rsync script set # # (c) 2016 — # Andrew Leshkevich (magicgts@gmail.com) # # # This script set is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by the # Free Software Foundation, either version 2 of the license or, at your # option, any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, see . # # For a list of supported commands, type ‘thin_lv_backup help’ # # . Please forgive me for bad english . # ################################################################################################ ################################################################################################ #Mount the snapshot to the specified mount point, if a snapshot is not active, then activate it # Arguments: # $ <1>— Short path to Volume (in VG/LV format) # $ <2>— Mount point # $ <3>— Optional LMV Volume attribute # Returns: # Return 0 if no errors ################################################################################################ mount_snapshot() < local SRC=$<1>local MNT_TGT=$ <2>[ «$#» -lt 2 ] && echo ‘Error: expected / [ ]’ && return 1 if [ «$#» -eq 2 ]; then local ATTR=$(lvs —noheadings -o lv_attr $) else local ATTR=$ <3>fi findmnt -nf —source /dev/$ >/dev/null 2>&1 && echo «Skip: LV $ is already mounted!» && return 0 findmnt -nf —target $ >/dev/null 2>&1 | grep -v -q $ && echo «Skip: the directory $ is already a mount point» && return 3 if [ ! -d «$» ]; then mkdir -p «$» || echo «Error: Creating directory $» || return 4 echo «Info: directory $ has been created» fi find $ -prune -empty | grep -v -q $ && echo «Skip: $ directory is not empty» && return 5 [[ $ =

.*a.* ]] || lvchange -ay -K $ || echo «Error: Volume Activation $» || return 6 mount -o ro,nouuid /dev/$ $ || echo «Error: Mounting $» || return 7 return 0 > ################################################################################################ # UnMount snaphot, deactivate volume and remove it mount point directory # Arguments: # $ <1>— Short path to Volume (in VG/LV format) # Returns: # Return 0 if no errors ################################################################################################ umount_snapshot() < local SRC=$<1>local TGT [ «$#» -ne 1 ] && echo ‘Error: expected / ‘ && return 1 local _TGT=(«$( findmnt -nf —source /dev/$ | cut -d ‘ ‘ -f 1 )») if [ ! -z «$_TGT» ]; then umount -A /dev/$ || echo «Error: Umounting $» || return 2 for TGT in «$<_TGT[@]>«; do find $ -prune -empty | grep -q «$» && rm —one-file-system -df $ [ -d «$» ] && echo «Info: Fail to remove target directory $» done fi lvchange -an -K $ || echo «Error: Volume Deactivation $» || return 3 return 0 > ################################################################################################ # Mount all associated snapshots of the volume to its origin mount points # All snapshots must be named on the template: -GMT-%Y.%m.%d-%H.%M.%S # Arguments: # $ <1>— Short path to Origin Volume (in VG/LV format) # $ <2>— Optional archive volume group, that used to mount all archive snapshots # Returns: # Return 0 if no errors ################################################################################################ mount_all_snapshot() < local SRC=$<1>local A_VG=$ <2>local ATTR_S local SNAP [ «$#» -lt 1 ] && echo ‘Error: expected / []’ && exit 1 IFS=$’/’ read -r -a ATTR_S / ‘ && return 1 IFS=$’/’ read -r -a ATTR_S / [

]’ && exit 1 local DATE=$(date -u +GMT-%Y.%m.%d-%H.%M.%S) [ «$#» -eq 2 ] && DATE=»$<2>» IFS=$’/’ read -r -a ATTR_S / ‘ && return 1 IFS=$’/’ read -r -a ATTR_S / ‘ && return 1 local VOL_SRC=$ <1>local MNT_TGT=$ <2>mkdir -p $ mount /dev/$ $ || echo «Error: Mounting $» || return 7 > ################################################################################################ # Post archive operation: unmount target volume, remove its mount point, create its snaphot # Arguments: # $ <1>— Short path to Origin Volume (in VG/LV format) # $ <2>— Mount point for $ <1># Returns: # Return 0 if no errors ################################################################################################ post_archive() < [ "$#" -ne 3 ] && echo 'Error: expected / / ' && return 1 local VOL_SRC=$<1>local MNT_TGT=$ <2>local TGT=$ <3>umount /dev/$ && rm -rd $ && lvcreate -n $ -s /dev/$ && return 0 return 1 > ################################################################################################ # Create rsync archive # Arguments: # $ <1>— Short path to Origin Volume (in VG/LV format) # $ <2>— Name of archive Volume Group # $ <3>— Optional connection string in @ format # $ <4>— Optional path to this script on remote machine # $ <5>— Optional prefix name for volume name on remote machine (

— -GMT-%Y.%m.%d-%H.%M.%S) # $ <6>— Optional also make local archive # Returns: # Return 0 if no errors ################################################################################################ create_archive() < local SRC=$<1>local TGT=$ <2>local CONN=$ <3>local CALL=$ <4>local PREFIX=$ <5>local ATTR_S local ATTR_D local RESULTS local RET [ «$#» -lt 2 ] && echo ‘Error: expected / [

Источник