Привет! К несчастью, столкнулся с такой особенностью, что когда делаешь бекап не оригинальной виртуальной машины, а ее копии (реплики), то тогда итоговый результат в бекапе будет не вполне тем, что хочешь получить. Бекап будет или частично или полностью недоступен при восстановлении. А все это из-за технологии CBT, которая включена по-умолчанию в заданиях бекапа Veeam и ускоряет процесс создания инкрементного бекапа. В случае бекапа реплики, нужно CBT отключать в настройках задания! А правильнее вариант — сначала делать бекап с боевой виртуальной машины и только после делать реплику, источником которой будут файлы резервной копии, в настройках задания репликации это можно указать в Veeam BR. Информация эта от поддержки Veeam, которая, в свою очередь, ссылается на форум Veeam, где есть об этом информация в виде сообщения от 2010 года 🙂
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 на другой сервер. Для этого необходимо:
- Настраиваем NFS-сервер. Я его поднимал на Windows. Для этого устанавливаем компонент «Сервер для NFS«, который является частью роли «Файловые службы и службы хранилища»
После установки роли создаем папку, например, «NFS» и для нее задал права:
Все сервера вписал по короткому и полным именами, с возможностью чтения и записи и разрешил доступ с правами root. Для всех остальных компьютеров настроен был запрет.
Что касается настроек NFS для этой папки, то они выглядят так:
- Теперь переходим к серверу с 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 расшаренная папка. - В Elastix в System — Backup/Restore выбираем «Daily» и нажимаем «Set Automatic Backup». После этого в директории /etc/cron.d/ создастся файл «automatic_backup.cron»
В моем случае в этом файле изменено время запуска скрипта на 14:27, вы можете поставить свое. Это время ежедневного запуска скрипта. - Переходим к файлу /var/www/backup/automatic_backup.php, в нем на 36 строке изменяем переменную $sBackupDir. Указываем в ней директорию, куда скрипт будет сохранять резервную копию, в нашем случае это /nfs/backup/
- В файле /usr/share/elastix/privileged/backupengine в строке 76 меняем директорию по-умолчанию для создания резервных копий.
- В терминале я выполнил
chmod –R 777 /nfs/иначе без этого в браузере не будет отображаться список сделанных резервных копий. - Теперь настроим, чтобы в административной панели Elastix скрипты искали резервные копии в нужной нам директории, для этого заходим в файл /var/www/html/modules/backup_restore/configs/default.conf.php и в строке 33 меняем директорию
- Если нужно, чтобы при запуске резервного копирования через web-интерфейс резервные копии складировались на NFS-шару, то тогда заходим в файл /var/www/html/modules/backup_restore/index.php и в строке 365 изменяем уже знакомую нам переменную на нужную директорию.
- Вообщем-то всё. Остался еще момент со временем на сервере. 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
На этом всё.
