Proxmox VE. Windows 2008(R2) гости и ошибка службы VSS.

Здесь я описывал установку Windows гостя в Proxmox, теперь дошли руки до решения давних проблем, с которыми встретился.

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

Bacula. Удаление старых клиентов

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

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

1. Комментируем в bacula-dir.conf ссылку на конфиг клиента.
2. Удаляем запись о клиенте из базы данных (в моем случае postgresql):

   psql -U postgres -c "delete from client where name='client-name'" bacula

   где client-name полное имя клиента (можно посмотреть в каталоге /var/db/bacula там он представлен в виде client-name.bsr)
3. Запустить чек базы bacula:

   dbcheck -f -b -c /usr/local/etc/bacula/bacula-dir.conf

Bacula admin tool v7.x в Lubuntu 18.04

Имею настроенный сервер резервного копирования Bacula v7.4.7, переустанавливать который нет никакого желания (он отлично справляется со всеми задачами и что то менять нет смысла).
Недавно столкнулся с тем, что в новых версиях Linux (Lubuntu 18.x+, Debian 10.x+) из пакетов ставятся клиенты и прочие утилиты Bacula версии 9.x, которые оказываются несовместимы с моим сервером. Проблема решается установкой пакетов нужной версии:

wget http://launchpadlibrarian.net/317614807/bacula-common_7.4.4+dfsg-6_amd64.deb
wget http://launchpadlibrarian.net/317614808/bacula-console-qt_7.4.4+dfsg-6_amd64.deb

После скачивания устанавливаем, сначала bacula-common_7.4.4+dfsg-6_amd64.deb

Bacula. Скрипт для поиска и удаления из системы неиспользуемых томов

Столкнулся с интересной проблемой:

Стоит сервер с системой резервного копирования Bacula. Все настроено, все отлично работает. Но вот недавно обнаружилась нехватка дискового пространства, хотя по всем расчетам места было достаточно. В итоге анализа выяснилось следующее:
Для большинства серверов настроена схема резервирования 1/m Full, 1/w Diff, 1/d Increment (раз в месяц Полный, раз в неделю дифференциальный, в остальные дни инкрементный). Полные и дифференциальные бэкапы хранятся год, а инкрементные неделю-месяц, в зависимости от сервера. Кроме того выставлена опция делать полный бэкап при изменении конфига - в ней собака и зарыта. По определению дифф. или инкремент. бэкапы меньше полного и когда Вы меняете конфиг для сервера, то полный бэкап создается в пуле для типа бэкапа по планировщику (например сегодня задача инкрементного бэкапа, а в пуле для daily выполнился Full). Еще такой эффект будет наблюдаться в случае уменьшение файлсета или в любом другом случае, когда естественная ротация бэкапов приводит к уменьшению объема хранимой в пуле информации. В случае использования каких то продвинутых систем хранения в Bacula есть механизм переноса томов из пула в пул, но в моем случае неиспользуемые тома необходимо просто выявить и удалить.
Вот так ситуация выглядит в Bacula Admin Tool

Medoc и система резервного копирования Bacula

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

1. созданная встроенными средствами резервная копия не содержит настроек пользователей.
2. при достаточно большой базе, разворачивание длится совершенно непозволительное время(я понимаю, проверка ссылочной целостности и тд. и тп.), но я сталкивался с ситуациями когда база порядка 10 Гиг разворачивалась более 10 часов и это все под вопли бухгалтерии о срыве сроков отчетов и огромных штрафах (решение: развернуть локальную пустую базу по быстрому).