На днях потратил кучу времени, чтобы настроить загрузку файлов на Яндекс.Диск через REST API. Больше всего провозился с настройкой доступа и получением токена. Текущего личного кабинета и документации недостаточно, чтобы успешно выполнить задачу. Пришлось разбираться. У Яндекс.Диска очень дешёвое хранилище. Активно его использую и для себя, и по работе.
1️⃣ С этим этапом я провозился больше всего. Если посмотреть документацию, то там предлагают пойти по ссылке https://yandex.ru/dev/oauth/ и создать приложение. Но в созданном через ЛК приложении у вас не будет возможности указать права для Яндекс.Диска. Это какой-то косяк очередного обновления сервиса. Раньше этой проблемы точно не было, так как я много раз получал токены для других нужд.
Правильная ссылка — https://oauth.yandex.ru/client/new По ней сразу можно создать приложение с нужными правами. Нужны будут следующие права:
▪ Доступ к папке приложения на Диске
▪ Доступ к информации о Диске
2️⃣ После создания приложения получите для него токен. Для этого откройте в браузере ссылку: https://oauth.yandex.ru/authorize?response_type=token&client_id=717284f34ab94558702c94345ac01829
В конце подставьте свой client_id от созданного приложения.
3️⃣ Прежде чем отправить файл в Яндекс.Диск, нужно получить ссылку для загрузки. Сделаем это с помощью curl:
curl -s -H "Authorization: OAuth y0_AgAAAAAAGk3WAAoqUQAAAADngUZDvsZq_dLLQSCfcGfddRqo5ETE25k" https://cloud-api.yandex.net:443/v1/disk/resources/upload/?path=app:/testfile.gz&overwrite=true
y0_AgAAAAAAGk3WAAoqUQAAAADngUZDvsZq_dLLQSCfcGfddRqo5ETE25k — ваш токен
app:/testfile.gz — путь, куда будет загружен файл testfile.gz. В таком формате пути у вас в корне диска будет директория Приложения, в ней директория с именем приложения, а в ней уже файл.
В ответ вы получите url для загрузки.
4️⃣ Используя полученный url, загружаем файл:
curl -s -T ~/testfile.gz -H "Authorization: OAuth y0_AgAAAAAAGk3WAAoqUQAAAADngUZDvsZq_dLLQSCfcGfddRqo5ETE25k" https://uploader6g.disk.yandex.net:443/upload-target/20230711T030316.348.utd.cbcacvszdm46g8j68kttgwnuq-k6g.8149437
Теперь всё это можно обернуть в какой-то скрипт в зависимости от ваших потребностей. Я свой скрипт не буду приводить, он слишком длинный. Примеры можете посмотреть в статье Backup с помощью Yandex Disk REST API. Там подробно расписаны несколько вариантов.
#bash #backup
1️⃣ С этим этапом я провозился больше всего. Если посмотреть документацию, то там предлагают пойти по ссылке https://yandex.ru/dev/oauth/ и создать приложение. Но в созданном через ЛК приложении у вас не будет возможности указать права для Яндекс.Диска. Это какой-то косяк очередного обновления сервиса. Раньше этой проблемы точно не было, так как я много раз получал токены для других нужд.
Правильная ссылка — https://oauth.yandex.ru/client/new По ней сразу можно создать приложение с нужными правами. Нужны будут следующие права:
▪ Доступ к папке приложения на Диске
▪ Доступ к информации о Диске
2️⃣ После создания приложения получите для него токен. Для этого откройте в браузере ссылку: https://oauth.yandex.ru/authorize?response_type=token&client_id=717284f34ab94558702c94345ac01829
В конце подставьте свой client_id от созданного приложения.
3️⃣ Прежде чем отправить файл в Яндекс.Диск, нужно получить ссылку для загрузки. Сделаем это с помощью curl:
curl -s -H "Authorization: OAuth y0_AgAAAAAAGk3WAAoqUQAAAADngUZDvsZq_dLLQSCfcGfddRqo5ETE25k" https://cloud-api.yandex.net:443/v1/disk/resources/upload/?path=app:/testfile.gz&overwrite=true
y0_AgAAAAAAGk3WAAoqUQAAAADngUZDvsZq_dLLQSCfcGfddRqo5ETE25k — ваш токен
app:/testfile.gz — путь, куда будет загружен файл testfile.gz. В таком формате пути у вас в корне диска будет директория Приложения, в ней директория с именем приложения, а в ней уже файл.
В ответ вы получите url для загрузки.
4️⃣ Используя полученный url, загружаем файл:
curl -s -T ~/testfile.gz -H "Authorization: OAuth y0_AgAAAAAAGk3WAAoqUQAAAADngUZDvsZq_dLLQSCfcGfddRqo5ETE25k" https://uploader6g.disk.yandex.net:443/upload-target/20230711T030316.348.utd.cbcacvszdm46g8j68kttgwnuq-k6g.8149437
Теперь всё это можно обернуть в какой-то скрипт в зависимости от ваших потребностей. Я свой скрипт не буду приводить, он слишком длинный. Примеры можете посмотреть в статье Backup с помощью Yandex Disk REST API. Там подробно расписаны несколько вариантов.
#bash #backup
Вчера слушал вебинар Rebrain по поводу бэкапов MySQL. Мне казалось, что я в целом всё знаю по этой теме. Это так и оказалось, кроме одного маленького момента. Существует более продвинутый аналог mysqldump для создания логических бэкапов — mydumper. Решил сразу сделать про него заметку, чтобы не забыть и самому запомнить инструмент.
Как вы, наверное, знаете, существуют два типа бэкапов MySQL:
1️⃣ Логические, или дампы, как их ещё называют. Это текстовые данные в виде sql команд, которые при восстановлении просто выполняются на сервере. Их обычно делают с помощью утилиты Mysqldump, которая идёт в комплекте с MySQL сервером. Их отличает простота создания и проверки. Из минусов — бэкапы только полные, долго создаются и долго восстанавливаются. В какой-то момент, в зависимости от размера базы и возможностей железа, их делать становится практически невозможно. (моя статья по теме)
2️⃣ Бинарные бэкапы на уровне непосредственно файлов базы данных. Наиболее популярное бесплатное средство для создания таких бэкапов — Percona XtraBackup. Позволяет делать полные и инкрементные бэкапы баз данных и всего сервера СУБД в целом. (моя статья по теме)
Mysqldump делает бэкапы в один поток и на выходе создаёт один файл дампа. Можно это обойти, делая скриптом бэкап таблиц по отдельности, но при таком подходе могут быть проблемы с целостностью итоговой базы. Отдельно таблицу из полного дампа можно вытянуть с помощью sed или awk. Пример потабличного бэкапа базы или вытаскивания отдельной таблицы из полного дампа я делал в заметке.
Так вот, с чего я начал. Есть утилита MyDumper, которая работает чуть лучше Mysqldump. Она делает логический дамп базы данных в несколько потоков и сразу складывает его в отдельные файлы по таблицам. И при этом контролирует целостность итогового бэкапа базы данных. Восстановление такого бэкапа выполняется с помощью MyLoader и тоже в несколько потоков.
Такой подход позволяет выполнять бэкап и восстановление базы в разы быстрее, чем с помощью Mysqldump, если, конечно, позволяет дисковая подсистема сервера. Использовать MyDumper не сложнее, чем Mysqldump. Это та же консольная утилита, которой можно передать параметры в виде ключей или заранее задать в конфигурационном файле. Примеры есть в репозитории.
Я не знал про существовании этой утилиты, хотя почти все свои сервера MySQL бэкаплю в виде логических бэкапов Mysqldump. Надо будет переходить на MyDumper.
#mysql #backup
Как вы, наверное, знаете, существуют два типа бэкапов MySQL:
1️⃣ Логические, или дампы, как их ещё называют. Это текстовые данные в виде sql команд, которые при восстановлении просто выполняются на сервере. Их обычно делают с помощью утилиты Mysqldump, которая идёт в комплекте с MySQL сервером. Их отличает простота создания и проверки. Из минусов — бэкапы только полные, долго создаются и долго восстанавливаются. В какой-то момент, в зависимости от размера базы и возможностей железа, их делать становится практически невозможно. (моя статья по теме)
2️⃣ Бинарные бэкапы на уровне непосредственно файлов базы данных. Наиболее популярное бесплатное средство для создания таких бэкапов — Percona XtraBackup. Позволяет делать полные и инкрементные бэкапы баз данных и всего сервера СУБД в целом. (моя статья по теме)
Mysqldump делает бэкапы в один поток и на выходе создаёт один файл дампа. Можно это обойти, делая скриптом бэкап таблиц по отдельности, но при таком подходе могут быть проблемы с целостностью итоговой базы. Отдельно таблицу из полного дампа можно вытянуть с помощью sed или awk. Пример потабличного бэкапа базы или вытаскивания отдельной таблицы из полного дампа я делал в заметке.
Так вот, с чего я начал. Есть утилита MyDumper, которая работает чуть лучше Mysqldump. Она делает логический дамп базы данных в несколько потоков и сразу складывает его в отдельные файлы по таблицам. И при этом контролирует целостность итогового бэкапа базы данных. Восстановление такого бэкапа выполняется с помощью MyLoader и тоже в несколько потоков.
Такой подход позволяет выполнять бэкап и восстановление базы в разы быстрее, чем с помощью Mysqldump, если, конечно, позволяет дисковая подсистема сервера. Использовать MyDumper не сложнее, чем Mysqldump. Это та же консольная утилита, которой можно передать параметры в виде ключей или заранее задать в конфигурационном файле. Примеры есть в репозитории.
Я не знал про существовании этой утилиты, хотя почти все свои сервера MySQL бэкаплю в виде логических бэкапов Mysqldump. Надо будет переходить на MyDumper.
#mysql #backup
Я активно использую как в работе, так и в личных целях, Яндекс.Диск. У него очень низкая стоимость хранения данных. В Linux использую либо API для загрузки данных, либо rclone.
Для Windows использовал либо родной клиент, что не очень удобно, либо монтировал сетевой диск в Linux и там с ним работал. Не знал, что полнофункциональный rclone нормально работает в Windows, причём абсолютно так же, как в Linux. Настройка 1 в 1.
Установить можно как вручную, так и с помощью winget:
Через winget не сразу понял, куда он был установлен. Оказалось, что в директорию C:\Users\User\AppData\Local\Microsoft\WinGet\Packages\Rclone.Rclone_Microsoft.Winget.Source_8wekyb3d8bbwe\rclone-v1.63.1-windows-amd64.
Для настройки работы rclone с Яндекс диском нужно получить токен. Как это сделать, я описывал в заметке по работе с API. Единственное отличие — нужно предоставить побольше прав:
▪ Доступ к папке приложения на Диске
▪ Доступ к информации о Диске
▪ Запись в любом месте на Диске
▪ Доступ к Яндекс.Диску для приложений
А в качестве Redirect URI использовать ссылку: http://127.0.0.1:53682/
После этого запускаете в консоли команду:
Выбираете New remote ⇨ указываете название, например yandex ⇨ номер 48, соответствующий хранилищу Яндекс диск ⇨ client_id и client_secret оставляете пустыми ⇨ выполняете запрос токена ⇨ сохраняете конфиг.
У вас появится файл в C:\Users\User\AppData\Roaming\rclone\rclone.conf примерно следующего содержания:
[yandex]
type = yandex
client_id =
client_secret =
token = {"access_token":"y0_AgAAAABvmXfPAALEtgAAAAKpIA8y2bb-M0IiRFu068gJJKvzSOGoBBs","token_type":"OAuth","refresh_token":"1:p0NRuhts1VI1N7Sq:NWEoGv963fVVGSpE_k8Mftn6Pd8AKsFcte2WGqv77mKgWaoer36TX4irbubWTfCgk9_Gxh5NLBzkWA:b_dCjrHMIEMkKeH-oOFrFQ","expiry":"2024-07-30T20:45:05.4991551+03:00"}
Теперь можно через консоль загружать туда файлы:
Положили в корень диска файл test.txt
Помимо загрузки файлов, rclone умеет монтировать внешние хранилища как локальные или сетевые диски. Для этого ему нужна программа winfsp. Поставить можно тоже через winget:
Монтируем яндекс диск в режиме чтения:
Или в режиме записи:
Яндекс диск смонтирован в виде локального диска X. Подробнее о монтировании в Windows, о правах доступа и прочих нюансах можно прочитать в документации.
Если для вас всё это слишком замороченно и хочется попроще, то вот набор программ, которые реализуют то же самое. Это платные программы, с ограниченными бесплатными версиями. Они удобны и популярны, так что при желании, вы найдёте репаки платных версий, но аккуратнее с ними. Я лично давно уже опасаюсь использовать ломаный софт.
🔹Air Explorer — двухпанельный файловый менеджер, который позволяет работать с облачными сервисами как с локальными директориями. Поддерживает и Яндекс.Диск, и диск от Mail ru.
🔹Air Live Drive — программа от того же производителя, которая позволят монтировать облачные диски как локальные.
🔹RaiDrive — писал об этой программе ранее. Позволяет подключать различные облачные сервисы как локальные диски.
#windows #rclone #backup
Для Windows использовал либо родной клиент, что не очень удобно, либо монтировал сетевой диск в Linux и там с ним работал. Не знал, что полнофункциональный rclone нормально работает в Windows, причём абсолютно так же, как в Linux. Настройка 1 в 1.
Установить можно как вручную, так и с помощью winget:
> winget install rcloneЧерез winget не сразу понял, куда он был установлен. Оказалось, что в директорию C:\Users\User\AppData\Local\Microsoft\WinGet\Packages\Rclone.Rclone_Microsoft.Winget.Source_8wekyb3d8bbwe\rclone-v1.63.1-windows-amd64.
Для настройки работы rclone с Яндекс диском нужно получить токен. Как это сделать, я описывал в заметке по работе с API. Единственное отличие — нужно предоставить побольше прав:
▪ Доступ к папке приложения на Диске
▪ Доступ к информации о Диске
▪ Запись в любом месте на Диске
▪ Доступ к Яндекс.Диску для приложений
А в качестве Redirect URI использовать ссылку: http://127.0.0.1:53682/
После этого запускаете в консоли команду:
> rclone configВыбираете New remote ⇨ указываете название, например yandex ⇨ номер 48, соответствующий хранилищу Яндекс диск ⇨ client_id и client_secret оставляете пустыми ⇨ выполняете запрос токена ⇨ сохраняете конфиг.
У вас появится файл в C:\Users\User\AppData\Roaming\rclone\rclone.conf примерно следующего содержания:
[yandex]
type = yandex
client_id =
client_secret =
token = {"access_token":"y0_AgAAAABvmXfPAALEtgAAAAKpIA8y2bb-M0IiRFu068gJJKvzSOGoBBs","token_type":"OAuth","refresh_token":"1:p0NRuhts1VI1N7Sq:NWEoGv963fVVGSpE_k8Mftn6Pd8AKsFcte2WGqv77mKgWaoer36TX4irbubWTfCgk9_Gxh5NLBzkWA:b_dCjrHMIEMkKeH-oOFrFQ","expiry":"2024-07-30T20:45:05.4991551+03:00"}
Теперь можно через консоль загружать туда файлы:
> rclone copy C:\Users\User\Downloads\test.txt yandex:/Положили в корень диска файл test.txt
Помимо загрузки файлов, rclone умеет монтировать внешние хранилища как локальные или сетевые диски. Для этого ему нужна программа winfsp. Поставить можно тоже через winget:
> winget install winfspМонтируем яндекс диск в режиме чтения:
> rclone mount yandex:/ X:Или в режиме записи:
> rclone mount yandex:/ X: --vfs-cache-mode writesЯндекс диск смонтирован в виде локального диска X. Подробнее о монтировании в Windows, о правах доступа и прочих нюансах можно прочитать в документации.
Если для вас всё это слишком замороченно и хочется попроще, то вот набор программ, которые реализуют то же самое. Это платные программы, с ограниченными бесплатными версиями. Они удобны и популярны, так что при желании, вы найдёте репаки платных версий, но аккуратнее с ними. Я лично давно уже опасаюсь использовать ломаный софт.
🔹Air Explorer — двухпанельный файловый менеджер, который позволяет работать с облачными сервисами как с локальными директориями. Поддерживает и Яндекс.Диск, и диск от Mail ru.
🔹Air Live Drive — программа от того же производителя, которая позволят монтировать облачные диски как локальные.
🔹RaiDrive — писал об этой программе ранее. Позволяет подключать различные облачные сервисы как локальные диски.
#windows #rclone #backup
Расскажу одну историю, которая случилась со мной на днях. Это будет наглядный пример закона подлости и надежды на авось. У меня есть два старых неттопа, которые я время от времени использую. По характеристикам они до сих пор вполне актуальны: 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
