Error Veeam Backup and Replication: «Unable get OIB by id»

Неожиданно на агентском задании бекапа SQL-кластера в Veeam BR 9.5 Update 4 возникла ошибка «Error: Unable get OIB by id ‘f3d18c39-7ff7-4524-b1db-e862719c6230’ «. Ошибка не хотела пропадать даже после создания нового задания. Пришлось обратиться в техническую поддержку Veeam за помощью и вот что они предложили сделать:
1) Выполняем SQL запрос для конфигурационной базы Veeam:
select * FROM [dbo].[Backup.Model.OibsWithAlwaysOnGroups] where oib_id=’f3d18c39-7ff7-4524-b1db-e862719c6230’
должен вывести проблемную точку восстановления
2) Выполняем SQL запрос delete [dbo].[Backup.Model.OibsWithAlwaysOnGroups] where oib_id=’f3d18c39-7ff7-4524-b1db-e862719c6230′ -для удаления проблемной точки восстановления из цепочки.
3) Делаем рескан репозитория, где хранятся резервные копии проблемного задания бекапа и после снова запускаем задание.
После проделанных действий ошибка пропала и бекап снова стал выполняться.

Kerio Connect 9.2 Резервное копирование

В процессе эксплуатация почтового сервера Kerio выяснилось, что резервные копии, который он делает своими скриптами (настроенными из графического интерфейса), хранятся вечно и их нужно самим периодически очищать. То есть получается параметр «число сохраняемых резервных копий» не работает.

Я позвонил в службу поддержки и мне подтвердили, что этот функционал не работает как надо. Не стал уточнять на каких платформах не работает, у меня же почтовый сервер настроен на Debian 8.9 x64. Они посоветовали добавить в Cron скрипт по очистке дискового пространства от старых резервных копий. И вот что получилось:

В файле /etc/crontab добавляем строчку, где добавляется ежедневный запуск скрипта, который ищет в директории с резервными копиями файлы старше 40 дней и удаляет их.

Настройка резервного копирования в Elastix 2.4

Пришел день столкнуться мне с данной АТС и задача была настроить резервное копирование. Заходим в web-интерфейс в System — Backup/Restore и видим скудные настройки.

По-умолчанию система может бекапить ежедневно, еженедельно и ежемесячно, но только в локальную папку «/var/www/backup» Из этой же папки, по-умолчанию, веб-интерфейс отображает список сделанных резервных копий. Можно подключить FTP-сервер, но на него резервные копии переносить надо вручную. Поэтому было решено настроить резервное копирование по NFS на другой сервер. Для этого необходимо:

  1. Настраиваем NFS-сервер. Я его поднимал на Windows. Для этого устанавливаем компонент «Сервер для NFS«, который является частью роли «Файловые службы и службы хранилища»
    После установки роли создаем папку, например, «NFS» и для нее задал права:
    Все сервера вписал по короткому и полным именами, с возможностью чтения и записи и разрешил доступ с правами root. Для всех остальных компьютеров настроен был запрет.
    Что касается настроек NFS для этой папки, то они выглядят так:
  2. Теперь переходим к серверу с Elastix. На нем уже есть NFS-клиент. В терминале выполняем
    mkdir /nfs/
    echo "10.150.1.15:/NFS /nfs/backup nfs defaults 0 0" >> /etc/fstab
    mount -a
    10.150.1.15:/NFS — это NFS-сервер и расшаренная по nfs папка «NFS»
    /nfs/backup — это папка, куда будет подключена по nfs расшаренная папка.
  3. В Elastix в System — Backup/Restore выбираем «Daily» и нажимаем «Set Automatic Backup». После этого в директории  /etc/cron.d/ создастся файл «automatic_backup.cron»

    В моем случае в этом файле изменено время запуска скрипта на 14:27, вы можете поставить свое. Это время ежедневного запуска скрипта.
  4. Переходим к файлу /var/www/backup/automatic_backup.php, в нем на 36 строке изменяем переменную $sBackupDir. Указываем в ней директорию, куда скрипт будет сохранять резервную копию, в нашем случае это /nfs/backup/
  5. В файле /usr/share/elastix/privileged/backupengine в строке 76 меняем директорию по-умолчанию для создания резервных копий.
  6. В терминале я выполнил chmod –R 777 /nfs/иначе без этого в браузере не будет отображаться список сделанных резервных копий.
  7. Теперь настроим, чтобы в административной панели Elastix скрипты искали резервные копии в нужной нам директории, для этого заходим в файл /var/www/html/modules/backup_restore/configs/default.conf.php и в строке 33 меняем директорию
  8. Если нужно, чтобы при запуске резервного копирования через web-интерфейс резервные копии складировались на NFS-шару, то тогда заходим в файл /var/www/html/modules/backup_restore/index.php и в строке 365 изменяем уже знакомую нам переменную на нужную директорию.
  9. Вообщем-то всё. Остался еще момент со временем на сервере. Elastix 2.4 работает на старом Centos 5.10 и в нём используются старые временные зоны для России. Чтобы исправить этот недочет необходимо:
    wget http://people.centos.org/hughesjr/tzdata-2014g-1.el5/i386/RPMS/tzdata-2014g-1.el5.i386.rpm --no-check-certificate
    rpm -Uvh tzdata-2014g-1.el5.i386.rpm
    После этого в файле /etc/php.ini после секции [PHP] прописываем нужную нам временную зону:
    date.timezone = Europe/Samara
    После этого перезапускаем сервис httpd
    service httpd restart
    Теперь в самом Elastix выставляем нужное время и часовой пояс. Заходим в System — Preferences — Date/Time
    На этом всё.