Расскажу одну историю, которая случилась со мной на днях. Это будет наглядный пример закона подлости и надежды на авось. У меня есть два старых неттопа, которые я время от времени использую. По характеристикам они до сих пор вполне актуальны: i3 cpu + 8GB ram + ssd. Там стоят Windows 10. Один вообще не используется, там чистая настроенная система, второй немного используется и его настройки терять не хочется.
Тот, который используется, бэкапится с помощью Veeam Agent for Windows Free. Архив порядка 100 GB весит. В какой-то момент система начала глючить и периодически виснуть при загрузке. Приходилось систему жёстко выключать, она запускалась снова, проводила какую-то свою диагностику и в итоге загружалась. При этом в журнале ничего информативного. Не понятно, что же не так.
Мне это надоело, решил как-то исправить проблему. Я сразу подумал на железо, поэтому для экономии времени просто перекинул жёсткий диск на второй неттоп. Через некоторое время проблема повторилась. Более того, спустя несколько дней система вообще перестала загружаться, тупо зависая в процессе.
Тогда я почему-то решил, что проблема в жёстком диске, потому что всё остальное я поменял. Взял второй изначально работающий неттоп и решил на него восстановить бэкап нужного. Загрузился с загрузочного диска Veeam, оказалось, что он не видит расшаренные сетевые диски. Пришлось искать внешний диск. Нашёл старый USB-HDD, там USB-2.0. Пару часов копировал на него бэкап.
Подключил диск к системе, начал восстановление бэкапа. При этом бэкапа работающей системы у меня не было. Я перед тем, как начать восстановление, подумал, что наверное неплохо было бы забэкапить чистую систему, чтобы потом не настраивать всё сначала, но поленился.
В итоге, что получилось. Оба неттопа не грузятся. Нет ни чистой работающей системы, ни нужной настроенной. Судя по всему, проблема не в железе, а в самой системе, что я не встречал уже очень давно. Даже не помню, когда у меня окончательно умирала винда. У меня есть бэкап нужной системы, но по факту от него нету толка. При восстановлении из него воспроизводится та же ошибка.
Пока пишу эту заметку, гружу образ винды, буду всё настраивать с нуля. История, как мне кажется, поучительная получилась. Имея как минимум одну работающую систему и бэкап неработающей, я получил две неработающие системы и невозможность воспользоваться бэкапом. По факту систему я потерял. В данном случае это не критично, я потерял только своё время. А вот если в проде такое повториться, то это будет провал.
Причём такие провалы я видел лично, но не по своей вине. Сам я, слава богу 🙏, не сталкивался с этим. Меня привлекали помочь решать проблемы, когда то VM не восстанавливались из бэкапа, то дампы баз данных. Кстати, всегда удавалось решить проблему. У людей просто квалификации не хватало всё сделать правильно, а тренировки они не делали.
❗️Отсюда можно сделать 2 важных коротких вывода:
1️⃣ Надо проверять скорость восстановления бэкапа. В моём случае если бэкап весил бы 500 Гб, то его сутки пришлось бы копировать и восстанавливать.
2️⃣ Бэкапы надо проверять и по возможности хранить как можно бОльшую глубину, так как проблема может появиться очень давно, а проявиться слишком поздно. Если впервые увидели проблемы, сразу сохраните отдельно бэкап ещё рабочей системы.
p.s. Бэкап глючной системы постараюсь починить в виртуалке. Очень интересно узнать, что там случилось. По результатам напишу потом.
#backup
Тот, который используется, бэкапится с помощью Veeam Agent for Windows Free. Архив порядка 100 GB весит. В какой-то момент система начала глючить и периодически виснуть при загрузке. Приходилось систему жёстко выключать, она запускалась снова, проводила какую-то свою диагностику и в итоге загружалась. При этом в журнале ничего информативного. Не понятно, что же не так.
Мне это надоело, решил как-то исправить проблему. Я сразу подумал на железо, поэтому для экономии времени просто перекинул жёсткий диск на второй неттоп. Через некоторое время проблема повторилась. Более того, спустя несколько дней система вообще перестала загружаться, тупо зависая в процессе.
Тогда я почему-то решил, что проблема в жёстком диске, потому что всё остальное я поменял. Взял второй изначально работающий неттоп и решил на него восстановить бэкап нужного. Загрузился с загрузочного диска Veeam, оказалось, что он не видит расшаренные сетевые диски. Пришлось искать внешний диск. Нашёл старый USB-HDD, там USB-2.0. Пару часов копировал на него бэкап.
Подключил диск к системе, начал восстановление бэкапа. При этом бэкапа работающей системы у меня не было. Я перед тем, как начать восстановление, подумал, что наверное неплохо было бы забэкапить чистую систему, чтобы потом не настраивать всё сначала, но поленился.
В итоге, что получилось. Оба неттопа не грузятся. Нет ни чистой работающей системы, ни нужной настроенной. Судя по всему, проблема не в железе, а в самой системе, что я не встречал уже очень давно. Даже не помню, когда у меня окончательно умирала винда. У меня есть бэкап нужной системы, но по факту от него нету толка. При восстановлении из него воспроизводится та же ошибка.
Пока пишу эту заметку, гружу образ винды, буду всё настраивать с нуля. История, как мне кажется, поучительная получилась. Имея как минимум одну работающую систему и бэкап неработающей, я получил две неработающие системы и невозможность воспользоваться бэкапом. По факту систему я потерял. В данном случае это не критично, я потерял только своё время. А вот если в проде такое повториться, то это будет провал.
Причём такие провалы я видел лично, но не по своей вине. Сам я, слава богу 🙏, не сталкивался с этим. Меня привлекали помочь решать проблемы, когда то VM не восстанавливались из бэкапа, то дампы баз данных. Кстати, всегда удавалось решить проблему. У людей просто квалификации не хватало всё сделать правильно, а тренировки они не делали.
❗️Отсюда можно сделать 2 важных коротких вывода:
1️⃣ Надо проверять скорость восстановления бэкапа. В моём случае если бэкап весил бы 500 Гб, то его сутки пришлось бы копировать и восстанавливать.
2️⃣ Бэкапы надо проверять и по возможности хранить как можно бОльшую глубину, так как проблема может появиться очень давно, а проявиться слишком поздно. Если впервые увидели проблемы, сразу сохраните отдельно бэкап ещё рабочей системы.
p.s. Бэкап глючной системы постараюсь починить в виртуалке. Очень интересно узнать, что там случилось. По результатам напишу потом.
#backup
Для бэкапа баз PostgreSQL существует много различных подходов и решений. Я вам хочу предложить ещё одно, отметив его особенности и преимущества. Да и в целом это одна из самых известных программ для этих целей. А в конце приведу список того, чем ещё можно бэкапить PostgreSQL.
Сейчас речь пойдёт об open source продукте pgBackRest. Сразу перечислю основные возможности:
◽умеет бэкапить как локально, так и удалённо, подключаясь по SSH
◽умеет параллелить свою работу и сжимать на ходу с помощью lz4 и zstd, что обеспечивает максимальное быстродействие
◽умеет полные, инкрементные, разностные бэкапы
◽поддерживает локальное и удалённое (в том числе S3) размещение архивов с разными политиками хранения
◽умеет проверять консистентность данных
◽может докачивать бэкапы на том месте, где остановился, а не начинать заново при разрывах связи
Несмотря на то, что продукт довольно старый (написан на C и Perl), он активно поддерживается и обновляется. Плохо только то, что в репозитории нет ни бинарников, ни пакетов. Только исходники, которые предлагается собрать самостоятельно. В целом, это не проблема, так как в Debian и Ubuntu есть уже собранные пакеты в репозиториях, но не самых свежих версий. Свежие придётся самим собирать.
Дальше настройка стандартная для подобных приложений. Рисуете конфиг, где описываете хранилища, указываете объекты для бэкапа, параметры бэкапа и куда складывать логи. Они информативные, можно анализировать при желании.
Подробное описание работы pgBackRest, а так же подходы к созданию резервных копий PostgreSQL и их проверке подробно описаны в ▶️ выступлении Дэвид Стили на PGConf.Online.
❓Чем ещё можно бэкапить PostgreSQL?
🔹pg_dump - встроенная утилита для создания логической копии базы. Подходит только для небольших малонагруженных баз
🔹pg_basebackup - встроенная утилита для создания бинарных бэкапов на уровне файлов всего сервера или кластера. Нельзя делать выборочный бэкап отдельных баз или таблиц.
🔹Barman - наиболее известный продукт для бэкапа PostgreSQL. Тут я могу ошибаться, но по моим представлениям это большой продукт для крупных компаний и нагруженных серверов. Barman размещают на отдельное железо и бэкапаят весь парк своих кластеров. Его часто сравнивают с pgBackrest и выбирают, что лучше.
🔹WAL-G - более молодой продукт по сравнению с Barman и pgBackrest. Написан на GO и поддерживает в том числе MySQL/MariaDB и MS SQL Server. Возможности сопоставимы с первыми двумя, но есть и свои особенности.
Если перед вами стоит задача по бэкапу PostgreSQL, а вы не знаете с чего начать, так как для вас это новая тема, посмотрите выступление с HighLoad++:
▶️ Инструменты создания бэкапов PostgreSQL / Андрей Сальников (Data Egret)
#backup #postgresql
Сейчас речь пойдёт об open source продукте pgBackRest. Сразу перечислю основные возможности:
◽умеет бэкапить как локально, так и удалённо, подключаясь по SSH
◽умеет параллелить свою работу и сжимать на ходу с помощью lz4 и zstd, что обеспечивает максимальное быстродействие
◽умеет полные, инкрементные, разностные бэкапы
◽поддерживает локальное и удалённое (в том числе S3) размещение архивов с разными политиками хранения
◽умеет проверять консистентность данных
◽может докачивать бэкапы на том месте, где остановился, а не начинать заново при разрывах связи
Несмотря на то, что продукт довольно старый (написан на C и Perl), он активно поддерживается и обновляется. Плохо только то, что в репозитории нет ни бинарников, ни пакетов. Только исходники, которые предлагается собрать самостоятельно. В целом, это не проблема, так как в Debian и Ubuntu есть уже собранные пакеты в репозиториях, но не самых свежих версий. Свежие придётся самим собирать.
# apt install pgbackrestДальше настройка стандартная для подобных приложений. Рисуете конфиг, где описываете хранилища, указываете объекты для бэкапа, параметры бэкапа и куда складывать логи. Они информативные, можно анализировать при желании.
Подробное описание работы pgBackRest, а так же подходы к созданию резервных копий PostgreSQL и их проверке подробно описаны в ▶️ выступлении Дэвид Стили на PGConf.Online.
❓Чем ещё можно бэкапить PostgreSQL?
🔹pg_dump - встроенная утилита для создания логической копии базы. Подходит только для небольших малонагруженных баз
🔹pg_basebackup - встроенная утилита для создания бинарных бэкапов на уровне файлов всего сервера или кластера. Нельзя делать выборочный бэкап отдельных баз или таблиц.
🔹Barman - наиболее известный продукт для бэкапа PostgreSQL. Тут я могу ошибаться, но по моим представлениям это большой продукт для крупных компаний и нагруженных серверов. Barman размещают на отдельное железо и бэкапаят весь парк своих кластеров. Его часто сравнивают с pgBackrest и выбирают, что лучше.
🔹WAL-G - более молодой продукт по сравнению с Barman и pgBackrest. Написан на GO и поддерживает в том числе MySQL/MariaDB и MS SQL Server. Возможности сопоставимы с первыми двумя, но есть и свои особенности.
Если перед вами стоит задача по бэкапу PostgreSQL, а вы не знаете с чего начать, так как для вас это новая тема, посмотрите выступление с HighLoad++:
▶️ Инструменты создания бэкапов PostgreSQL / Андрей Сальников (Data Egret)
#backup #postgresql
Если хотите потренироваться и погонять бесплатно S3 хранилище, то у меня есть подходящий сервис для вас с бесплатным тарифным планом - tebi.io. Для регистрации требуется только email, карту не просят. Обещают Free Tier с ограничением на 25 GiB хранилища и 250 GiB исходящего трафика в месяц.
After the Free Trial ends, you can use the Free Tier, or you can switch to a paid subscription.
Я зарегистрировался и погонял этот тариф. Выглядит удобно и функционально. После регистрации вы создаёте новый bucket. Далее заходите в него в режиме редактирования и видите Access key и Secret Key. Они нужны для доступа к хранилищу. Причём доступ этот возможен как по протоколу S3, так и обычному FTP.
Для S3 я взял Rclone и настроил доступ. Достаточно простого конфига:
И можно грузить файлы или директории:
Для FTP нужны только эти данные:
Третий вариант доступа к данным через веб интерфейс личного кабинета. Если у вас есть, к примеру, небольшие сайты, можете добавить это хранилище в качестве дополнительного места хранения бэкапов. Если уже куда-то складываете по S3, то добавить ещё один бакет в качестве приёмника дело пару минут. А в самом бакете можно настроить политику хранения, чтобы гарантированно не вылезти из лимита 25 GiB. А то ещё заставят деньги платить.
А в целом, это неплохая возможность хотя бы посмотреть, как всё это работает, если не знакомы. Тут полный набор стандартных возможностей типичного S3 хранилища: acl, api, lifecycle, policy, datastream.
📌 Полезные ссылки по теме:
▪ S3 (Simple Storage Service) — плюсы и минусы
▪ Софт для бэкапов в S3
▪ Подключение S3 бакета в качестве диска
▪ Свой S3 сервер на базе MiniO
#беслпатно #S3 #backup
After the Free Trial ends, you can use the Free Tier, or you can switch to a paid subscription.
Я зарегистрировался и погонял этот тариф. Выглядит удобно и функционально. После регистрации вы создаёте новый bucket. Далее заходите в него в режиме редактирования и видите Access key и Secret Key. Они нужны для доступа к хранилищу. Причём доступ этот возможен как по протоколу S3, так и обычному FTP.
Для S3 я взял Rclone и настроил доступ. Достаточно простого конфига:
[tebi]type = s3provider = Otheraccess_key_id = uo5csfdErtydmaYsecret_access_key = vCFkX9pR785VNyt6Qf1zFJokqTBUFYuHrVX58yOmendpoint = https://s3.tebi.io/acl = privateИ можно грузить файлы или директории:
# rclone sync -i testfile.exe tebi:bucket_nameДля FTP нужны только эти данные:
server: ftp.tebi.ioport: 21login: uo5csfdErtydmaYpassword: vCFkX9pR785VNyt6Qf1zFJokqTBUFYuHrVX58yOmТретий вариант доступа к данным через веб интерфейс личного кабинета. Если у вас есть, к примеру, небольшие сайты, можете добавить это хранилище в качестве дополнительного места хранения бэкапов. Если уже куда-то складываете по S3, то добавить ещё один бакет в качестве приёмника дело пару минут. А в самом бакете можно настроить политику хранения, чтобы гарантированно не вылезти из лимита 25 GiB. А то ещё заставят деньги платить.
А в целом, это неплохая возможность хотя бы посмотреть, как всё это работает, если не знакомы. Тут полный набор стандартных возможностей типичного S3 хранилища: acl, api, lifecycle, policy, datastream.
📌 Полезные ссылки по теме:
▪ S3 (Simple Storage Service) — плюсы и минусы
▪ Софт для бэкапов в S3
▪ Подключение S3 бакета в качестве диска
▪ Свой S3 сервер на базе MiniO
#беслпатно #S3 #backup
Недавно один человек у меня попросил совета по поводу программы для бэкапов в Linux на базе rsync, но только чтобы была полноценная поддержка инкрементных архивов, чтобы можно было вернуться назад на заданный день. Я знаю, что базовыми возможностями rsync без костылей и скриптов такое не сделать, поэтому сразу вспомнил про программу rdiff-backup. Хотел скинуть ссылку на свою заметку, но с удивлением обнаружил, что я вообще ни разу про неё не писал, хотя сам лично использовал.
Rdiff-backup по своей сути является python обёрткой вокруг rsync (используется библиотека librsync). Она наследует всю скорость и быстроту синхронизации сотен тысяч файлов, которую обеспечивает rsync. Если нужны бэкапы сырых файлов, без упаковки в архивы, дедупликации, сжатия и т.д., то я всегда предпочитаю использовать именно rsync. С ним быстрее и проще всего получить точную пофайловую копию какого-то файлового хранилища, которое регулярно синхронизируется. Это идеальный инструмент для организации горячего резерва файлового архива. В случае выхода из строя основного сервера или хранилища с файлами, можно очень быстро подмонтировать или организовать подключение копии, создаваемой с помощью rsync.
Особенно это актуально для почтовых серверов с форматом хранения maildir. Там каждое письмо это отдельный файл. В итоге файловое хранилище превращается в сотни тысяч мелких файлов, которые один раз скопировать может и не проблема, но каждый день актуализировать копию уже не так просто, так как надо сравнить источник и приёмник, где с каждой стороны огромное количество файлов и они меняются. По моему опыту, rsync это делает быстрее всех. Я даже на Windows сервера ставлю rsync и бэкаплю большие файловые хранилища с его помощью.
Возвращаюсь к Rdiff-backup. Он расширяет возможности rsync, позволяя очень быстро организовать полноценные инкрементные бэкапы, используя технологию hard link. Установить программу можно из стандартного репозитория Debian:
Если надо просто сделать копию каких-то данных, то не нужны никакие настройки и ключи. Просто копируем:
Удалённое резервное копирование по SSH с сервера hostname на локальный бэкап-сервер:
Добавляя ключи
Если между первым и вторым запуском бэкапа набор файлов менялся, то в локальной директории
Вы увидите наборы инкрементов и даты, когда они были созданы. С этими инкрементами можно некоторым образом работать. Например, можно посмотреть, какие файлы изменились за последние 5 дней:
Или посмотреть список файлов, которые присутствовали в архиве 5 дней назад. Если список большой, то сразу выводите его в файл и там просматривайте, ищите нужный файл:
Ну и так далее. Подробное описание с примерами есть в документации. Главное, идея понятна. Все изменения от инкремента к инкременту хранятся и их можно анализировать.
Восстановление по сути представляет из себя обычное копирование файлов из актуальной копии. Это если вам нужно взять свежие данные от последней синхронизации. Если же вам нужно восстановиться из какого-то инкремента, то укажите его явно:
Программа простая и функциональная. Рекомендую 👍.
⇨ Сайт / Исходники
Похожие программы, которые тоже используют librsync:
▪ Burp
▪ Duplicity
▪ Csync2
#backup
Rdiff-backup по своей сути является python обёрткой вокруг rsync (используется библиотека librsync). Она наследует всю скорость и быстроту синхронизации сотен тысяч файлов, которую обеспечивает rsync. Если нужны бэкапы сырых файлов, без упаковки в архивы, дедупликации, сжатия и т.д., то я всегда предпочитаю использовать именно rsync. С ним быстрее и проще всего получить точную пофайловую копию какого-то файлового хранилища, которое регулярно синхронизируется. Это идеальный инструмент для организации горячего резерва файлового архива. В случае выхода из строя основного сервера или хранилища с файлами, можно очень быстро подмонтировать или организовать подключение копии, создаваемой с помощью rsync.
Особенно это актуально для почтовых серверов с форматом хранения maildir. Там каждое письмо это отдельный файл. В итоге файловое хранилище превращается в сотни тысяч мелких файлов, которые один раз скопировать может и не проблема, но каждый день актуализировать копию уже не так просто, так как надо сравнить источник и приёмник, где с каждой стороны огромное количество файлов и они меняются. По моему опыту, rsync это делает быстрее всех. Я даже на Windows сервера ставлю rsync и бэкаплю большие файловые хранилища с его помощью.
Возвращаюсь к Rdiff-backup. Он расширяет возможности rsync, позволяя очень быстро организовать полноценные инкрементные бэкапы, используя технологию hard link. Установить программу можно из стандартного репозитория Debian:
# apt install rdiff-backupЕсли надо просто сделать копию каких-то данных, то не нужны никакие настройки и ключи. Просто копируем:
# rdiff-backup /var/www/site.ru/ /backup/site.ru/Удалённое резервное копирование по SSH с сервера hostname на локальный бэкап-сервер:
# rdiff-backup user@hostname::/remote-dir local-dirДобавляя ключи
-v5 и --print-statistics вы можете получать подробную информацию о процессе бэкапа, которую потом удобно парсить, отправлять на хранение, мониторить. Если между первым и вторым запуском бэкапа набор файлов менялся, то в локальной директории
local-dir будет лежать самая последняя копия файлов. А кроме этого в ней же будет находиться директория rdiff-backup-data, которая будет содержать информацию и логи о проводимых бэкапах, а также инкременты, необходимые для отката на любой прошлый выполненный бэкап. Посмотреть инкременты можно вот так:# rdiff-backup -l local-dirВы увидите наборы инкрементов и даты, когда они были созданы. С этими инкрементами можно некоторым образом работать. Например, можно посмотреть, какие файлы изменились за последние 5 дней:
# rdiff-backup list files --changed-since 5D local-dirИли посмотреть список файлов, которые присутствовали в архиве 5 дней назад. Если список большой, то сразу выводите его в файл и там просматривайте, ищите нужный файл:
# rdiff-backup list files --at 5D local-dirНу и так далее. Подробное описание с примерами есть в документации. Главное, идея понятна. Все изменения от инкремента к инкременту хранятся и их можно анализировать.
Восстановление по сути представляет из себя обычное копирование файлов из актуальной копии. Это если вам нужно взять свежие данные от последней синхронизации. Если же вам нужно восстановиться из какого-то инкремента, то укажите его явно:
# rdiff-backup restore \local-dir/rdiff-backup-data/increments.2023-10-29T21:03:37+03:00.dir \/tmp/restoreПрограмма простая и функциональная. Рекомендую 👍.
⇨ Сайт / Исходники
Похожие программы, которые тоже используют librsync:
▪ Burp
▪ Duplicity
▪ Csync2
#backup
Я обновил популярную подборку со своего сайта:
⇨ Топ бесплатных программ для бэкапа
Обновил не в плане актуализировал все описания, а просто дополнил статью всеми программами, что были упомянуты в моём канале. Я не представляю, как эту подборку можно актуализировать. Слишком хлопотно всё это перепроверять и обновлять описания.
Даже в таком виде статья информативна. Если подбираете себе бесплатный инструмент для бэкапа, то подборка поможет быстро сориентироваться в том, что есть, посмотреть алгоритмы, основные возможности, поддерживаемые платформы, наличие веб интерфейса и т.д.
Плюс, к каждому продукту есть ссылка на обсуждение в Telegram канале, где есть в том числе отзывы и рекомендации от тех, кто пользовался. Именно поэтому я прошу не флудить в комментариях и не превращать чат в болталку. Иногда удаляю то, что считаю бесполезным для читателей (мемы, картинки, ссоры и т.д.), чтобы не занимать зря их время и внимание.
Если считаете, что какой-то полезной программы не хватает, пишите в комментариях здесь или на сайте. Я буду дополнять. В этом обновлении добавил туда ElkarBackup, FBackup. Почему-то их там не было. До этого добавлял ReaR и Restic, но анонса не делал.
#backup #подборка
⇨ Топ бесплатных программ для бэкапа
Обновил не в плане актуализировал все описания, а просто дополнил статью всеми программами, что были упомянуты в моём канале. Я не представляю, как эту подборку можно актуализировать. Слишком хлопотно всё это перепроверять и обновлять описания.
Даже в таком виде статья информативна. Если подбираете себе бесплатный инструмент для бэкапа, то подборка поможет быстро сориентироваться в том, что есть, посмотреть алгоритмы, основные возможности, поддерживаемые платформы, наличие веб интерфейса и т.д.
Плюс, к каждому продукту есть ссылка на обсуждение в Telegram канале, где есть в том числе отзывы и рекомендации от тех, кто пользовался. Именно поэтому я прошу не флудить в комментариях и не превращать чат в болталку. Иногда удаляю то, что считаю бесполезным для читателей (мемы, картинки, ссоры и т.д.), чтобы не занимать зря их время и внимание.
Если считаете, что какой-то полезной программы не хватает, пишите в комментариях здесь или на сайте. Я буду дополнять. В этом обновлении добавил туда ElkarBackup, FBackup. Почему-то их там не было. До этого добавлял ReaR и Restic, но анонса не делал.
#backup #подборка
Server Admin
Топ 12 бесплатных программ для бэкапа | serveradmin.ru
Подборка бесплатных программ для бэкапа. Краткое описание, возможности, отзывы реальных людей об использовании.
Не так давно я рассказывал про простую и надёжную систему для бэкапов - rdiff-backup на базе rsync. Система хорошая, сам её использовал. Один из читателей поделился информацией про продукт Minarca. Это клиент-серверное приложение с веб интерфейсом на основе rdiff-backup. Я его установил и немного потетисровал. Понравилась идея и реализация.
Установить сервер очень просто. Для DEB дистрибутивов есть репозитории. На Debian ставим так:
И всё, можно идти в веб интерфейс на порт 8080. Учётка по умолчанию:
Для того, чтобы что-то забэкапить, надо скачать и установить агента. Есть версия под Windows, Linux, MacOS. Можно всех бэкапить под одной учёткой, либо под разными. Дальше будет понятно, в чём отличие. Устанавливаем клиента, указываем адрес сервера, логин, пароль.
Приложение очень простое. Выбираем что бэкапим на уровне файлов и каталогов, задаём расписание и запускаем бэкап. Когда он будет закончен, на сервере в веб интерфейсе вы увидите репозиторий этого агента и информацию по бэкапам. Там же можно посмотреть файлы.
Восстановление можно сделать как с сервера с помощью админской учётки, так и с клиента под его собственной учёткой. То есть у каждого клиента может быть доступ к своим бэкапам, если он знает учётную запись, под которой эти бэкапы делались. На сервере можно настроить политику хранения бэкапа для каждого репозитория, посмотреть статистику, настроить уведомления. Есть графики, логи.
Каких-то особенных возможностей нет, но в базе по бэкапам есть всё необходимое. При желании, можно настроить 2FA и спрятать сервис за прокси. Отмечу ещё раз, что под капотом там rdiff-backup, соответственно, все возможности по хранению там те же: бэкап только на уровне файлов, дедупликации, бэкапа дисков и всей системы нет. Хранятся инкрементные бэкапы в экономичном формате с помощью линуксовых hard links. Репозитроий для хранения - обычная директория Linux на сервере. По умолчанию -
Мне система понравилась. Не знаю, что там по надёжности и удобству использования. Это надо попользоваться, чтобы понять. Больше всего понравилось то, что можно легко дать пользователям доступ к бэкапам. А также ежедневные или еженедельные отчёты по бэкапам, которые можно настроить в уведомлениях.
⇨ Сайт / Исходники / Demo / Видеообзор
#backup
Установить сервер очень просто. Для DEB дистрибутивов есть репозитории. На Debian ставим так:
# curl -L https://www.ikus-soft.com/archive/minarca/public.key | gpg --dearmor > /usr/share/keyrings/minarca-keyring.gpg# echo "deb [arch=amd64 signed-by=/usr/share/keyrings/minarca-keyring.gpg] https://nexus.ikus-soft.com/repository/apt-release-$(lsb_release -sc)/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/minarca.list# apt update# apt install minarca-serverИ всё, можно идти в веб интерфейс на порт 8080. Учётка по умолчанию:
admin / admin123. Для того, чтобы что-то забэкапить, надо скачать и установить агента. Есть версия под Windows, Linux, MacOS. Можно всех бэкапить под одной учёткой, либо под разными. Дальше будет понятно, в чём отличие. Устанавливаем клиента, указываем адрес сервера, логин, пароль.
Приложение очень простое. Выбираем что бэкапим на уровне файлов и каталогов, задаём расписание и запускаем бэкап. Когда он будет закончен, на сервере в веб интерфейсе вы увидите репозиторий этого агента и информацию по бэкапам. Там же можно посмотреть файлы.
Восстановление можно сделать как с сервера с помощью админской учётки, так и с клиента под его собственной учёткой. То есть у каждого клиента может быть доступ к своим бэкапам, если он знает учётную запись, под которой эти бэкапы делались. На сервере можно настроить политику хранения бэкапа для каждого репозитория, посмотреть статистику, настроить уведомления. Есть графики, логи.
Каких-то особенных возможностей нет, но в базе по бэкапам есть всё необходимое. При желании, можно настроить 2FA и спрятать сервис за прокси. Отмечу ещё раз, что под капотом там rdiff-backup, соответственно, все возможности по хранению там те же: бэкап только на уровне файлов, дедупликации, бэкапа дисков и всей системы нет. Хранятся инкрементные бэкапы в экономичном формате с помощью линуксовых hard links. Репозитроий для хранения - обычная директория Linux на сервере. По умолчанию -
/backups.Мне система понравилась. Не знаю, что там по надёжности и удобству использования. Это надо попользоваться, чтобы понять. Больше всего понравилось то, что можно легко дать пользователям доступ к бэкапам. А также ежедневные или еженедельные отчёты по бэкапам, которые можно настроить в уведомлениях.
⇨ Сайт / Исходники / Demo / Видеообзор
#backup
До появления Proxmox Backup Server я часто отдавал предпочтение при выборе гипервизора Hyper-V из-за того, что для Proxmox VE не было функционального инструмента для бэкапов VM, кроме его встроенного средства, которое делало только полные бэкапы.
С выходом PBS этот вопрос был закрыт, причём бескомпромиссно. Предложенное решение было лучше, чем любое другое бесплатное. Так что связка Proxmox VE + PBS аналогов сейчас не имеет по удобству, простоте настройки и эксплуатации.
Отдельно отметить и рассказать более подробно я хочу про Proxmox Backup Client. Это консольная утилита для Linux, которая позволяет делать бэкап на уровне файлов из виртуальной машины в PBS, даже если система находится на другом гипервизоре. То есть это полностью отвязанный от инфраструктуры Proxmox клиент, который позволяет складывать резервные копии в PBS. Таким образом этот сервер бэкапов может объединять в себе разнородную инфраструктуру.
Сразу перечислю основные ограничения этого клиента:
▪ бэкап только на уровне файлов или образов дисков, не системы целиком;
▪ официальная поддержка только deb дистрибутивов, для rpm люди сами собирают пакеты, так как исходники открыты;
▪ нет поддержки windows, вариант бэкапа данных оттуда только один - монтирование диска по smb к linux машине и бэкап этого примонтированного диска.
Использовать proxmox-backup-client очень просто. Я не буду подробно описывать его возможности, так как в оригинальной документации представлена исчерпывающая информация. Если хочется на русском, то можно обратиться к документации от altlinux. Кратко покажу пример установки и бэкапа.
Ставим Proxmox Backup Client на Debian:
Вставляем туда для Debian 12
Для Debian 11:
Для Debian 10:
Ставим клиента:
Теперь бэкапим корень сервера без примонтированных дисков. То есть делаем бэкап системы:
Здесь мы указали:
◽root.pxar - имя архива в формате pbs
◽/ - бэкапим корень системы
◽10.20.1.47 - адрес pbs сервера
◽main - имя datastore
По умолчанию используется учётная запись root@pam, то есть дефолтный админ. Разумеется, на проде так делать не надо, потому что у него полные права, в том числе на удаление архивов. Делайте отдельные учётки для разных систем с ограниченными правами. В PBS это организовано удобно и просто, так что разобраться не трудно. Для указания имени пользователя, нужно использовать такой вид репозитория:
Для того, чтобы не вводить пароль пользователя вручную, можно задать его через переменную окружения
Смотреть содержимое бэкапов можно как через веб интерфейс, так и тут локально. Причём бэкап можно примонтировать через fuse. Сморим снэпшоты и выбираем любой для монтирования:
Очень быстро и удобно. При желании бэкапы можно шифровать.
#proxmox #backup
С выходом PBS этот вопрос был закрыт, причём бескомпромиссно. Предложенное решение было лучше, чем любое другое бесплатное. Так что связка Proxmox VE + PBS аналогов сейчас не имеет по удобству, простоте настройки и эксплуатации.
Отдельно отметить и рассказать более подробно я хочу про Proxmox Backup Client. Это консольная утилита для Linux, которая позволяет делать бэкап на уровне файлов из виртуальной машины в PBS, даже если система находится на другом гипервизоре. То есть это полностью отвязанный от инфраструктуры Proxmox клиент, который позволяет складывать резервные копии в PBS. Таким образом этот сервер бэкапов может объединять в себе разнородную инфраструктуру.
Сразу перечислю основные ограничения этого клиента:
▪ бэкап только на уровне файлов или образов дисков, не системы целиком;
▪ официальная поддержка только deb дистрибутивов, для rpm люди сами собирают пакеты, так как исходники открыты;
▪ нет поддержки windows, вариант бэкапа данных оттуда только один - монтирование диска по smb к linux машине и бэкап этого примонтированного диска.
Использовать proxmox-backup-client очень просто. Я не буду подробно описывать его возможности, так как в оригинальной документации представлена исчерпывающая информация. Если хочется на русском, то можно обратиться к документации от altlinux. Кратко покажу пример установки и бэкапа.
Ставим Proxmox Backup Client на Debian:
# wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg# mcedit /etc/apt/sources.list.d/pbs-client.listВставляем туда для Debian 12
deb http://download.proxmox.com/debian/pbs-client bookworm mainДля Debian 11:
deb http://download.proxmox.com/debian/pbs-client bullseye mainДля Debian 10:
deb http://download.proxmox.com/debian/pbs-client buster mainСтавим клиента:
# apt update && apt install proxmox-backup-clientТеперь бэкапим корень сервера без примонтированных дисков. То есть делаем бэкап системы:
# proxmox-backup-client backup root.pxar:/ --repository 10.20.1.47:mainЗдесь мы указали:
◽root.pxar - имя архива в формате pbs
◽/ - бэкапим корень системы
◽10.20.1.47 - адрес pbs сервера
◽main - имя datastore
По умолчанию используется учётная запись root@pam, то есть дефолтный админ. Разумеется, на проде так делать не надо, потому что у него полные права, в том числе на удаление архивов. Делайте отдельные учётки для разных систем с ограниченными правами. В PBS это организовано удобно и просто, так что разобраться не трудно. Для указания имени пользователя, нужно использовать такой вид репозитория:
user01@pbs@10.20.1.47. То есть мы указали созданного вручную пользователя user01@pbs.Для того, чтобы не вводить пароль пользователя вручную, можно задать его через переменную окружения
PBS_PASSWORD. Смотреть содержимое бэкапов можно как через веб интерфейс, так и тут локально. Причём бэкап можно примонтировать через fuse. Сморим снэпшоты и выбираем любой для монтирования:
# proxmox-backup-client snapshot list --repository 10.20.1.47:main# proxmox-backup-client mount host/debian12-vm/2024-02-06T19:19:12Z root.pxar --repository 10.20.1.47:main /mnt/backupОчень быстро и удобно. При желании бэкапы можно шифровать.
#proxmox #backup
Яндекс.Диск – одно из самых дешёвых файловых хранилищ. При этом с хорошей скоростью. У него есть полнофункциональный Linux клиент, который умеет работать только в консоли. Его без проблем можно установить на сервер без gui и складывать туда бэкапы.
Установить его просто, так как есть репозиторий под это дело:
После этого запускаете:
Дальше следуете указаниям мастера, проходите авторизацию устройства, указываете директорию, которая будет синхронизироваться с диском. После этого все файлы, положенные в эту директорию, будут синхронизироваться с облаком.
При работе таким образом важно понимать нюансы. Нельзя бэкапы держать только на Яндекс.Диске. Если у него будет сбой и повредятся или пропадут файлы, то и у вас они пропадут, так как синхронизация двусторонняя. Я лично с таким сталкивался. Так что это в первую очередь холодное хранение одной из копий. Нельзя полагаться только на неё. И хотя фактически данные хранятся в двух местах – у вас на диске и в облаке. Потеряете и там, и тут, если не предпримете отдельных действий.
Второй нюанс в том, что все синхронизируемые данные лежат и на сервере, и на диске. А на сервере зачастую нет большого количества свободного места, так как оно тоже денег стоит, особенно если он арендуется. Из этой ситуации можно выйти, отправляя файлы напрямую в диск через API, без родного клиента. Это умеет делать rclone, либо можно самостоятельно передавать туда файлы с помощью простейшего bash скрипта.
Я не раз видел отзывы, что у Яндекс.Диска плохая скорость. Вот конкретно в Москве никогда такого не наблюдал. Он канал до 100 мегабит спокойно утилизирует весь. Я им пользуюсь постоянно, проверял не единожды. Так что могу смело его рекомендовать с поправкой на то, что данные там могут быть утеряны. Ну а где этого не может случиться? Везде можно потерять, поэтому храните несколько копий.
И ещё такой момент. Сам Яндекс через техподдержку всегда говорит, что максимальную скорость гарантирует только при использовании родного клиента. Все остальные способы доступа к файлам работают как получится. Возможно в каких-то случаях скорость сознательно урезается. С webdav это точно происходит.
#backup
Установить его просто, так как есть репозиторий под это дело:
# echo "deb http://repo.yandex.ru/yandex-disk/deb/ stable main" | tee -a /etc/apt/sources.list.d/yandex-disk.list > /dev/null# wget http://repo.yandex.ru/yandex-disk/YANDEX-DISK-KEY.GPG -O- | apt-key add - # apt update && apt install yandex-diskПосле этого запускаете:
# yandex-disk setupДальше следуете указаниям мастера, проходите авторизацию устройства, указываете директорию, которая будет синхронизироваться с диском. После этого все файлы, положенные в эту директорию, будут синхронизироваться с облаком.
При работе таким образом важно понимать нюансы. Нельзя бэкапы держать только на Яндекс.Диске. Если у него будет сбой и повредятся или пропадут файлы, то и у вас они пропадут, так как синхронизация двусторонняя. Я лично с таким сталкивался. Так что это в первую очередь холодное хранение одной из копий. Нельзя полагаться только на неё. И хотя фактически данные хранятся в двух местах – у вас на диске и в облаке. Потеряете и там, и тут, если не предпримете отдельных действий.
Второй нюанс в том, что все синхронизируемые данные лежат и на сервере, и на диске. А на сервере зачастую нет большого количества свободного места, так как оно тоже денег стоит, особенно если он арендуется. Из этой ситуации можно выйти, отправляя файлы напрямую в диск через API, без родного клиента. Это умеет делать rclone, либо можно самостоятельно передавать туда файлы с помощью простейшего bash скрипта.
Я не раз видел отзывы, что у Яндекс.Диска плохая скорость. Вот конкретно в Москве никогда такого не наблюдал. Он канал до 100 мегабит спокойно утилизирует весь. Я им пользуюсь постоянно, проверял не единожды. Так что могу смело его рекомендовать с поправкой на то, что данные там могут быть утеряны. Ну а где этого не может случиться? Везде можно потерять, поэтому храните несколько копий.
И ещё такой момент. Сам Яндекс через техподдержку всегда говорит, что максимальную скорость гарантирует только при использовании родного клиента. Все остальные способы доступа к файлам работают как получится. Возможно в каких-то случаях скорость сознательно урезается. С webdav это точно происходит.
#backup
На днях триггер в Zabbix сработал на то, что дамп Mysql базы не создался. Это бывает редко, давно его не видел. Решил по этому поводу рассказать, как у меня устроена проверка создания дампов с контролем этого процесса через Zabbix. Здесь будет только теория в общих словах. Пример реализации описан у меня в статье:
⇨ https://serveradmin.ru/nastrojka-mysqldump-proverka-i-monitoring-bekapov-mysql/
Она старя, что-то уже переделывалась, но общий смысл примерно тот же. К сожалению, нет времени обновлять и актуализировать статьи. Да и просмотров там не очень много. Тема узкая, не очень популярная. Хотя как по мне, без мониторинга этих дампов просто нельзя. Можно годами не знать, что у тебя дампы битые, если хотя бы не проверять их создание.
Описание ниже будет актуально для любых текстовых дампов sql серверов. Как минимум, один и тот же подход я применяю как к Mysql, так и Postgresql.
1️⃣ В любом дампе sql обычно есть служебные строки в начале и в конце. Для Mysql это обычно в начале
2️⃣ Если строки есть, пишу в отдельный лог файл что-то типа
3️⃣ В Zabbix настраиваю отдельный шаблон, где в айтем забираю этот лог. И делаю для него триггер, что если есть слово corrupted, то срабатывает триггер.
Вот и всё. Если срабатывает триггер, иду на сервер и смотрю результат работы дампа. Я его тоже в отдельный файл сохраняю. Можно и его забирать в Zabbix, но я не вижу большого смысла в этой информации, чтобы забивать ей базу заббикса.
В логе увидел ошибку:
Не знаю, с чем она была связана. Проверил лог mysql в это время, там тоже ошибка:
Проверил таблицу, там всё в порядке:
Следующий дамп прошёл уже без ошибок, так что я просто забил. Если повторится, буду разбираться детальнее.
Делать такую проверку можно как угодно. Я люблю всё замыкать на Zabbix, а он уже шлёт уведомления. Можно в скрипте с проверкой сразу отправлять информацию на почту, и, к примеру, мониторить почтовый ящик. Если кто-то тоже мониторит создание дампов, то расскажите, как это делаете вы.
Ну и не забываем, что это только мониторинг создания. Даже если не было ошибок, это ещё не гарантия того, что дамп реально рабочий, хотя лично я ни разу не сталкивался с тем, что корректно созданный дамп не восстанавливается.
Тем не менее, восстановление я тоже проверяю. Тут уже могут быть различные реализации в зависимости от инфраструктуры. Самый более ли менее приближённый к реальности вариант такой. Копируете этот дамп вместе с бэкапом исходников на запасной веб сервер, там скриптами разворачиваете и проверяете тем же Zabbix, что развёрнутый из бэкапов сайт работает и актуален по свежести. Пример, как это может выглядеть, я когда-то тоже описывал в старой статье.
#mysql #backup
⇨ https://serveradmin.ru/nastrojka-mysqldump-proverka-i-monitoring-bekapov-mysql/
Она старя, что-то уже переделывалась, но общий смысл примерно тот же. К сожалению, нет времени обновлять и актуализировать статьи. Да и просмотров там не очень много. Тема узкая, не очень популярная. Хотя как по мне, без мониторинга этих дампов просто нельзя. Можно годами не знать, что у тебя дампы битые, если хотя бы не проверять их создание.
Описание ниже будет актуально для любых текстовых дампов sql серверов. Как минимум, один и тот же подход я применяю как к Mysql, так и Postgresql.
1️⃣ В любом дампе sql обычно есть служебные строки в начале и в конце. Для Mysql это обычно в начале
-- MySQL dump и в конце -- Dump completed. После создания дампа я банальным grep проверяю, что там эти строки есть. 2️⃣ Если строки есть, пишу в отдельный лог файл что-то типа
${BASE01} backup is OK, если хоть одной строки нет, то ${BASE01} backup is corrupted.3️⃣ В Zabbix настраиваю отдельный шаблон, где в айтем забираю этот лог. И делаю для него триггер, что если есть слово corrupted, то срабатывает триггер.
Вот и всё. Если срабатывает триггер, иду на сервер и смотрю результат работы дампа. Я его тоже в отдельный файл сохраняю. Можно и его забирать в Zabbix, но я не вижу большого смысла в этой информации, чтобы забивать ей базу заббикса.
В логе увидел ошибку:
mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `b_stat_session_data` at row: 1479887Не знаю, с чем она была связана. Проверил лог mysql в это время, там тоже ошибка:
Aborted connection 1290694 to db: 'db01' user: 'user01' host: 'localhost' (Got timeout writing communication packets)Проверил таблицу, там всё в порядке:
> check table b_stat_session_data;Следующий дамп прошёл уже без ошибок, так что я просто забил. Если повторится, буду разбираться детальнее.
Делать такую проверку можно как угодно. Я люблю всё замыкать на Zabbix, а он уже шлёт уведомления. Можно в скрипте с проверкой сразу отправлять информацию на почту, и, к примеру, мониторить почтовый ящик. Если кто-то тоже мониторит создание дампов, то расскажите, как это делаете вы.
Ну и не забываем, что это только мониторинг создания. Даже если не было ошибок, это ещё не гарантия того, что дамп реально рабочий, хотя лично я ни разу не сталкивался с тем, что корректно созданный дамп не восстанавливается.
Тем не менее, восстановление я тоже проверяю. Тут уже могут быть различные реализации в зависимости от инфраструктуры. Самый более ли менее приближённый к реальности вариант такой. Копируете этот дамп вместе с бэкапом исходников на запасной веб сервер, там скриптами разворачиваете и проверяете тем же Zabbix, что развёрнутый из бэкапов сайт работает и актуален по свежести. Пример, как это может выглядеть, я когда-то тоже описывал в старой статье.
#mysql #backup
Server Admin
Настройка mysqldump, проверка и мониторинг бэкапов mysql |...
Создание и проверка бэкапов MySQL с помощью mysqldump. Мониторинг бэкапов в Zabbix с уведомлением об ошибках создания.
Для бэкапа серверов под управлением 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️⃣ Скопировал файл с репозиторием на целевой сервер и подключил его:
3️⃣ Установил veeam и дополнительные пакеты:
4️⃣ К сожалению, понадобилась перезагрузка сервера. Без перезагрузки не создавался бэкап. Veeam ругался, что не загружен модуль для снепшота диска. У меня так и не получилось его загрузить вручную. Вроде всё делал, что надо, но не заработало. Пришлось перезагрузиться и проблема ушла.
5️⃣ Так как на сервере у нас только один диск, мы не можем на него же класть бэкап, когда будем делать образ всей системы. Я решил использовать сетевой smb диск с другой виртуальной машины, которая запущена на целевом Proxmox, куда буду переносить систему. Для этого на ней поднял и настроил ksmbd, затем с помощью ssh настроил VPN туннель между машинами. Всё делал прям по инструкциям из указанных заметок. Заняло буквально 5-10 минут.
6️⃣ Запустил на целевой машине veeam:
И с помощью псевдографического интерфейса настроил задание для бэкапа в сетевую папку smb. Там всё просто. Немного затупил с правильностью указания настроек для smb, так как не сразу понял формат, в котором надо записать путь к серверу (на картинке снизу скриншот правильных настроек). Но быстро разобрался. И ещё важный момент. На smb шару у вас должны быть права на запись. Если их нет, получите неинформативную ошибку. Я с этим проковырялся немного, пока не догадался проверить. Оказалось, что забыл дать права на запись в директорию, которая монтировалась по smb.
7️⃣ Запустил задание бэкапа и убедился, что он прошёл без ошибок.
8️⃣ Сделал на Proxmox новую виртуальную машину с диском, у которого размер не меньше исходной машины, которую бэкапили. Это важно. Даже если на диске занято очень мало места, перераспределить его при восстановлении на меньший диск не получится. Veeam просто не умеет этого делать.
9️⃣ Загрузил новую виртуалку с Veeam Linux Recovery Media, подключил туда по smb тот же сетевой диск, куда делал бэкап и успешно выполнил восстановление. Всё прошло без сучка и задоринки. Виртуалка сразу же загрузилась с восстановленного диска и заработала без каких-то дополнительных действий.
Такой вот полезный инструмент. Если локально ещё есть разные варианты, чем забэкапить машину, то с арендованными VPS всё не так просто. Veeam Agent for Linux позволяет из без проблем бэкапить и в случае необходимости восстанавливать локально.
#backup #veeam
⇨ Бэкап и перенос 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.deb3️⃣ Установил veeam и дополнительные пакеты:
# apt install blksnap veeam cifs-utils4️⃣ К сожалению, понадобилась перезагрузка сервера. Без перезагрузки не создавался бэкап. 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
Примерно 3 года назад я рассказывал про хороший инструмент для бэкапа - Kopia. Это бесплатная кросс-платформенная система для бэкапов с управлением через веб интерфейс. С тех пор вышло много обновлений, продукт активно развивается и обрастает возможностями. Решил написать о нём ещё раз, чтобы напомнить и рассказать тем, кто не знаком с ним.
📌 Кратко перечислю основные возможности Kopia:
▪️ Кросс-платформенная система как на уровне агентов, так и сервера. Вы можете развернуть сервер с веб интерфейсом как на Linux, так и Windows или macOS. И бэкапить туда все поддерживаемые системы.
▪️ Поддержка различных бэкендов для организации архива с бэкапами. Даже если чего-то не хватает, то в качестве транспорта может выступать rclone, который поддерживает вообще всё, что только можно.
▪️ Есть в том числе поддержка CLI (консольного интерфейса), что позволяет очень гибко с помощью ключей задавать преднастройки для процесса архивирования.
▪️ Очень гибкая система хранения и управления бэкапами с помощью политик.
▪️ Веб интерфейс для настройки бэкапов и доступа к данным. При желании, можно всё делать через него. В консоль ходить не обязательно. Но при этом все настройки, сделанные в веб интерфейсе можно экспортировать в json конфиги и консольные ключи.
🔥 Поддержка инкрементных бэкапов, дедупликации, сжатия.
▪️ Есть возможность проводить регулярные проверки бэкапов на целостность.
▪️ В последний релиз завезли поддержку Volume Shadow Copy Service (VSS) под Windows.
▪️ Всё это написано на GO и работает быстро.
❗️Сразу отмечу, что Kopia делает бэкапы только на уровне файлов и каталогов. Сделать образ диска или бэкап всей системы разом с ней не получится.
У Kopia немного необычная архитектура и принцип работы. Сейчас кратко расскажу, как там всё устроено. Клиент и сервер по сути одно и то же. Это всё один бинарник. Поставить в Debian можно так:
Далее вы можете все конфиги подготовить заранее и запустить бинарник с нужными параметрами. Но так как мы используем этот продукт впервые, то запустим веб интерфейс и всё настроим там. А потом уже заберём готовые конфиги для других серверов.
Запустили kopia в режиме веб интерфейса. Идём на http://10.20.1.36:51515 и логинимся под указанной учёткой. Сразу добавляем репозиторий для хранения бэкапов. Например, локальную директорию
После того, как мы настроили репозиторий и параметры бэкапа, его конфиг сохранился в
Будет создан очередной снэпшот директории. Посмотреть его можно будет в том числе через веб интерфейс.
Теперь мы можем установить kopia на любую другую машину. Если мы захотим складывать её бэкапы на тот же сервер, где мы ранее настроили репозиторий, то на него они будут попадать уже по sftp. Для этого можно так же запустить на новой машине веб интерфейс и добавить репозиторий уже не локальный, а sftp и указать параметры подключения по ssh. И далее так же делать снепшоты либо через веб интерфейс, либо локальной командой, которую можно запускать через cron или systemd.
При описанной схеме, все клиенты имеют полный доступ к репозиторию с бэкапами. Это самая простая настройка. Чтобы доступ ограничивать через acl, можно поднять Repository Server и подключаться через него.
⇨ Сайт / Исходники
#backup
📌 Кратко перечислю основные возможности Kopia:
▪️ Кросс-платформенная система как на уровне агентов, так и сервера. Вы можете развернуть сервер с веб интерфейсом как на Linux, так и Windows или macOS. И бэкапить туда все поддерживаемые системы.
▪️ Поддержка различных бэкендов для организации архива с бэкапами. Даже если чего-то не хватает, то в качестве транспорта может выступать rclone, который поддерживает вообще всё, что только можно.
▪️ Есть в том числе поддержка CLI (консольного интерфейса), что позволяет очень гибко с помощью ключей задавать преднастройки для процесса архивирования.
▪️ Очень гибкая система хранения и управления бэкапами с помощью политик.
▪️ Веб интерфейс для настройки бэкапов и доступа к данным. При желании, можно всё делать через него. В консоль ходить не обязательно. Но при этом все настройки, сделанные в веб интерфейсе можно экспортировать в json конфиги и консольные ключи.
🔥 Поддержка инкрементных бэкапов, дедупликации, сжатия.
▪️ Есть возможность проводить регулярные проверки бэкапов на целостность.
▪️ В последний релиз завезли поддержку Volume Shadow Copy Service (VSS) под Windows.
▪️ Всё это написано на GO и работает быстро.
❗️Сразу отмечу, что Kopia делает бэкапы только на уровне файлов и каталогов. Сделать образ диска или бэкап всей системы разом с ней не получится.
У Kopia немного необычная архитектура и принцип работы. Сейчас кратко расскажу, как там всё устроено. Клиент и сервер по сути одно и то же. Это всё один бинарник. Поставить в Debian можно так:
# curl -s https://kopia.io/signing-key \| gpg --dearmor -o /etc/apt/keyrings/kopia-keyring.gpg# echo "deb [signed-by=/etc/apt/keyrings/kopia-keyring.gpg] \ http://packages.kopia.io/apt/ stable main" \| tee /etc/apt/sources.list.d/kopia.list# apt update# apt install kopiaДалее вы можете все конфиги подготовить заранее и запустить бинарник с нужными параметрами. Но так как мы используем этот продукт впервые, то запустим веб интерфейс и всё настроим там. А потом уже заберём готовые конфиги для других серверов.
# kopia server start --insecure --address="http://10.20.1.36:51515" \--server-username="kopia" --server-password=kopiaЗапустили kopia в режиме веб интерфейса. Идём на http://10.20.1.36:51515 и логинимся под указанной учёткой. Сразу добавляем репозиторий для хранения бэкапов. Например, локальную директорию
/mnt/backup. После этого в разделе Snapshots мы можем добавить любой локальный каталог в качестве источника бэкапа. И там же через веб интерфейс настроить параметры бэкапа и политики хранения. Они сохранятся в репозитории. После того, как мы настроили репозиторий и параметры бэкапа, его конфиг сохранился в
/root/.config/kopia/repository.config. Теперь мы можем просто запускать команду для бэкапа в консоли. Примерно так для директории /var/log:# kopia snapshot create /var/logБудет создан очередной снэпшот директории. Посмотреть его можно будет в том числе через веб интерфейс.
Теперь мы можем установить kopia на любую другую машину. Если мы захотим складывать её бэкапы на тот же сервер, где мы ранее настроили репозиторий, то на него они будут попадать уже по sftp. Для этого можно так же запустить на новой машине веб интерфейс и добавить репозиторий уже не локальный, а sftp и указать параметры подключения по ssh. И далее так же делать снепшоты либо через веб интерфейс, либо локальной командой, которую можно запускать через cron или systemd.
При описанной схеме, все клиенты имеют полный доступ к репозиторию с бэкапами. Это самая простая настройка. Чтобы доступ ограничивать через acl, можно поднять Repository Server и подключаться через него.
⇨ Сайт / Исходники
#backup
Максимально простой и быстрый способ перенести без остановки ОС Linux на другое железо или виртуальную машину. Не понадобится ничего, кроме встроенных средств. Проверял лично и не раз. Перед написанием этой заметки тоже проверил.
Допустим, у вас система виртуальной машины установлена на /dev/sda. Там, соответственно, будет три раздела: boot, корень и swap. Нам надо эту систему перенести куда-то в другое место. Желательно на однотипное железо, чтобы не возникло проблем. Если железо будет другое, то тоже реально, но нужно будет немного заморочиться и выполнить дополнительные действия. Заранее их все не опишешь, так как это сильно зависит от конкретной ситуации. Скорее всего придётся внутри системы что-то править (сеть, точки монтирования) и пересобрать initrd.
Создаём где-то новую виртуальную машину с таким же диском. Загружаемся с любого загрузочного диска. Например, с SystemRescue. Настраиваем в этой системе сеть, чтобы виртуальная машина, которую переносим, могла сюда подключиться. Запускаем сервер SSH. Не забываем открыть порты в файрволе. В SystemRescue он по умолчанию включен и всё закрыто на вход.
Идём на виртуалку, которую будем переносить. И делаем там простой трюк:
Мы с помощью dd читаем устройство
Процесс будет длительный, так как передача получается посекторная. Нужно понимать, что если машина большая и нагруженная, то в момент передачи целостность данных нарушается. Какую-нибудь СУБД так не перенести. Я лично не пробовал, но подозреваю, что с большой долей вероятности база будет битая. А вот обычный не сильно нагруженный сервер вполне.
После переноса он скорее всего ругнётся на ошибки файловой системы при загрузке, но сам себя починит с очень большой долей вероятности. Я как-то раз пытался так перенести виртуалку на несколько сотен гигабайт. Вот это не получилось. Содержимое судя по всему сильно билось по дороге, так как виртуалка не останавливалась. Не удалось её запустить. А что-то небольшое на 20-30 Гб вполне нормально переносится. Можно так виртуалку от какого-то хостера себе локально перенести. Главное сетевую связность между ними организовать.
Если по сети нет возможности передать образ, то можно сохранить его в файл, если есть доступный носитель:
Потом копируем образ и восстанавливаем из него систему:
Делаем всё это с какого-то загрузочного диска.
Напомню, что перенос системы можно выполнить и с помощью специально предназначенного для этого софта:
▪️ ReaR
▪️ Veeam Agent for Linux FREE
▪️ Clonezilla
#linux #backup
Допустим, у вас система виртуальной машины установлена на /dev/sda. Там, соответственно, будет три раздела: boot, корень и swap. Нам надо эту систему перенести куда-то в другое место. Желательно на однотипное железо, чтобы не возникло проблем. Если железо будет другое, то тоже реально, но нужно будет немного заморочиться и выполнить дополнительные действия. Заранее их все не опишешь, так как это сильно зависит от конкретной ситуации. Скорее всего придётся внутри системы что-то править (сеть, точки монтирования) и пересобрать initrd.
Создаём где-то новую виртуальную машину с таким же диском. Загружаемся с любого загрузочного диска. Например, с SystemRescue. Настраиваем в этой системе сеть, чтобы виртуальная машина, которую переносим, могла сюда подключиться. Запускаем сервер SSH. Не забываем открыть порты в файрволе. В SystemRescue он по умолчанию включен и всё закрыто на вход.
Идём на виртуалку, которую будем переносить. И делаем там простой трюк:
# dd if=/dev/sda | ssh root@10.20.1.28 "dd of=/dev/sda"Мы с помощью dd читаем устройство
/dev/sda и передаём его содержимое по ssh на другую машину такой же утилите dd, которая пишет информацию в устройство /dev/sda уже на другой машине. Удобство такого переноса в том, что не нужен промежуточный носитель для хранения образа. Всё передаётся налету. Процесс будет длительный, так как передача получается посекторная. Нужно понимать, что если машина большая и нагруженная, то в момент передачи целостность данных нарушается. Какую-нибудь СУБД так не перенести. Я лично не пробовал, но подозреваю, что с большой долей вероятности база будет битая. А вот обычный не сильно нагруженный сервер вполне.
После переноса он скорее всего ругнётся на ошибки файловой системы при загрузке, но сам себя починит с очень большой долей вероятности. Я как-то раз пытался так перенести виртуалку на несколько сотен гигабайт. Вот это не получилось. Содержимое судя по всему сильно билось по дороге, так как виртуалка не останавливалась. Не удалось её запустить. А что-то небольшое на 20-30 Гб вполне нормально переносится. Можно так виртуалку от какого-то хостера себе локально перенести. Главное сетевую связность между ними организовать.
Если по сети нет возможности передать образ, то можно сохранить его в файл, если есть доступный носитель:
# dd if=/dev/sda of=/mnt/backup/sda.imgПотом копируем образ и восстанавливаем из него систему:
# dd if=/mnt/backup/sda.img of=/dev/sdaДелаем всё это с какого-то загрузочного диска.
Напомню, что перенос системы можно выполнить и с помощью специально предназначенного для этого софта:
▪️ ReaR
▪️ Veeam Agent for Linux FREE
▪️ Clonezilla
#linux #backup
Существует много консольных инструментов для настройки бэкапов. Наиболее популярные и функциональные restic и borg. Сегодня я расскажу про ещё один, который я недавно внедрил на один веб сервер, так что в конце приведу полные конфиги для полноценного использования.
Речь пойдёт про старый и относительно известный инструмент nxs-backup от компании Nixys. Я знаю его давно. Если не ошибаюсь, то сначала это был просто bash скрипт, потом его упаковали в пакеты. А где-то год назад его полностью переписали и теперь это бинарник на Go.
📌 Основные возможности nxs-backup:
🔹Полные и инкрементные бэкапы на уровне файлов.
🔹Бэкапы СУБД MySQL/PostgreSQL как дампом, так и бинарные.
🔹Бэкапы MongoDB и Redis.
🔹В качестве бэкенда для передачи и хранения может использоваться: S3, SSH (SFTP), FTP, CIFS (SMB), NFS, WebDAV.
🔹Уведомления по email, Telegram, Slack или любой webhook.
Теперь отдельно расскажу, что хорошего и полезного есть конкретно в этой программе, так как список возможностей типичный для подобных программ.
➕Простые конфиги в формате yaml для заданий + одиночный бинарник. Удобно масштабировать и использовать одни и те же настройки на различных проектах. Работает одинаково без зависимостей и пересборки практически на всех Linux.
➕Из предыдущего пункта вытекает удобство использования в контейнерах. В конфиги можно передавать переменные, что упрощает настройку и позволяет не хранить секреты в конфигах. Бонусом будет очень маленький образ с самим nxs-backup, если он будет запускаться отдельно.
➕Возможность гибкой настройки логов и уведомлений. Я сделал хранение полного лога в текстовом файле локально, который легко анализировать и куда-то в общее хранилище передавать. А оповещения об ошибках и предупреждениях отдельно отправляю в Telegram.
➕Бэкап на уровне файлов делается простым tar. На базе его же возможностей организованы инкрементные бэкапы. То есть файлы хранятся в исходном виде, а восстановление возможно самостоятельно без использования nxs-backup. Кому-то это покажется минусом, но лично я больше люблю хранение в таком виде. Да, нет дедупликации, но меньше шансов получить поврежденные данные в случае каких-то проблем.
➕В едином формате конфигов описываются задания для бэкапа файлов и баз. Закрываются базовые потребности одной программой. Не надо дампить или делать бинарные бэкапы каким-то отдельным инструментом.
➕Удобно настроить одновременно локальное хранение бэкапов и отправку в S3. Я обычно это сам костылю скриптами.
➕Есть Helm чарт для использования в Kubernetes.
☝ Сразу отмечу явные минусы:
➖Нет встроенного шифрования.
➖Не очень удобно мониторить. По сути есть только логи и уведомления.
➖Документация так себе. Пришлось поковыряться, хоть в итоге всё и получилось, как задумал.
В целом, получилось неплохо. Я потратил время и создал для себя универсальные конфиги, которые буду использовать. Для интегратора или аутсорсера, кто занимается поддержкой серверов, это удобное решение. Собственно, оно для этих целей и писалось, чтобы закрыть внутренние потребности.
Установка:
Подготовка основного конфига в
⇨ nxs-backup.conf
Конфиг с заданием для бэкапа файлов
⇨ site01-files.conf
Конфиг с заданием для бэкапа БД
⇨ site01-mysql.conf
Проверяем конфигурацию:
Если есть ошибки, увидите их. Если нет, то запускаем бэкап:
У меня успешно создаётся локальный бэкап и одновременно с ним отправляется в S3 Селектела. Соответственно, политика хранения бэкапов указана. Nxs-backup будет автоматически складывать по указанной структуре бэкапы и удалять старые.
Продукт интересный. Кто занимается подобными вещами, рекомендую обратить внимание.
⇨ Сайт / Исходники
#backup
Речь пойдёт про старый и относительно известный инструмент nxs-backup от компании Nixys. Я знаю его давно. Если не ошибаюсь, то сначала это был просто bash скрипт, потом его упаковали в пакеты. А где-то год назад его полностью переписали и теперь это бинарник на Go.
📌 Основные возможности nxs-backup:
🔹Полные и инкрементные бэкапы на уровне файлов.
🔹Бэкапы СУБД MySQL/PostgreSQL как дампом, так и бинарные.
🔹Бэкапы MongoDB и Redis.
🔹В качестве бэкенда для передачи и хранения может использоваться: S3, SSH (SFTP), FTP, CIFS (SMB), NFS, WebDAV.
🔹Уведомления по email, Telegram, Slack или любой webhook.
Теперь отдельно расскажу, что хорошего и полезного есть конкретно в этой программе, так как список возможностей типичный для подобных программ.
➕Простые конфиги в формате yaml для заданий + одиночный бинарник. Удобно масштабировать и использовать одни и те же настройки на различных проектах. Работает одинаково без зависимостей и пересборки практически на всех Linux.
➕Из предыдущего пункта вытекает удобство использования в контейнерах. В конфиги можно передавать переменные, что упрощает настройку и позволяет не хранить секреты в конфигах. Бонусом будет очень маленький образ с самим nxs-backup, если он будет запускаться отдельно.
➕Возможность гибкой настройки логов и уведомлений. Я сделал хранение полного лога в текстовом файле локально, который легко анализировать и куда-то в общее хранилище передавать. А оповещения об ошибках и предупреждениях отдельно отправляю в Telegram.
➕Бэкап на уровне файлов делается простым tar. На базе его же возможностей организованы инкрементные бэкапы. То есть файлы хранятся в исходном виде, а восстановление возможно самостоятельно без использования nxs-backup. Кому-то это покажется минусом, но лично я больше люблю хранение в таком виде. Да, нет дедупликации, но меньше шансов получить поврежденные данные в случае каких-то проблем.
➕В едином формате конфигов описываются задания для бэкапа файлов и баз. Закрываются базовые потребности одной программой. Не надо дампить или делать бинарные бэкапы каким-то отдельным инструментом.
➕Удобно настроить одновременно локальное хранение бэкапов и отправку в S3. Я обычно это сам костылю скриптами.
➕Есть Helm чарт для использования в Kubernetes.
☝ Сразу отмечу явные минусы:
➖Нет встроенного шифрования.
➖Не очень удобно мониторить. По сути есть только логи и уведомления.
➖Документация так себе. Пришлось поковыряться, хоть в итоге всё и получилось, как задумал.
В целом, получилось неплохо. Я потратил время и создал для себя универсальные конфиги, которые буду использовать. Для интегратора или аутсорсера, кто занимается поддержкой серверов, это удобное решение. Собственно, оно для этих целей и писалось, чтобы закрыть внутренние потребности.
Установка:
# curl -L https://github.com/nixys/nxs-backup/releases/latest/download/nxs-backup-amd64.tar.gz -o /tmp/nxs-backup.tar.gz# tar xf /tmp/nxs-backup.tar.gz -C /tmp# mv /tmp/nxs-backup /usr/sbin/nxs-backupПодготовка основного конфига в
/etc/nxs-backup/nxs-backup.conf:⇨ nxs-backup.conf
Конфиг с заданием для бэкапа файлов
/etc/nxs-backup/conf.d/site01-files.conf:⇨ site01-files.conf
Конфиг с заданием для бэкапа БД
/etc/nxs-backup/conf.d/site01-mysql.conf:⇨ site01-mysql.conf
Проверяем конфигурацию:
# nxs-backup -tЕсли есть ошибки, увидите их. Если нет, то запускаем бэкап:
# nxs-backup start allУ меня успешно создаётся локальный бэкап и одновременно с ним отправляется в S3 Селектела. Соответственно, политика хранения бэкапов указана. Nxs-backup будет автоматически складывать по указанной структуре бэкапы и удалять старые.
Продукт интересный. Кто занимается подобными вещами, рекомендую обратить внимание.
⇨ Сайт / Исходники
#backup
Дам несколько советов по организации структуры бэкапов на основе своего опыта. На всякий случай напомню, что у меня не обучающий канал. Я не ставлю себе цели выверить информацию, дать максимально подробно и правильно, чтобы вы смогли повторить за мной. Я делюсь своими знаниями, какие они есть. Специально к публикациям не готовлюсь, в основном пишу экспромтом.
Существуют два принципиально разных подхода к созданию бэкапов:
1️⃣ На целевые сервера с данными устанавливаются какие-то агенты единой системы или самостоятельный софт для подготовки и передачи бэкапов в какое-то хранилище. У этого подхода есть несколько плюсов.
➕ Основной - можно локально задавать политики хранения и ротации бэкапов. Не нужен какой-то единый центр управления для этого, а в качестве бэкенда хранения достаточно будет любого сетевого хранилища, куда можно просто складывать данные. Например, хранилище на базе протокола S3. Сейчас это очень распространённые хранилища.
➕ Второе преимущество - достаточно настроить только доступ к хранилищу бэкапов. К самим серверам со стороны хранения доступ настраивать не обязательно. Это актуально в сильно распределённой системе.
➖ Основной минус такого подхода - если скомпрометируют сервер, то злоумышленники могут с него уничтожить и бэкапы. Вероятность такого развития событий не такая уж и маленькая. Некоторые злоумышленники этим промышляют. Сначала каким-то образом в автоматическом режиме получают доступы к серверам, а потом уже руками туда заходят и начинают разбираться, как там всё устроено. Если получают доступ к бэкапам, то шифруют их тоже. Я знаю такие истории.
В таком режиме можно настроить бэкапы с помощью nxs-backup, restic, borg и многих других консольных программ из мира Linux. Получается максимально дёшево и эффективно.
2️⃣ Другой подход - это когда вы имеете сервер для бэкапов, который сам ходит по целевым машинам и забирает с них данные.
➖ Сразу скажу очевидный минус. Сервер бэкапов должен иметь прямой доступ к серверам с данными. Иногда это бывает хлопотно организовать. Иметь где-то во внешней площадке сервер с бэкапами, куда есть доступ у всех целевых серверов проще, чем сделать с внешней площадки доступ ко всем серверам с данными, особенно если они разрозненно находятся.
➖ Второй момент. Для такой схемы недостаточно просто купить какое-то хранилище с доступом по S3, SMB, NFS и т.д. Это должен быть полноценный сервер.
➕ Плюс тут тоже очевиден - это более безопасный способ хранения бэкапов, так как с целевых серверов нет доступа к архивам. При этом сам сервер с бэкапами на целевые сервера может иметь доступ только на чтение. Даже если он будет скомпрометирован, уничтожить исходные данные не получится. Проще всего такое хранение организовать с помощью rsync и доступа по ssh. Создаём на сервере бэкапов ключ, на серверы с данными добавляем учётку с аутентификацией по этому ключу и забираем данные по ssh. Подойдёт любой софт, который умеет забирать данные по ssh. Как я уже сказал rsync, unison, Butterfly Backup, rsnapshot, ElkarBackup, BackupPC, Burp и т.д.
Только первую схему лично я никогда не использую. Идеально их совмещать, либо использовать только вторую.
Для первой схемы есть возможность себя обезопасить. Например, можно использовать в качестве хранилища S3. В правах доступа к бакету запретить возможность удаления данных. А чтобы обеспечить ротацию архивов, настроить политику удаления старых данных средствами хранилища S3. Я активно применяю такую схему. Делаю 3 бакета: day, week, month. В первом данные хранятся 7 дней, во втором 4 недели, в третьем вечно. Получается дёшево и безопасно.
Более масштабные системы типа Veeam, PBS, Vinchin и т.д. используют оба метода - там и центральный сервер с политиками хранения, и агенты на хостах. Компрометация хостов с агентами не ведёт к потере резервных копий. Разумеется, если в самой серверной части нет уязвимостей. А они иногда бывают. В этом плане вторая схема со скрытием от посторонних глаз сервера с бэкапами наиболее безопасная.
#backup
Существуют два принципиально разных подхода к созданию бэкапов:
1️⃣ На целевые сервера с данными устанавливаются какие-то агенты единой системы или самостоятельный софт для подготовки и передачи бэкапов в какое-то хранилище. У этого подхода есть несколько плюсов.
➕ Основной - можно локально задавать политики хранения и ротации бэкапов. Не нужен какой-то единый центр управления для этого, а в качестве бэкенда хранения достаточно будет любого сетевого хранилища, куда можно просто складывать данные. Например, хранилище на базе протокола S3. Сейчас это очень распространённые хранилища.
➕ Второе преимущество - достаточно настроить только доступ к хранилищу бэкапов. К самим серверам со стороны хранения доступ настраивать не обязательно. Это актуально в сильно распределённой системе.
➖ Основной минус такого подхода - если скомпрометируют сервер, то злоумышленники могут с него уничтожить и бэкапы. Вероятность такого развития событий не такая уж и маленькая. Некоторые злоумышленники этим промышляют. Сначала каким-то образом в автоматическом режиме получают доступы к серверам, а потом уже руками туда заходят и начинают разбираться, как там всё устроено. Если получают доступ к бэкапам, то шифруют их тоже. Я знаю такие истории.
В таком режиме можно настроить бэкапы с помощью nxs-backup, restic, borg и многих других консольных программ из мира Linux. Получается максимально дёшево и эффективно.
2️⃣ Другой подход - это когда вы имеете сервер для бэкапов, который сам ходит по целевым машинам и забирает с них данные.
➖ Сразу скажу очевидный минус. Сервер бэкапов должен иметь прямой доступ к серверам с данными. Иногда это бывает хлопотно организовать. Иметь где-то во внешней площадке сервер с бэкапами, куда есть доступ у всех целевых серверов проще, чем сделать с внешней площадки доступ ко всем серверам с данными, особенно если они разрозненно находятся.
➖ Второй момент. Для такой схемы недостаточно просто купить какое-то хранилище с доступом по S3, SMB, NFS и т.д. Это должен быть полноценный сервер.
➕ Плюс тут тоже очевиден - это более безопасный способ хранения бэкапов, так как с целевых серверов нет доступа к архивам. При этом сам сервер с бэкапами на целевые сервера может иметь доступ только на чтение. Даже если он будет скомпрометирован, уничтожить исходные данные не получится. Проще всего такое хранение организовать с помощью rsync и доступа по ssh. Создаём на сервере бэкапов ключ, на серверы с данными добавляем учётку с аутентификацией по этому ключу и забираем данные по ssh. Подойдёт любой софт, который умеет забирать данные по ssh. Как я уже сказал rsync, unison, Butterfly Backup, rsnapshot, ElkarBackup, BackupPC, Burp и т.д.
Только первую схему лично я никогда не использую. Идеально их совмещать, либо использовать только вторую.
Для первой схемы есть возможность себя обезопасить. Например, можно использовать в качестве хранилища S3. В правах доступа к бакету запретить возможность удаления данных. А чтобы обеспечить ротацию архивов, настроить политику удаления старых данных средствами хранилища S3. Я активно применяю такую схему. Делаю 3 бакета: day, week, month. В первом данные хранятся 7 дней, во втором 4 недели, в третьем вечно. Получается дёшево и безопасно.
Более масштабные системы типа Veeam, PBS, Vinchin и т.д. используют оба метода - там и центральный сервер с политиками хранения, и агенты на хостах. Компрометация хостов с агентами не ведёт к потере резервных копий. Разумеется, если в самой серверной части нет уязвимостей. А они иногда бывают. В этом плане вторая схема со скрытием от посторонних глаз сервера с бэкапами наиболее безопасная.
#backup
Продолжу тему про бэкапы. Бэкап может считаться полноценным, когда он не только сделан и сохранён в нескольких местах, но и успешно восстановлен. Помимо технических моментов, важно учесть и юридические. Сразу остановлюсь на этом моменте.
1️⃣ Нельзя все бэкапы хранить у одного хостера или юридического лица, даже если они географически разнесены. Кажется, что вероятность проблем по этой части не очень велика. На деле я сталкивался с подобным не раз. То собственники делят или захватывают бизнес и вырубают вообще всю инфраструктуру, то по ошибке блокируют учётную запись и невозможно продлить услугу, то ещё что-нибудь. Это важный момент. На него надо обращать внимание.
2️⃣ Большая тема про восстановление. Я на практике знаю, что мало кто реально восстанавливается на постоянной основе из бэкапов и проверяет их. Может в большом бизнесе так где-то и делают, но в малом и среднем почти никогда. Надо понимать, что это стоит денег в виде рабочих часов специалистов и железа под это дело, зачастую в том же объёме, что и рабочий прод. Если оно арендное, то расходы ещё более заметны.
В этом плане мне очень нравится софт от Veeam. Из-за него я долго пользовался HyperV и очень жду, когда он заработает под KVM. Veeam, помимо непосредственно бэкапов, предлагает готовые инструменты для их проверок. База, которую я старался делать всегда - автоматическое ежедневное разворачивание образов виртуалок на запасных серверах. Только когда это реализовано, я могу спать спокойно и быть уверенным, что всё в порядке. И обязательно каждый день отчёт на почту с информацией о бэкапах и восстановлении. Читаю их глазами и проверяю, если что-то не так.
Этот подход даёт много плюсов. Во-первых, бэкапы реально восстанавливаются. Во-вторых, у вас всегда под рукой копия вашего прода не в виде сырых данных, а работающих систем, в том числе связанных между собой сетью. Там есть отдельное решение для работы сети без изменений в системах и доступа к ним. Я иногда их использую, чтобы просто что-то проверить на копии системы. Под это дело обычно использую старые сервера, с которых уехал прод на новые. В случае проблем можно оперативно переключиться на запасной сервер.
Если нет Veeam, то восстановление и проверка реализуются скриптами и костылями по месту в зависимости от обстоятельств. У меня были и статьи, и заметки по этим темам, но всё уже устарело и не обновлялось, поэтому не привожу.
3️⃣ Отдельно отмечу момент со скоростью восстановления. Если не делать восстановление, то невозможно наверняка знать, сколько этот процесс будет длиться. Бэкапы на удалённой площадке могут восстанавливаться и неделю, и две. Они идут по ночам инкрементами и скорости хватает. А полное восстановление может длиться сутками. Это может оказаться неприемлемым.
У меня была такая площадка с большим объёмом данных. Был согласованный план - если что случается, едет водитель и забирает сервер, куда все бэкапы восстанавливаются каждый день. Это были полные бэкапы систем, чтобы можно было взять, привезти сервер и запустить. Важно это проработать.
Когда дело доходит до бэкапов, ситуация хреновая. Это стресс. Если только данные под рукой, то нужно оперативно решать кучу моментов с восстановлением и настройкой систем. Я этим тоже занимался и могу сказать, что лучше не заниматься. Стараюсь, чтобы системы были. Не всегда получается организовать полностью бэкап виртуалок. Тогда делаю системные диски небольшими, бэкаплю их. А сырые данные отдельно.
Знакомый рассказывал историю, когда держал большой объём данных на каком-то очень дешёвом хранилище AWS. А когда нужно было восстановить оттуда данные, оказалось, что быстро это сделать невозможно. И денег стоит совсем других, не как хранение.
4️⃣ Не давайте никому без особой надобности доступ к бэкапам. Особенно каким-то подрядчикам или новым сотрудникам. У меня иногда просят, но тут я непреклонен. Никому не даю, только если руководитель или собственник распорядится. Но ни разу никто после моих доводов не давал таких распоряжений.
#backup
1️⃣ Нельзя все бэкапы хранить у одного хостера или юридического лица, даже если они географически разнесены. Кажется, что вероятность проблем по этой части не очень велика. На деле я сталкивался с подобным не раз. То собственники делят или захватывают бизнес и вырубают вообще всю инфраструктуру, то по ошибке блокируют учётную запись и невозможно продлить услугу, то ещё что-нибудь. Это важный момент. На него надо обращать внимание.
2️⃣ Большая тема про восстановление. Я на практике знаю, что мало кто реально восстанавливается на постоянной основе из бэкапов и проверяет их. Может в большом бизнесе так где-то и делают, но в малом и среднем почти никогда. Надо понимать, что это стоит денег в виде рабочих часов специалистов и железа под это дело, зачастую в том же объёме, что и рабочий прод. Если оно арендное, то расходы ещё более заметны.
В этом плане мне очень нравится софт от Veeam. Из-за него я долго пользовался HyperV и очень жду, когда он заработает под KVM. Veeam, помимо непосредственно бэкапов, предлагает готовые инструменты для их проверок. База, которую я старался делать всегда - автоматическое ежедневное разворачивание образов виртуалок на запасных серверах. Только когда это реализовано, я могу спать спокойно и быть уверенным, что всё в порядке. И обязательно каждый день отчёт на почту с информацией о бэкапах и восстановлении. Читаю их глазами и проверяю, если что-то не так.
Этот подход даёт много плюсов. Во-первых, бэкапы реально восстанавливаются. Во-вторых, у вас всегда под рукой копия вашего прода не в виде сырых данных, а работающих систем, в том числе связанных между собой сетью. Там есть отдельное решение для работы сети без изменений в системах и доступа к ним. Я иногда их использую, чтобы просто что-то проверить на копии системы. Под это дело обычно использую старые сервера, с которых уехал прод на новые. В случае проблем можно оперативно переключиться на запасной сервер.
Если нет Veeam, то восстановление и проверка реализуются скриптами и костылями по месту в зависимости от обстоятельств. У меня были и статьи, и заметки по этим темам, но всё уже устарело и не обновлялось, поэтому не привожу.
3️⃣ Отдельно отмечу момент со скоростью восстановления. Если не делать восстановление, то невозможно наверняка знать, сколько этот процесс будет длиться. Бэкапы на удалённой площадке могут восстанавливаться и неделю, и две. Они идут по ночам инкрементами и скорости хватает. А полное восстановление может длиться сутками. Это может оказаться неприемлемым.
У меня была такая площадка с большим объёмом данных. Был согласованный план - если что случается, едет водитель и забирает сервер, куда все бэкапы восстанавливаются каждый день. Это были полные бэкапы систем, чтобы можно было взять, привезти сервер и запустить. Важно это проработать.
Когда дело доходит до бэкапов, ситуация хреновая. Это стресс. Если только данные под рукой, то нужно оперативно решать кучу моментов с восстановлением и настройкой систем. Я этим тоже занимался и могу сказать, что лучше не заниматься. Стараюсь, чтобы системы были. Не всегда получается организовать полностью бэкап виртуалок. Тогда делаю системные диски небольшими, бэкаплю их. А сырые данные отдельно.
Знакомый рассказывал историю, когда держал большой объём данных на каком-то очень дешёвом хранилище AWS. А когда нужно было восстановить оттуда данные, оказалось, что быстро это сделать невозможно. И денег стоит совсем других, не как хранение.
4️⃣ Не давайте никому без особой надобности доступ к бэкапам. Особенно каким-то подрядчикам или новым сотрудникам. У меня иногда просят, но тут я непреклонен. Никому не даю, только если руководитель или собственник распорядится. Но ни разу никто после моих доводов не давал таких распоряжений.
#backup
Расскажу для тех, кто не знает. Есть отечественная система для бэкапов RuBackup. Я про неё узнал ещё года 1,5 назад. Меня пригласили на какую-то конференцию, где про неё и другие отечественные решения для бэкапа рассказывали. Я послушал, мне в целом понравилось, но руки так и не дошли попробовать.
Там внушительные возможности по функциональности. KVM и, в частности, Proxmox, тоже поддерживается. Есть бесплатная версия без существенных ограничений, но для бэкапов объёмом суммарно до 1ТБ уже после дедупликации. Понятно, что для прода это очень мало, но для личных нужд или теста вполне достаточно.
Сразу скажу, что сам с этой системой не работал. Хотел поставить и попробовать, поэтому и заметку не писал так долго, но руки так и не дошли. И, наверное, не дойдут, поэтому решил написать. Это не реклама, у меня никто эту заметку не заказывал.
Если кто-то пользовался, покупал, внедрял, поделитесь, пожалуйста, впечатлением.
Пока писал заметку, полазил по сайту и увидел, что срок действия бесплатной лицензии - 1 год 🤦 Зачем так делать, я не понимаю. Раньше этого ограничения не было, иначе я бы не добавил к себе в закладки эту систему на попробовать. Я не пробую и не пишу про коммерческие решения, где нет хоть какой-нибудь бесплатной версии, которой можно полноценно пользоваться.
Так бы можно было для себя оставить систему корпоративного уровня, но с ограничениями, которые в личном использовании не критичны. Так делают многие вендоры. Почему RuBackup и многие другие отечественные компании не хотят идти по этому пути для популяризации своих продуктов, я не понимаю. С ограничением в 1ТБ эту систему и так в коммерческую организацию не поставишь. Какой смысл ещё и по времени пользования ограничивать? Неужели это какую-то упущенную прибыль может принести? Кто-нибудь может это объяснить?
#backup
Там внушительные возможности по функциональности. KVM и, в частности, Proxmox, тоже поддерживается. Есть бесплатная версия без существенных ограничений, но для бэкапов объёмом суммарно до 1ТБ уже после дедупликации. Понятно, что для прода это очень мало, но для личных нужд или теста вполне достаточно.
Сразу скажу, что сам с этой системой не работал. Хотел поставить и попробовать, поэтому и заметку не писал так долго, но руки так и не дошли. И, наверное, не дойдут, поэтому решил написать. Это не реклама, у меня никто эту заметку не заказывал.
Если кто-то пользовался, покупал, внедрял, поделитесь, пожалуйста, впечатлением.
Пока писал заметку, полазил по сайту и увидел, что срок действия бесплатной лицензии - 1 год 🤦 Зачем так делать, я не понимаю. Раньше этого ограничения не было, иначе я бы не добавил к себе в закладки эту систему на попробовать. Я не пробую и не пишу про коммерческие решения, где нет хоть какой-нибудь бесплатной версии, которой можно полноценно пользоваться.
Так бы можно было для себя оставить систему корпоративного уровня, но с ограничениями, которые в личном использовании не критичны. Так делают многие вендоры. Почему RuBackup и многие другие отечественные компании не хотят идти по этому пути для популяризации своих продуктов, я не понимаю. С ограничением в 1ТБ эту систему и так в коммерческую организацию не поставишь. Какой смысл ещё и по времени пользования ограничивать? Неужели это какую-то упущенную прибыль может принести? Кто-нибудь может это объяснить?
#backup
Расскажу пару историй с ошибками бэкапов, с которыми столкнулся за последнее время. Я уже много раз рассказывал про свои подходы к созданию бэкапов. Вот примеры: 1, 2, 3, 4, 5, 6. Ничего нового не скажу, просто поделюсь своими историями.
Проблема номер 1. Есть сервер PBS для бэкапа виртуальных машин Proxmox. Бэкапы регулярно делаются, проходят проверку встроенными средствами, ошибок нет. Решаю проверить полное восстановление VM на новый сервер. Нашёл подходящий свободный сервер, подключил хранилище PBS, запустил восстановление виртуалки размером 450 Гб. А оно не проходит. Тупо ошибка:
в случайный момент времени. Ошибка неинформативная. Со стороны PBS просто:
Похоже на сетевую ошибку. Немного погуглил, увидел людей, которые сталкивались с похожими проблемами. Причины могут быть разными. У кого-то с драйвером сетевухи проблемы, какие-то настройки интерфейса меняют, у кого-то через VPN есть эта ошибка, без VPN нет. Я, кстати, по VPN каналу делал восстановление. Возможно, это мой случай.
Столкнуться с проблемами передачи такого большого файла через интернет вероятность очень большая. Никакой докачки нет. После ошибки, начинай всё заново. Поэтому я всегда делаю бэкап VM и в обязательном порядке сырых данных внутри этой виртуалки. Обычно с помощью rsync или чего-то подобного. Это позволит всегда иметь под рукой реальные данные без привязки к какой-то системе бэкапов, которая может тупо заглючить или умереть.
Хорошо, что это была просто проверка и у меня есть другие бэкапы данных. А если бы была авария и тут такой сюрприз в виде невозможности восстановиться. Кстати, бэкап на самом деле живой. Я вытащил из него данные через обзор файлов. Но целиком восстановить VM не получилось из-за каких-то сетевых проблем.
Проблема номер 2. События вообще в другом месте и никак не связаны. Разные компании. Появляется новый свободный сервер, который ещё не запустили в эксплуатацию. Решаю на него восстановить полную версию VM через Veeam Backup and Replication. Вим регулярное делает бэкапы, шлёт отчёты, бэкапы восстанавливаются через настроенную задачу репликации. То есть всё работает как надо.
Новый сервер в другой локации, с другой сетью, связь через VPN. Но тут сразу скажу, проблема не в этом. Запускаю восстановление, а оно раз за разом падает с ошибкой:
Налицо какая-то сетевая проблема, но не могу понять, в чём дело. SMB шара работает, доступна. Бэкапы туда складываются и разворачиваются планом репликации. На вид всё ОК.
Несколько дней я подходил к этой задаче и не мог понять, что не так. Решение пришло случайно. Я вспомнил, что NAS, с которого монтируется SMB шара, файрволом ограничен белым списком IP, которым разрешён доступ к данным. Я проверял с управляющей машины и реплицировал данные на сервера из этого списка, которые в одной локации. Проблем не было. А нового сервера в списках не было. Восстановление запускает агента на новом сервере и он напрямую от себя тянет данные с хранилища, а я думал, что через прокси на управляющей машине.
Хорошо, что всё это было выявлено во время проверки. А если бы всё грохнулось и я пытался бы восстановиться, то не факт, что вспомнил, в чём проблема, особенно в состоянии стресса. Столько бы кирпичей отложил, когда увидел, что бэкап не восстанавливается.
❗️В заключении скажу банальность - проверяйте бэкапы. Особенно большие VM и бэкапы баз данных.
#backup
Проблема номер 1. Есть сервер PBS для бэкапа виртуальных машин Proxmox. Бэкапы регулярно делаются, проходят проверку встроенными средствами, ошибок нет. Решаю проверить полное восстановление VM на новый сервер. Нашёл подходящий свободный сервер, подключил хранилище PBS, запустил восстановление виртуалки размером 450 Гб. А оно не проходит. Тупо ошибка:
restore failed: error:0A000119:SSL routines:ssl3_get_record:decryption failed or bad record mac:../ssl/record/ssl3_record.c:622в случайный момент времени. Ошибка неинформативная. Со стороны PBS просто:
TASK ERROR: connection error: connection resetПохоже на сетевую ошибку. Немного погуглил, увидел людей, которые сталкивались с похожими проблемами. Причины могут быть разными. У кого-то с драйвером сетевухи проблемы, какие-то настройки интерфейса меняют, у кого-то через VPN есть эта ошибка, без VPN нет. Я, кстати, по VPN каналу делал восстановление. Возможно, это мой случай.
Столкнуться с проблемами передачи такого большого файла через интернет вероятность очень большая. Никакой докачки нет. После ошибки, начинай всё заново. Поэтому я всегда делаю бэкап VM и в обязательном порядке сырых данных внутри этой виртуалки. Обычно с помощью rsync или чего-то подобного. Это позволит всегда иметь под рукой реальные данные без привязки к какой-то системе бэкапов, которая может тупо заглючить или умереть.
Хорошо, что это была просто проверка и у меня есть другие бэкапы данных. А если бы была авария и тут такой сюрприз в виде невозможности восстановиться. Кстати, бэкап на самом деле живой. Я вытащил из него данные через обзор файлов. Но целиком восстановить VM не получилось из-за каких-то сетевых проблем.
Проблема номер 2. События вообще в другом месте и никак не связаны. Разные компании. Появляется новый свободный сервер, который ещё не запустили в эксплуатацию. Решаю на него восстановить полную версию VM через Veeam Backup and Replication. Вим регулярное делает бэкапы, шлёт отчёты, бэкапы восстанавливаются через настроенную задачу репликации. То есть всё работает как надо.
Новый сервер в другой локации, с другой сетью, связь через VPN. Но тут сразу скажу, проблема не в этом. Запускаю восстановление, а оно раз за разом падает с ошибкой:
Restore job failed. Error: The network path was not found. Failed to open storage for read access. Storage: [\\10.30.5.21\veeam\Office\OfficeD2024-05-23T040102_8E4F.vib]. Failed to restore file from local backup. VFS link: [summary.xml]. Target file: [MemFs://frontend::CDataTransferCommandSet::RestoreText_{f81d9dbd-ee5b-4a4e-ae58-744bb6f46a6b}]. CHMOD mask: [226]. Agent failed to process method {DataTransfer.RestoreText}.Налицо какая-то сетевая проблема, но не могу понять, в чём дело. SMB шара работает, доступна. Бэкапы туда складываются и разворачиваются планом репликации. На вид всё ОК.
Несколько дней я подходил к этой задаче и не мог понять, что не так. Решение пришло случайно. Я вспомнил, что NAS, с которого монтируется SMB шара, файрволом ограничен белым списком IP, которым разрешён доступ к данным. Я проверял с управляющей машины и реплицировал данные на сервера из этого списка, которые в одной локации. Проблем не было. А нового сервера в списках не было. Восстановление запускает агента на новом сервере и он напрямую от себя тянет данные с хранилища, а я думал, что через прокси на управляющей машине.
Хорошо, что всё это было выявлено во время проверки. А если бы всё грохнулось и я пытался бы восстановиться, то не факт, что вспомнил, в чём проблема, особенно в состоянии стресса. Столько бы кирпичей отложил, когда увидел, что бэкап не восстанавливается.
❗️В заключении скажу банальность - проверяйте бэкапы. Особенно большие VM и бэкапы баз данных.
#backup
Прочитал интересную серию статей Building A 'Mini' 100TB NAS, где человек в трёх частях рассказывает, как он себе домой NAS собирал и обновлял. Железо там хорошее для дома. Было интересно почитать.
Меня в третьей части привлёк один проект для создания хранилища с дублированием информации - SnapRAID. Я раньше не слышал про него. Это такая необычная штука не то бэкапилка, не то рейд массив. Наполовину и то, и другое. Расскажу, как она работает.
Образно SnapRAID можно сравнить с RAID 5 или RAID 6, но с ручной синхронизацией. И реализован он программно поверх уже существующей файловой системы.
Допустим, у вас сервер с четырьмя дисками. Вы хотите быть готовым к тому, что выход из строя одного из дисков не приведёт к потере данных. Тогда вы настраиваете SnapRAID следующим образом:
/mnt/diskp <- диск для контроля чётности
/mnt/disk1 <- первый диск с данными
/mnt/disk2 <- второй диск с данными
/mnt/disk3 <- третий диск с данными
Принцип получается как в обычном RAID5. Вы создаёте настройки для SnapRAID в
И после этого запускаете синхронизацию:
Данные на дисках могут уже присутствовать. Это не принципиально. SnapRAID запустит процесс пересчёта чётности файлов, как в обычном RAID 5. Только проходит это не в режиме онлайн, а после запуска команды.
После того, как вся чётность пересчитана, данные защищены на всех дисках. Если любой из дисков выйдет из строя, у вас будет возможность восстановить данные на момент последней синхронизации.
Звучит это немного странно и я до конца не могу осознать, как это работает, потому что толком не понимаю, как контроль чётности помогает восстанавливать файлы. Но в общем это работает. Получается классический RAID 5 с ручной синхронизацией.
Надеюсь основной принцип работы я передал. Насколько я понял, подобная штука может быть очень удобной для дома. К примеру, для хранения медиа контента, к которому доступ в основном в режиме чтения. Не нужны никакие рейд контроллеры и массивы. Берём любые диски, объединяем их в SnapRAID, синхронизируем данные раз в сутки по ночам и спокойно спим. Если выйдет из строя один диск, вы ничего не теряете. Имеете честный RAID 5 с ручной синхронизацией, что для дома приемлемо. Да и не только для дома. Можно ещё где-то придумать применение.
Одной из возможностей SnapRAID является создание некоего пула, который будет объединять символьными ссылками в режиме чтения данные со всех дисков в одну точку монтирования, которую можно расшарить в сеть. То есть берёте NAS из четырёх дисков. Один диск отдаёте на контроль чётности. Три Остальных заполняете, как вам вздумается. Потом создаёте пул, шарите его по сети, подключаете к телевизору. Он видит контент со всех трёх дисков.
Выглядит эта тема на самом деле неплохо. У меня дома как раз NAS на 4 диска и у меня там 2 зеркала RAID 1 на базе mdadm. В основном хранится контент для медиацентра, фотки и немного других файлов. Вариант со SnapRAID смотрится в этом случае более привлекательным, чем два рейд массива.
Я прочитал весь Getting Started. Настраивается и управляется эта штука очень просто. Небольшой конфиг и набор простых команд. Понятен процесс восстановления файлов, добавления новых дисков. Даже если что-то пойдёт не так, то больше данных, чем было на сломавшемся диске, вы не потеряете. Не выйдет так, что массив развалился и вы остались без данных, так как они лежат в исходном виде на файловой системе.
SnapRAID есть в составе openmediavault. Он там очень давно присутствует в виде плагина. Программа представляет из себя один исполняемый файл и конфигурацию к нему. Есть как под Linux, так и Windows.
⇨ Сайт / Исходники
#fileserver #backup
Меня в третьей части привлёк один проект для создания хранилища с дублированием информации - SnapRAID. Я раньше не слышал про него. Это такая необычная штука не то бэкапилка, не то рейд массив. Наполовину и то, и другое. Расскажу, как она работает.
Образно SnapRAID можно сравнить с RAID 5 или RAID 6, но с ручной синхронизацией. И реализован он программно поверх уже существующей файловой системы.
Допустим, у вас сервер с четырьмя дисками. Вы хотите быть готовым к тому, что выход из строя одного из дисков не приведёт к потере данных. Тогда вы настраиваете SnapRAID следующим образом:
/mnt/diskp <- диск для контроля чётности
/mnt/disk1 <- первый диск с данными
/mnt/disk2 <- второй диск с данными
/mnt/disk3 <- третий диск с данными
Принцип получается как в обычном RAID5. Вы создаёте настройки для SnapRAID в
/etc/snapraid.conf:parity /mnt/diskp/snapraid.paritycontent /var/snapraid/snapraid.contentcontent /mnt/disk1/snapraid.contentcontent /mnt/disk2/snapraid.contentdata d1 /mnt/disk1/data d2 /mnt/disk2/data d3 /mnt/disk3/И после этого запускаете синхронизацию:
# snapraid syncДанные на дисках могут уже присутствовать. Это не принципиально. SnapRAID запустит процесс пересчёта чётности файлов, как в обычном RAID 5. Только проходит это не в режиме онлайн, а после запуска команды.
После того, как вся чётность пересчитана, данные защищены на всех дисках. Если любой из дисков выйдет из строя, у вас будет возможность восстановить данные на момент последней синхронизации.
Звучит это немного странно и я до конца не могу осознать, как это работает, потому что толком не понимаю, как контроль чётности помогает восстанавливать файлы. Но в общем это работает. Получается классический RAID 5 с ручной синхронизацией.
Надеюсь основной принцип работы я передал. Насколько я понял, подобная штука может быть очень удобной для дома. К примеру, для хранения медиа контента, к которому доступ в основном в режиме чтения. Не нужны никакие рейд контроллеры и массивы. Берём любые диски, объединяем их в SnapRAID, синхронизируем данные раз в сутки по ночам и спокойно спим. Если выйдет из строя один диск, вы ничего не теряете. Имеете честный RAID 5 с ручной синхронизацией, что для дома приемлемо. Да и не только для дома. Можно ещё где-то придумать применение.
Одной из возможностей SnapRAID является создание некоего пула, который будет объединять символьными ссылками в режиме чтения данные со всех дисков в одну точку монтирования, которую можно расшарить в сеть. То есть берёте NAS из четырёх дисков. Один диск отдаёте на контроль чётности. Три Остальных заполняете, как вам вздумается. Потом создаёте пул, шарите его по сети, подключаете к телевизору. Он видит контент со всех трёх дисков.
Выглядит эта тема на самом деле неплохо. У меня дома как раз NAS на 4 диска и у меня там 2 зеркала RAID 1 на базе mdadm. В основном хранится контент для медиацентра, фотки и немного других файлов. Вариант со SnapRAID смотрится в этом случае более привлекательным, чем два рейд массива.
Я прочитал весь Getting Started. Настраивается и управляется эта штука очень просто. Небольшой конфиг и набор простых команд. Понятен процесс восстановления файлов, добавления новых дисков. Даже если что-то пойдёт не так, то больше данных, чем было на сломавшемся диске, вы не потеряете. Не выйдет так, что массив развалился и вы остались без данных, так как они лежат в исходном виде на файловой системе.
SnapRAID есть в составе openmediavault. Он там очень давно присутствует в виде плагина. Программа представляет из себя один исполняемый файл и конфигурацию к нему. Есть как под Linux, так и Windows.
⇨ Сайт / Исходники
#fileserver #backup
Я давно знаю и работаю с программой для бэкапа виртуальных сред Veeam Backup & Replication. Как всем известно, этот бренд ушёл из России, заблокировал доступ к своим ресурсам, не осуществляет продажи и не оказывает тех. поддержку. Полноценных аналогов с такой же функциональностью не так много. Я даже затрудняюсь назвать их, хотя наверняка есть, но мне не знакомы. То есть не работал с ними. Отечественные решения, насколько я знаю, по возможностям пока не дотягивают до Veeam.
Есть китайский аналог Vinchin Backup & Recovery. Я года два назад про него узнал, когда начались всевозможные санкции. Были пару обзоров от наших интеграторов КРОК и ГК ЛАНИТ. Причём отзывы вполне нормальные. В то же время на меня выходили сами разработчики и хотели какой-то кооперации: статьи, заметок в telegram, анонсов вебинаров и т.д. Был необычный опыт, так как общаться приходилось явно с не русскоязычным человеком, но мы понимали друг друга. Но всё как-то не срасталось по срокам и форматам.
Чтобы как-то предметно общаться, я решил всё же своими глазами посмотреть и попробовать этот продукт. К тому же на сайте есть русскоязычная версия с описанием, а список возможностей выглядит очень привлекательно. Можно объединить в единой системе бэкап вообще всей информации. Плюс поддержка отечественных ОС и систем виртуализации.
Есть полностью бесплатная версия для бэкапа трёх виртуальных машин. Не густо, конечно, но хоть что-то.
📌 Vinchin Backup & Recovery умеет бэкапить:
◽Виртуальные машины на различных гипервизорах и системах виртуализации. Список там очень внушительный, перечислю наиболее популярные и актуальные: zVirt, ROSA Virtualization, RED Virtualization, Hyper-V, Proxmox, VMware, Citrix, XCP-ng, oVirt, OpenStack
◽Базы данных популярных СУБД: MS SQL, MySQL, Oracle, PostgreSQL, MariaDB
◽Файлы в операционных системах Windows и Linux с помощью установленных агентов. Есть поддержка Astra Linux и RED OS.
◽Целиком операционные системы Windows и Linux, либо отдельные диски в них.
◽Сетевые диски, подключаемые по протоколам CIFS и NFS.
◽Microsoft Exchange как локальной установки, так и облачной.
◽Виртуальные машины облачного провайдера AWS EC2
Получается, он покрывает все варианты информации. Тут и виртуальные машины, и сервера через агентов, и сетевые диски, и СУБД.
Я развернул у себя эту систему. Ставится автоматически из готового ISO образа. Всё управление через веб интерфейс. Попробовал забэкапить и восстановить виртуальные машины на Hyper-V и Proxmox, а также сетевой диск.
Всё получилось практически сходу. Система простая, функциональная и удобная. Мне прям она вообще понравилась. Оформил всё в простой обзор с картинками, чтобы наглядно показать, как всё это выглядит на практике:
⇨ Обзор Vinchin Backup & Recovery
Если выбираете себе подобный продукт, то посмотрите Vinchin. Честно говоря, я с некоторым скепсисом её разворачивал, ожидая увидеть какие-то нелогичности, мелкие баги как интерфейса, так и самой работы, возможно ещё какие-то проблемы. Но на удивление, всё прошло гладко и ровно. Никаких ошибок я не заметил.
За скобками остался вопрос стоимости. Так как на сайте в открытом доступе цен нет, сказать мне об этом нечего. Все цены только по запросу. В лучших традициях, так сказать. Ну и ещё раз напомню, что есть бесплатная версия для бэкапа трёх виртуальных машин.
#backup
Есть китайский аналог Vinchin Backup & Recovery. Я года два назад про него узнал, когда начались всевозможные санкции. Были пару обзоров от наших интеграторов КРОК и ГК ЛАНИТ. Причём отзывы вполне нормальные. В то же время на меня выходили сами разработчики и хотели какой-то кооперации: статьи, заметок в telegram, анонсов вебинаров и т.д. Был необычный опыт, так как общаться приходилось явно с не русскоязычным человеком, но мы понимали друг друга. Но всё как-то не срасталось по срокам и форматам.
Чтобы как-то предметно общаться, я решил всё же своими глазами посмотреть и попробовать этот продукт. К тому же на сайте есть русскоязычная версия с описанием, а список возможностей выглядит очень привлекательно. Можно объединить в единой системе бэкап вообще всей информации. Плюс поддержка отечественных ОС и систем виртуализации.
Есть полностью бесплатная версия для бэкапа трёх виртуальных машин. Не густо, конечно, но хоть что-то.
📌 Vinchin Backup & Recovery умеет бэкапить:
◽Виртуальные машины на различных гипервизорах и системах виртуализации. Список там очень внушительный, перечислю наиболее популярные и актуальные: zVirt, ROSA Virtualization, RED Virtualization, Hyper-V, Proxmox, VMware, Citrix, XCP-ng, oVirt, OpenStack
◽Базы данных популярных СУБД: MS SQL, MySQL, Oracle, PostgreSQL, MariaDB
◽Файлы в операционных системах Windows и Linux с помощью установленных агентов. Есть поддержка Astra Linux и RED OS.
◽Целиком операционные системы Windows и Linux, либо отдельные диски в них.
◽Сетевые диски, подключаемые по протоколам CIFS и NFS.
◽Microsoft Exchange как локальной установки, так и облачной.
◽Виртуальные машины облачного провайдера AWS EC2
Получается, он покрывает все варианты информации. Тут и виртуальные машины, и сервера через агентов, и сетевые диски, и СУБД.
Я развернул у себя эту систему. Ставится автоматически из готового ISO образа. Всё управление через веб интерфейс. Попробовал забэкапить и восстановить виртуальные машины на Hyper-V и Proxmox, а также сетевой диск.
Всё получилось практически сходу. Система простая, функциональная и удобная. Мне прям она вообще понравилась. Оформил всё в простой обзор с картинками, чтобы наглядно показать, как всё это выглядит на практике:
⇨ Обзор Vinchin Backup & Recovery
Если выбираете себе подобный продукт, то посмотрите Vinchin. Честно говоря, я с некоторым скепсисом её разворачивал, ожидая увидеть какие-то нелогичности, мелкие баги как интерфейса, так и самой работы, возможно ещё какие-то проблемы. Но на удивление, всё прошло гладко и ровно. Никаких ошибок я не заметил.
За скобками остался вопрос стоимости. Так как на сайте в открытом доступе цен нет, сказать мне об этом нечего. Все цены только по запросу. В лучших традициях, так сказать. Ну и ещё раз напомню, что есть бесплатная версия для бэкапа трёх виртуальных машин.
#backup
Server Admin
Обзор Vinchin Backup & Recovery – инструмента для бэкапа всей...
Обзор, знакомство и первый опыт использования системы бэкапов Vinchin Backup & Recovery для физических и виртуальных сред.
Для тех, кто пользуется Proxmox Backup Server (PBS) важное предостережение. Я им пользуюсь практически с момента релиза, но только недавно столкнулся с проблемой. Не допускайте исчерпания свободного места на сервере с бэкапами.
Я краем уха слышал, что очистка от старых данных нетривиальная штука и нельзя просто взять, удалить ненужные бэкапы и освободить занятое место. Но сам с этим не сталкивался, так как обычно место планирую с запасом и настраиваю мониторинг. Так что своевременно предпринимаю какие-то действия.
А тут проспал. Точнее, неправильно отреагировал на сложившуюся ситуацию. Были видно, что место заканчивается. Я зашёл, удалил некоторые бэкапы в ожидании увеличения свободного объёма для хранения. Была сделана копия большой виртуалки, которая тоже поехала в архив. Рассчитывал, что благодаря дедупликации, реального места будет занято не так много. Но ошибся.
То ли место не успело освободиться, то ли дедупликация в реальности сработала не так, как я ожидал, но в итоге было занято 100% доступного объёма хранилища и все процессы в нём встали. Он даже сам себя очистить не мог. Процесс Garbage Collect не запускался из-за недостатка свободного места. Я решил вопрос просто - очистил логи systemd:
Они занимали несколько гигабайт, так что мне хватило для того, чтобы отработал процесс Garbage Collect. Но он не удаляет данные, а только помечает их к удалению. Реально данные будут удалены через 24 часа и 5 минут после того, как сборщик мусора пометит их на удаление. И никакого способа вручную запустить реальную очистку хранилища нет. По крайней мере я не нашёл.
Очень внимательно прочитал несколько тем на официальном форуме по этой проблеме и везде совет один - освобождайте место или расширяйте хранилище, если у вас zfs, запускайте сборщик мусора и ждите сутки. Других вариантов нет, кроме полного удаления Datastore со всеми бэкапами. Тогда место освободится сразу.
Это особенность реализации дедупликации в PBS. Помеченные на удаления chunks реально удаляются через 24 часа. Форсировать этот процесс не получится.
#proxmox #backup
Я краем уха слышал, что очистка от старых данных нетривиальная штука и нельзя просто взять, удалить ненужные бэкапы и освободить занятое место. Но сам с этим не сталкивался, так как обычно место планирую с запасом и настраиваю мониторинг. Так что своевременно предпринимаю какие-то действия.
А тут проспал. Точнее, неправильно отреагировал на сложившуюся ситуацию. Были видно, что место заканчивается. Я зашёл, удалил некоторые бэкапы в ожидании увеличения свободного объёма для хранения. Была сделана копия большой виртуалки, которая тоже поехала в архив. Рассчитывал, что благодаря дедупликации, реального места будет занято не так много. Но ошибся.
То ли место не успело освободиться, то ли дедупликация в реальности сработала не так, как я ожидал, но в итоге было занято 100% доступного объёма хранилища и все процессы в нём встали. Он даже сам себя очистить не мог. Процесс Garbage Collect не запускался из-за недостатка свободного места. Я решил вопрос просто - очистил логи systemd:
# journalctl --vacuum-size=256MОни занимали несколько гигабайт, так что мне хватило для того, чтобы отработал процесс Garbage Collect. Но он не удаляет данные, а только помечает их к удалению. Реально данные будут удалены через 24 часа и 5 минут после того, как сборщик мусора пометит их на удаление. И никакого способа вручную запустить реальную очистку хранилища нет. По крайней мере я не нашёл.
Очень внимательно прочитал несколько тем на официальном форуме по этой проблеме и везде совет один - освобождайте место или расширяйте хранилище, если у вас zfs, запускайте сборщик мусора и ждите сутки. Других вариантов нет, кроме полного удаления Datastore со всеми бэкапами. Тогда место освободится сразу.
Это особенность реализации дедупликации в PBS. Помеченные на удаления chunks реально удаляются через 24 часа. Форсировать этот процесс не получится.
#proxmox #backup
