Нет бэкапа

Установка[править]

Серверправить

На сервер backup, мы устанавливаем:

1. директора:
   • bacula-director-common
   • bacula-director-mysql
2. клиента:
3. хранилище:
   • bacula-storage-common
   • bacula-storage-mysql
4. управление:
5. общая часть:
6. SQL:

Например:

yum install bacula-director-common bacula-director-mysql \
	bacula-client \
	bacula-storage-common bacula-storage-mysql \
	bacula-console bacula-common \
	mysql-server

Эти компоненты также возможно разнести на разные системы, но для простоты будем рассматривать случай когда директор, хранилище и сервер SQL будут на одной машине. Здесь же будет размещён клиент, чтобы делать резервную копию собственной конфигурации.

Вместо mysql есть возможность выбрать postgresql или sqlite.

Клиентправить

На машинах, с которых будет выполняется резервное копирование, нужно установить bacula-fd (File Daemon)

1. bacula-client

Управлениеправить

На компьютере, с которого будет происходить управление, нужно установить консоль которая есть как в виде CLI так и в виде GUI в асортименте:

1. CLI
2. GUI
   • bacula-console-gnome: Bacula console for the Gnome desktop environment
   • bacula-console-wxwidgets: Bacula console using the wx widgets toolkit
   • bacula-console-qt: Bacula Administration Tool Console (bat)
   • bacula-traymonitor: Bacula monitor for the Gnome and KDE system tray

Также, можно отдельно сделать веб интерфейс.

Настройка Bacula для PostgreSQL[править]

Настройка клиентаправить

Внимание! Для работы с Bacula на сервере PostgreSQL должно быть настроено онлайн резервирование )

На клиенте в каталоге /etc/bacula создадим следующие скрипты:pre-base-backup.sh:

#!/bin/bash
DATE=`date +"%b %d %T"`
/usr/bin/pg_basebackup -D /var/lib/pgsql/backup -F t -z -U postgres -w -c fast -l "pg_basebackup ${DATE}"

Этот скрипт создает полную копию базы данных и выполняется перед выполнением задачи резервного копирования базы.post-base-backup.sh:

#!/bin/bash
rm -f /var/lib/pgsql/backup/*

Этот скрипт удаляет созданную копию базы данных и будет выполнен после задачи резервного копирования базы.pre-logs-backup.sh:

#!/bin/bash
touch /var/lib/pgsql/backup_in_progress

Этот скрипт создает файл backup_in_progress и выполняется перед выполнением задачи резервного копирования журналов. Этот файл нужен, чтобы во время резервного копирования PostgreSQL не архивировал новые журналы ()post-logs-backup.sh:

#!/bin/bash
rm -f /var/lib/pgsql/wals/*
rm -f /var/lib/pgsql/backup_in_progress

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

# chmod 750 pre-base-backup.sh
# chmod 750 post-logs-backup.sh
# chmod 750 post-base-backup.sh
# chmod 750 pre-logs-backup.sh

На этом настройка клиента завершена.

Настройка сервераправить

Для онлайн резервного копирования PostgreSQL необходимо добавить в Bacula клиента и создать для него задачи. В этом примере рассмотрим настройку на примере клиента zabbix-fd.

Списки файловправить

Создадим списки файлов для резервного копирования в каталоге /etc/bacula/fileset.d:
Список для копирования полной резервной копии базы PGSQL-Full-Base-set.conf:

FileSet {
  Name = "PGSQL-Full-Base-set"
  Include {
    Options {
      signature = MD5
      Sparse = yes
      aclsupport = yes
      xattrsupport = yes
     }
    File = "/var/lib/pgsql/backup"
    }
}

Журналыправить

Список для копирования журналов PGSQL-Logs-set.conf:

FileSet {
  Name = "PGSQL-Logs-set"
  Include {
    Options {
      signature = MD5
      Sparse = yes
      aclsupport = yes
      xattrsupport = yes
     }
    File = "/var/lib/pgsql/wals"
    }
}

Пулправить

Создадим отдельный пул для наших бекапов в каталоге /etc/bacula/pool.d:
Файл zabbix.conf:

Pool {
  Name = Zabbix
  Pool Type = Backup
  Recycle = yes                       
  AutoPrune = yes                    
  Volume Retention = 365 days        
  LabelFormat = "zabbix"
}

Расписанияправить

Создадим расписания для резервирования базы и журналов в каталоге /etc/bacula/schedule.d:
Файл PGSQL-Full-Base-Cycle.conf:

Schedule {
  Name = "PGSQL-Full-Base-Cycle"
  Run = Full sun at 01:00 # задание будет выполнять полный бэкап каждое воскресенье в 01:00
}

файл PGSQL-Logs-Cycle.conf:

Schedule {
  Name = "PGSQL-Logs-Cycle"
  Run = Incremental mon-sat at 01:30 # задание будет выполнять инкрементальный бэкап каждый день с пн-сб в 01:30
}

Задачиправить

Создадим задачи резервного копирования в каталоге /etc/bacula/job.d:
Задача резервного копирования базы zabbix-pgsql-base-fd.conf:

Job {
  Name = "zabbix-pgsql-base-fd"
  JobDefs = "DefaultJob"
  Client = zabbix-fd
  FileSet = "PGSQL-Full-Base-set"
  Accurate = no
  Pool = Zabbix
  Priority = 10 # приоритет выполнения задачи
  Schedule = "PGSQL-Full-Base-Cycle"
  ClientRunBeforeJob = "/etc/bacula/pre-base-backup.sh" # скрипт выполняющийся до задачи
  ClientRunAfterJob = "/etc/bacula/post-base-backup.sh" # скрипт выполняющийся после задачи
}

Задача резервного копирования журналов zabbix-pgsql-logs-fd.conf:

Job {
  Name = "zabbix-pgsql-logs-fd"
  JobDefs = "DefaultJob"
  Client = zabbix-fd
  FileSet = "PGSQL-Logs-set"
  Accurate = no
  Pool = Zabbix
  Priority = 11 # приоритет ниже чем у задачи резервного копирования базы
  Schedule = "PGSQL-Logs-Cycle"
  ClientRunBeforeJob = "/etc/bacula/pre-logs-backup.sh" # скрипт выполняющийся до задачи
  ClientRunAfterJob = "/etc/bacula/post-logs-backup.sh"# скрипт выполняющийся после задачи
}

Теперь необходимо перезапустить сервис Bacula Director:

# systemctl restart bacula-dir

Клиент-серверный режим работы 1С (с базой данных на SQL)

Сервер – это компьютер. На нем установлена программа 1С:Сервер, которая позволяет запустить 1С:Предприятие 8 в клиент-серверном режиме. Это значит, что программа 1С, которую запускает пользователь на своем компьютере, работает с программой 1С:Сервер, а уже та, в свою очередь, работает с базой данных. В качестве инструмента управления базой данных используется СУБД – PostgreSQL, MS SQL или подобные.

Схема работы в клиент-серверном режиме

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

1. 1С:Сервер распределяет запросы к нужному файлу базы данных.
2. Определяет очередность выполнения операций.
3. Вносит изменения в базу данных.

В этом режиме ресурсоемкие операции выполняются на сервере, в месте хранения файлов базы данных, а не на компьютерах пользователей. Таким образом, для комфортной работы в программе 1С:Предприятие 8 будет достаточно только одной мощной машины. Задача компьютеров пользователей – отражение визуальной оболочки программы. С этим справится практически любой компьютер.

Клиент-серверный вариант позволяет:

1. Увеличить отказоустойчивость системы в случае экстренного отключения электропитания и большой загруженности локальной сети. Например, клиент-серверный режим работы позволяет настроить создание резервной копии базы данных каждые 30 минут прямо во время работы. Это значит, что даже если случится авария на сервере, будут потеряны данные только за полчаса, и уже через час ваша компания снова будет работать в обычном режиме.
2. Ускорить работу системы за счет отсутствия необходимости в постоянной транспортировке данных между компьютерами сети.
3. Предотвратить кражу данных пользователями системы 1С: Предприятие 8. База данных состоит из множества файлов, которые хранятся на сервере и управляются отдельной СУБД. Копирование файлов возможно только разрозненными частями, которые не дают какой-либо информативности. Для выгрузки базы данных в работоспособном формате необходим доступ с правами администратора к 1С:Серверу и СУБД.
4. Снизить риски повреждения базы данных. База статична – хранится и изменяется на одном компьютере, а значит повреждение во время транспортировки от пользователя к пользователю исключены.

Установка Webacula в Ubuntu

В статье буду описывать установку Webacula на Ubuntu 8.04 LTS, хотя для других дистрибутивов общий принцип сохраняется. Для Webacula нам потребуется: веб-сервер с модулем mod_rewrite и поддержкой PHP, Zend Framework версии 1.8.3 (требует PHP 5.2.4 или выше) с установленным расширением PDO, пакет php-gd. В качестве СУБД можно использовать MySQL или PostgreSQL (поддержка появилась в текущей версии Webacula). И собственно Bacula. Разработчики рекомендуют использовать версию 3.х, но в репозитарии Ubuntu 8.04 находится более ранняя версия Bacula 2.4.2, с которой Webacula отлично срабатывается.

Устанавливаем пакеты для MySQL:

$ sudo apt-get install mysql-server mysql-client

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

$ sudo mysqladmin -u root password пароль

По умолчанию Bacula устанавливается с поддержкой MySQL для директора (Director) и сервера хранения (Storage Daemon, SD).

$ sudo apt-get install bacula 

НОВЫЕ пакеты, которые будут установлены:
 bacula bacula-client bacula-director-mysql bacula-sd-mysql bacula-server

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

$ sudo nano /etc/bacula/bacula-dir.conf 
Catalog {
 Name = MyCatalog
 dbname = "bacula"; dbuser = "bacula"; dbpassword = "baculapass"
}
# для вывода сообщений выводимых при выполнении заданий

Для показа сообщений, которые выводятся во время выполнения заданий измените блок

Messages: 
Messages {
Name = Standard
...
catalog = all, !skipped, !saved
}

Настройку остальных параметров работы Bacula рассматривать не будем. Перезапускаем демон директора.

$ sudo /etc/init.d/bacula-director restart

Утилита “netstat” должна показать активность трех демонов:

$ netstat -l | grep bacula
tcp 0 0 comp.serv:bacula-dir *:* LISTEN
tcp 0 0 comp.serv:bacula-fd *:* LISTEN
tcp 0 0 comp.serv:bacula-sd *:* LISTEN

C Bacula закончили.

Журнал сообщений Bacula

Bacula поддерживает следующие типы сообщений:

• информационное (info)
• предупреждение (warning)
• ошибка (error)
• критическая ошибка (fatal)
• остановка (terminate)
• перечень пропущенных файлов (skipped);
• список файлов, сохраненных без ошибок (saved)
• список файлов, которые не удалось сохранить (notsaved)
• перечень восстановленных файлов (restored)
• потребность подключить новый том (mount)
• ошибка авторизации (security)
• все типы (all).

Для отправки сообщений Bacula использует собственный средство – bsmtp, которое может отправлять сообщения не только локальным пользователям, но и на удаленный smtp-сервер.

Установка клиента для Windows

Для этого существуют уже собранные пакеты на вебсайте Bacula.org. Они содержат Клиент, процесс Хранения и bconsole / BAT console для Windows, но конкретно в этом случае мы устанавливаем только Клиент, так как это более реалистично если речь идет о бэкапе серверов производства.

• Скачайте и распакуйте клиентские пакеты с Bacula.org: https://blog.bacula.org/binary-download-center/ (или корпоративный репозиторий Bacula Systems)
• Запустите файл Setup с правами Администратора (Системы и Домена, если возможно). Примите лицензионное соглашение.
• Выберите тот .exe файл, который подходит под вашу архитектуру Windows: 32 bit или 64 bit. Например: bacula-win64-9.4.0.exe.
• Запустите этот файл и примите условия лицензионного соглашения.
• Как показано ниже, выберите Custom Setup (позволяет вам настроить клиент, включая имя Директора, и возможность скопировать сгенерированный случайный пароль для последующих взаимодействий с бэкап-сервером).

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

Следующим шагом станет возможность изменить имя клиента Bacula и пароль для Директорского доступа к устанавливаемому клиенту. Скопируйте этот пароль, затем продолжайте.

И наконец, введите имя Директора так же, как указано на вашей основной машине-сервере (bacula-dir-conf — Director resource). Эту информацию также можно получить, открыв bconsole или используя команду version.

• Дождитесь окончания установки. Закройте все последующие всплывающие окна.
• Переходите к разделу настройки клиента Bacula.

Запуск резервного копирования вручную

Bacula теперь знает, как нужно записывать данные резервной копии. Теперь можно запустить резервное копирование, чтобы убедиться, что Bacula работает правильно:

Программа предложит выбрать задачу, которую нужно запустить. Чтобы выбрать BackupLocalFiles, введите 1.

Чтобы запустить задачу, на запрос Run Backup job нужно ответить yes.

Проверка сообщений и состояния

После запуска задачи Bacula создаст сообщения, в которых хранится вывод, сгенерированный задачей.

Чтобы проверить сообщения, введите:

В сообщениях должно быть указано «No prior Full backup Job record found» и что задача резервного копирования запустилась. Если при запуске задачи что-то пошло не так, в сообщениях вы найдете подсказки по устранению неполадок.

Также вы можете узнать состояние задачи. Для этого нужно запросить состояние Director. Введите в bconsole:

Если задача выполняется успешно, вы увидите примерно такой вывод:

Когда задача будет завершена, в отчете о состоянии она перейдет в раздел Terminated Jobs:

Состояние OK значит, что задача выполнена успешно.

Теперь у вас есть резервная копия Full Set, созданная с помощью Bacula.

Перезапуск сервиса Директора

Необходимо перезапустить сервис командой:

sudo systemctl restart bacula-director.service

Если все настроено правильно, то никаких сообщений об ошибках мы не увидим. Если что то пошло не так — смотрим журналы Bacula и системы, проверяем права доступа к каталогам и к файлам самой Bacula на Директоре. Так же пониманию возникших ошибок хорошо помогает анализ вывода команды:

sudo journalctl -xe

Альтернативный вариант:

Создаем сценарий script.sh со следующим содержимым:

#!/bin/bash

mkdir /etc/bacula/backup-default-confmv /etc/bacula/bacula-dir.conf /etc/bacula/backup-default-conf/bacula-dir.conftouch /etc/bacula/bacula-dir.confmcedit /etc/bacula/bacula-dir.conf

mkdir /etc/bacula/schedule.d/mkdir /etc/bacula/client.d/mkdir /etc/bacula/fileset.d/mkdir /etc/bacula/job.d/

touch /etc/bacula/schedule.d/dir-fd.confmcedit /etc/bacula/schedule.d/dir-fd.conftouch /etc/bacula/schedule.d/catalog.confmcedit /etc/bacula/schedule.d/catalog.conf

touch /etc/bacula/client.d/dir-fd.confmcedit /etc/bacula/client.d/dir-fd.conf

touch /etc/bacula/fileset.d/dir-fd.confmcedit /etc/bacula/fileset.d/dir-fd.conftouch /etc/bacula/fileset.d/catalog.confmcedit /etc/bacula/fileset.d/catalog.conf

touch /etc/bacula/job.d/backup-dir-fd.confmcedit /etc/bacula/job.d/backup-dir-fd.conftouch /etc/bacula/job.d/restore-dir-fd.confmcedit /etc/bacula/job.d/restore-dir-fd.conftouch /etc/bacula/job.d/catalog.confmcedit /etc/bacula/job.d/catalog.conf

chmod 644 /etc/bacula/bacula-dir.confchown root:bacula /etc/bacula/bacula-dir.conf

chmod 755 /etc/bacula/job.d/chown root:bacula /etc/bacula/job.d/chmod 644 /etc/bacula/job.d/*chown root:bacula /etc/bacula/job.d/*

chmod 755 /etc/bacula/client.d/chown root:bacula /etc/bacula/client.d/chmod 644 /etc/bacula/client.d/*chown root:bacula /etc/bacula/client.d/*

chmod 755 /etc/bacula/fileset.d/chown root:bacula /etc/bacula/fileset.d/chmod 644 /etc/bacula/fileset.d/*chown root:bacula /etc/bacula/fileset.d/*

chmod 755 /etc/bacula/schedule.d/chown root:bacula /etc/bacula/schedule.d/chmod 644 /etc/bacula/schedule.d/*chown root:bacula /etc/bacula/schedule.d/*

cp /etc/bacula/bat.conf /etc/bacula/backup-default-conf/bat.confmcedit /etc/bacula/bat.conf

cp /etc/bacula/bconsole.conf /etc/bacula/backup-default-conf/bconsole.confmcedit /etc/bacula/bconsole.conf

systemctl restart bacula-director.service

Настройка Nginx

Теперь нужно настроить Nginx для обслуживания PHP-приложений.

Для начала создайте файл htpasswd, чтобы неавторизованные пользователи не могли получить доступ к Bacula-web. Используйте htpasswd, чтобы создать учётную запись администратора, имеющего доступ к Bacula-web.

Примечание: В данном руководстве этот пользователь зовётся admin, но такое имя нельзя использовать из соображений безопасности.

По запросу укажите пароль и запомните его – он понадобится для авторизации.

Затем откройте конфигурационный файл стандартного блока server в текстовом редакторе:

Замените содержимое файла следующим блоком кода. Не забудьте указать свой домен или IP-адрес в строке server_name.

Сохраните и закройте файл. Теперь Nginx будет обслуживать PHP-приложения и использовать созданный ранее файл htpasswd.

Чтобы новые настройки вступили в силу, перезапустите Nginx:

Теперь можно приступать к загрузке Bacula-web

А вот и практический пример

«Это очень важный, критический сервис, и, если он будет простаивать больше 5 минут – случатся <такая-то сумма>-финансовые потери, а через 30 минут простоя – в 10 раз больше! И это уже не приемлемо для компании.»

1. Нам, прежде всего, необходимо отследить момент возникновения сбоя.
2. Определить последствия от сбоя: всё сломалось или что-то доступно.
3. Желательно найти причины возникновения сбоя, или хотя бы локализовать (изолировать) проблему: если пожар – потушить его, прежде чем пытаться восстановить что-либо в ту же инфраструктуру; если вирус портит данные – отключить от сети зараженный сервер, а не кормить вирус восстановленным сервером.
4. Далее определить способы реанимации (наиболее подходящую процедуру восстановления: перегрузить ВМ, дождаться переключения кластера на другую ноду, или восстановить из резервной копии).
5. Принять решение по восстановлению и собственно запустить восстановление.

Очень важно!

Bacula — решение для резервного копирования под Linux

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

Резервное копирование — процесс создания копии данных на резервный носитель.

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

Прежде всего отметим, что Bacula — это клиент-серверное решение, основные компоненты которого — Bacula Director, Bacula Storage, Bacula File Daemon. Ниже поясним детально про каждый из них.

Bacula Director (bacula-dir) — это главный компонент системы, назначение которого управлять всеми процессами резервирования и восстановления данных. Основной смысл этого сервиса в планировании и управлении задачами по резервному копированию (Job), а также в обслуживании Каталога (Catalog).

Bacula Storage (bacula-sd) — сервис, который представляет из себя хранилище, назначение которого, сохранять резервные копии на физическом носителе.

Bacula File Daemon (bacula-fd) — это клиент, который устанавливается на каждой машине, он выполняет резервное копирование (или восстановление и проверку данных) по запросу Bacula Director.

Также еще имеются такие важные сервисы, как Bacula Console и Catalog.

• Bacula Console (bconsole) — это специальная утилита для управления Bacula из командной строки, есть и другие ее варианты (под веб-интерфейс).
• Catalog — это БД для хранения информации о местонахождении всех зарезервированных файлов в резервных копиях и для обеспечения эффективной адресации к нужным файлам. Как правило, для Ubuntu поддерживаются следующие СУБД: PostgreSql и Postfix.

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

Далее, мы расскажем, как произвести установку и настройку Bacula под Ubuntu 20.04.

Установка Bacula

Чтобы установить клиент и сервер Bacula, введите:

Программа запросит информацию для настройки Postfix:

• General Type of Mail Configuration: выберите Internet Site.
• System Mail Name: укажите FQDN или имя хоста.

Затем Bacula запросит информацию о базе данных:

• Configure database for bacula-director-mysql with dbconfig-common?: выберите Yes.
• Password of the database’s administrative user: введите root-пароль MySQL.
• MySQL application password for bacula-director-mysql: Введите новый пароль и подтвердите его; чтобы программа выбрала случайный пароль, оставьте поле пустым.

Затем нужно обновить права на сценарий, который Bacula использует во время бэкапа каталога.

Сервер и клиент Bacula установлены.

Восстановление копии

После создания резервной копии важно убедиться, что её можно восстановить. В консоли bacula введите:. Появится меню, содержащее широкий ряд опций

Чтобы восстановить последнюю резервную копию, выберите 5:

Появится меню, содержащее широкий ряд опций. Чтобы восстановить последнюю резервную копию, выберите 5:

Это откроет дерево виртуальных файлов со структурой скопированных каталогов. Интерфейс позволяет легко добавлять и исключать файлы для восстановления при помощи простых команд.

Поскольку была выбрана опция restore all, каждый скопированный ранее файл будет восстановлен.

Чтобы выполнить тонкую настройку восстановления, просмотрите список файлов при помощи команды ls и cd, выберите файлы для восстановления при помощи команды mark и исключите ненужные файлы при помощи unmark. Чтобы получить полный список команд, запустите через консоль:

Завершив, выйдите из режима выбора файлов с помощью команды:

Подтвердите восстановление копии:

Проверьте сообщения об ошибках:

Резюме восстановления должно иметь такой вид:

Завершив, ведите exit, чтобы закрыть консоль bacula.

Проверка файловой системы

Чтобы убедиться, что резервное копирование прошло успешно, просмотрите содержимое резервного каталога. Для этого понадобятся привилегии sudo, поскольку права на структуру каталогов принадлежат пользователю bacula:

На экране появится файл с именем, установленным ранее для архива.

Теперь проверьте точку восстановления. Чтобы просмотреть её содержимое:

Вы увидите зеркало файловой структуры root, за исключением файлов и каталогов, внесённых в раздел Exclude файла bacula-dir.conf.

Примечание: Bacula также является производительным решением для удалённого резервного копирования, о чём можно прочесть в следующей статье этой серии.

BaculaMySQLUbuntu 12.04

Загрузка и настройка Bacula-web

Перейдите в домашний каталог и загрузите последнюю версию архива Bacula-web (на момент написания статьи это 7.0.3):

Затем создайте новый каталог по имени bacula-web, откройте его и извлеките загруженный архив.

Прежде чем скопировать файлы в document root сервера, нужно настроить приложение Bacula-web.

Откройте конфигурационный каталог:

Bacula-web предоставляет пример настроек. Скопируйте его:

Затем откройте конфигурационный файл в текстовом редакторе:

Найдите // MySQL bacula catalog и раскомментируйте его. Замените password паролем базы данных Bacula:

Сохраните и закройте файл.

Теперь приложение Bacula-web настроено, и теперь нужно только переместить его файлы в Document Root.

Настройка Bacula Director

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

Для начала настройте Bacula Director.

Откройте конфигурационный файл компонента:

Настройка локальных задач

Задачи Bacula (job) выполняют резервное копирование и восстановление данных. Ресурсы задания – это подробные данные о том или ином задании: имя клиента, файлы для бэкапа или восстановления (FileSet) и многое другое.

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

Найдите ресурс Job с именем BackupClient1. Замените значение в строке Name именем BackupLocalFiles.

Затем найдите ресурс Job с именем RestoreFiles. В строке Name укажите имя RestoreLocalFiles, а в строке Where – каталог /bacula/restore.

Теперь RestoreLocalFiles сможет хранить файлы в каталоге /bacula/restore.

Файлы для бэкапа

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

Найдите ресурс FileSet по имени Full Set (под комментарием # List of files to be backed up). Сюда нужно внести следующие изменения:

• Добавить сжатие gzip.
• В разделе Include заменить /usr/sbin в строке File на /.
• В разделе Exclude во второй строке File указать /bacula.

Рассмотрим изменения в FileSet под названием Full Set. Во-первых, при создании резервного архива будет использоваться сжатие gzip. Во-вторых, в резервное копирование включается весь корневой раздел. В-третьих, из резервного копирования исключается каталог /bacula, потому что иначе Bacula будет создавать резервные копии каталога, в котором хранятся резервные копии.

Примечание: Если в / смонтированы другие разделы, которые нужно включить в FileSet, создайте в разделе Include дополнительные записи File для каждого из них.

Имейте в виду: резервные копии широких наборов FileSet (таких как Full Set) занимают больше места на диске, чем резервные копии более конкретных списков файлов. Например, если у вас есть четкий план, вам может хватить набора FileSet из пользовательских конфигурационных файлов и баз данных. Это поможет сэкономить дисковое пространство.

Просто и сердито. Архивирование (backup) типовых конфигураций 1С 8.2, 8.3

После эксплуатации различных «бесплатных» обработок и скриптов решил написать свой cmd-файл для ежедневного архивирования баз 1С.
Работает на конфигурациях, где есть процедуры «ЗавершитьРаботуПользователей» и «РазрешитьРаботуПользователей» (т.е. во всех типовых, в нетиповые данные модули можно скопировать из типовых).
Сохраняет файлы как локально так и на удаленном файловом сервере. Автоматически удаляет старые архивы и копирует на удалённый сервер отсутствующие.
Расписание задается установкой соответствующего задания (запуска cmd-файла по времени) в планировщике задач Windows.
Для борьбы с зависшими сеансами, рекомендуется настроить в режиме конфигуратора параметры информационной базы: «Время засыпания пассивного сеанса» и «Время завершения спящего сеанса».

Как появился VSS

Итак, судя по написанному выше, всё просто: нам надо просто брать появляющиеся блоки и сохранять их куда-то в сторонку, чтобы при необходимости вынимать обратно. Сразу возникает первый вопрос: а что именно надо сохранять в нашем теневом хранилище? Ведь действительно, можно просто писать в него все приходящие новые блоки и сохранять в метаданные, на какое место они (блоки) должны были быть записаны. А можно поступить чуть сложнее и записывать новые блоки сразу на полагающееся им место, а в хранилище отправлять содержимое перезаписываемых блоков. Что лучше и как выбрать? На самом деле право на жизнь имеют оба варианта, и какой выбрать — зависит исключительно от воли вендора. Первый подход (redirect-on-write, RoW, если оперировать грамотными терминами) быстро пишется, но долго читается. Зато если надо откатиться на первоначальное состояние, это делается моментально — мы просто удаляем наше теневое хранилище. Второй подход (copy-on-write, CoW) пишется медленней, читается быстрее и моментально удаляет копии предыдущих состояний. VSS, к слову, придерживается парадигмы CoW, а в снапшотах VMware реализован RoW.

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

Давайте рассмотрим хрестоматийную ситуацию с файлом базы данных. (И если у вас уже заскрипел песок на зубах, смело пропускайте следующие два абзаца.) Итак: у нас есть банальная SQL Server база данных в виде mdf файла, и тут к нам прилетает какой-то запрос. SQL, как порядочное приложение, начинает старательно вносить изменения в файл, а мы старательно перехватываем каждый новый блок данных падающих на диск и пишем в нашу теневую копию. Всё хорошо и здорово, но тут выключили свет. Потом свет включили, сервер запустили и мы даже базу восстановили из нашей теневой копии, но тут оказывается, что SQL не запускается. Говорит — база в не консистентном состоянии. Это значит следующее: во время нормальной работы завершение каждой транзакции помечается специальным флагом. Сервер его видит и знает, что всё хорошо. А тут сервер загружается, видит, что из его базы торчит какой-то кусок данных, флага нет и, следовательно, что с этим всем делать — он понятия не имеет. То ли удалить, то ли дописать, то ли ещё что-то. Но у нас тут не угадайка, а всё должно быть однозначно и консистентно. Поэтому он принимает решение выключиться, дабы не поломать базу ещё сильнее.

Хорошо, но как избежать подобных приключений? Отличным вариантом будет подождать, пока SQL сервер допишет свою транзакцию, пометит её как завершённую, и потом мы быстренько заберём все появившиеся новые блоки. Отличный вариант, который надо срочно реализовывать! Вот только есть небольшая проблема: до этого мы говорили про одно приложение и один файл, с которым оно работает. Научиться общаться с условным SQL Server много ума не надо, но что делать с остальными миллиардами существующих приложений? А что делать, в конце концов, с самой ОС, у которой внутри огромное количество своих процессов и открытых файлов? Вот примерно с такими проблемами и столкнулись учёные мужи из Microsoft, когда пришли к выводу, что надо реализовать некий общий интерфейс, через который можно будет сразу всем прокричать нечто вроде: “Сейчас мы будем делать снапшот, так что быстренько сворачиваемся и сбрасываем буфера на диск! Приостанавливайте свою кипучую деятельность и приводите данные в консистентный вид!”. Ну а назвать эту штуку они решили, как вы уже догадались, Volume Snapshot Service. Или просто VSS.

И тут можно воскликнуть — но ведь в Windows 2008 был представлен Kernel Transaction Manager! Это разве не то же самое? Он же как раз занимается тем, что приводит файлы на диске в консистентное состояние. А вот и нет! То есть да, KTM приводит, но отвечает только за дисковые операции, а что там происходит с приложениями — его мало волнует. А ведь многим из этих приложений важна не просто целостность файлов, но и что в них записано. Классический пример — это Exchange и Active Directory

И тут мы подошли к важной теме: