​​Расскажу небольшую историю, которая со мной случилась недавно. Решил основательно настроить Firewall на сервере с MSSQL и отключить вообще всё лишнее. Прям по ip перечислил всех, кому можно обращаться к серверу и его службам. И забыл туда добавить хост с Veeam Backup и Replication.

На заданиях стояли уведомления только в случае ошибок во время бэкапа. Где-то течении недели бэкапы не делались. Заметил проблемы я только когда вручную просматривал сервера с бэкапами. Я делаю это с определённой периодичностью.

После того, как я закрыл доступ к MSSQL серверу, служба Veeam просто остановилась. Мониторинга работы этой службы настроено не было. Бэкапы не делались, уведомления не слались. Со стороны казалось, что всё в порядке.

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

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

#backup #veeam

​​При планирования места, которое потребуется для бэкапов Veeam, можно воспользоваться калькуляторами, которые подскажут примерный занимаемый объём при той или иной схеме бэкапов. Я узнал о них на днях, когда искал решение проблемы с инкрементными бэкапами. В одном из обсуждений увидел ссылку на калькулятор.

Калькуляторов этих два: один старый, другой новый. Старый мне показался более информативным и удобным, так что воспользовался им. Он не только объем подсказывает, но и логику очистки от старых копий при указанном количестве Retention Points и периодичности Synthetic Full Backup. Там не всё очевидно с удалением старых версии. Иногда их копится больше, чем ожидаешь, поэтому стоит прибегать к планированию.

Калькуляторы будут полезны как для пользователей платных Veeam Backup and Replication, так и бесплатных Veeam Agent. У них логика хранения и управления архивными копиями одинаковая.

Напомню, что похожий инструмент есть для бэкапов Proxmox - Prune Simulator. Только он помогает не место рассчитать, а наглядно увидеть, сколько и каких копий будет храниться при той или иной схеме хранения.

#veeam #backup

​​Для бэкапа серверов под управлением Linux существует отличное бесплатное решение - Veeam Agent for Linux FREE. Я очень давно его знаю, но конкретно для Linux давно не пользовался. У меня есть статья по работе с ним:

⇨ Бэкап и перенос linux (centos, debian, ubuntu) сервера с помощью Veeam Agent for Linux

Она написана давно, поэтому я решил проверить, насколько актуален тот метод восстановления, что там описан. Забегая вперёд скажу, что актуален. Изменились некоторые детали, но в основном всё то же самое.

Я себе поставил задачу – перенести виртуальную машину от обычного хостера, где используется стандартная услуга VPS и больше ничего. То есть у вас система на одном жёстком диске заданного размера. Задача перенести её в исходном виде к себе на локальный гипервизор Proxmox. В итоге у меня всё получилось. Рассказываю по шагам, что делал.

1️⃣ Скачал с сайта Veeam файл с репозиторием для Debian veeam-release-deb_1.0.8_amd64.deb и загрузочный ISO для восстановления Veeam Linux Recovery Media. Для загрузки нужна регистрация.

2️⃣ Скопировал файл с репозиторием на целевой сервер и подключил его:
# dpkg -i veeam-release-deb_1.0.8_amd64.deb

3️⃣ Установил veeam и дополнительные пакеты:
# apt install blksnap veeam cifs-utils

4️⃣ К сожалению, понадобилась перезагрузка сервера. Без перезагрузки не создавался бэкап. Veeam ругался, что не загружен модуль для снепшота диска. У меня так и не получилось его загрузить вручную. Вроде всё делал, что надо, но не заработало. Пришлось перезагрузиться и проблема ушла.

5️⃣ Так как на сервере у нас только один диск, мы не можем на него же класть бэкап, когда будем делать образ всей системы. Я решил использовать сетевой smb диск с другой виртуальной машины, которая запущена на целевом Proxmox, куда буду переносить систему. Для этого на ней поднял и настроил ksmbd, затем с помощью ssh настроил VPN туннель между машинами. Всё делал прям по инструкциям из указанных заметок. Заняло буквально 5-10 минут.

6️⃣ Запустил на целевой машине veeam:
# veeam
И с помощью псевдографического интерфейса настроил задание для бэкапа в сетевую папку smb. Там всё просто. Немного затупил с правильностью указания настроек для smb, так как не сразу понял формат, в котором надо записать путь к серверу (на картинке снизу скриншот правильных настроек). Но быстро разобрался. И ещё важный момент. На smb шару у вас должны быть права на запись. Если их нет, получите неинформативную ошибку. Я с этим проковырялся немного, пока не догадался проверить. Оказалось, что забыл дать права на запись в директорию, которая монтировалась по smb.

7️⃣ Запустил задание бэкапа и убедился, что он прошёл без ошибок.

8️⃣ Сделал на Proxmox новую виртуальную машину с диском, у которого размер не меньше исходной машины, которую бэкапили. Это важно. Даже если на диске занято очень мало места, перераспределить его при восстановлении на меньший диск не получится. Veeam просто не умеет этого делать.

9️⃣ Загрузил новую виртуалку с Veeam Linux Recovery Media, подключил туда по smb тот же сетевой диск, куда делал бэкап и успешно выполнил восстановление. Всё прошло без сучка и задоринки. Виртуалка сразу же загрузилась с восстановленного диска и заработала без каких-то дополнительных действий.

Такой вот полезный инструмент. Если локально ещё есть разные варианты, чем забэкапить машину, то с арендованными VPS всё не так просто. Veeam Agent for Linux позволяет из без проблем бэкапить и в случае необходимости восстанавливать локально.

#backup #veeam