Для бэкапа баз 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
