Улучшить BACKUP

[skid]

Да, именно так.

[Capricornus]

Да, именно так.

Спасибо!
Надеюсь, реализация продвинутого бекапа станет для вас приоритетной задачей)
Спасибо и за панель управления, удачи в разработке. Отличный продукт!

[Ansy]

Апну тему конструктивно.

Дабы решить сразу множество проблем с бэкапами -- а попробуйте впилить в VestaCP готовую утилиту BorgBackup.

Получим сразу:

• многоуровневый бэкап
• эффективнейшую дедупликацию/инкрементальность для сохранения места (в т.ч. на уровне всего сервера/архива)
• настраиваемой глубины автоматическое удаление старых версий (borg prune)

Более того -- например, у Хетцнера интерфейс к бэкап-пространству уже предлагается готовый в т.ч. и по Borg-интерфейсу, удобно и весьма шустро (потому что гигабитная сеть + на их стороне расчётом контрольных сумм нагружены ИХ процессорные ресурсы, а не свои локальные).

Если надо выкачать отдельный бэкап из архива -- можно так же легко примонтировать его в каталог (borg mount).
И для пущей сохранности регулярно синхронизировать весь Borg-архив с одним из многочисленных облачных хранилищ посредством замечательной утилитки rclone, что опять же за счет параллельной работы и своего ресурса, и облачного, исключительно быстро (rclone sync на Яндекс.Диск -- под 30МБАйт/с) и ТОЛЬКО изменённые блоки.

[demian]

Апну тему конструктивно.

Не наблюдаю коснтруктива.
1. два непонятных скрипта вместо одного duply(duplicity)
2. эффективная дедубликация может быть только, если она реализована на уровне файловой системы(пока адекватная реализация только в zfs - под хостинг не подходит, скорее под системы хранения).
3. Сторонние системы централизованного бакапа - amanda и bacula лучше и универсальнее нет

[Ansy]

Не наблюдаю коснтруктива.
1. два непонятных скрипта вместо одного duply(duplicity)

Тоже вариант. Но лишь бы не так как сейчас -- архив и расход кучи места, особенно в процессе копирования на внешний FTP.
Способы хранения -- на выбор. Я предложил один из удобных имеющихся на одном из распространённых хостингов (бесплатно притом).

2. эффективная дедубликация может быть только, если она реализована на уровне файловой системы(пока адекватная реализация только в zfs - под хостинг не подходит, скорее под системы хранения).

К сожалению, мы не можем выбирать тип ФС на сторонних хранилищах, в облачных сервисах, куда бэкапится оооочень шустро (Яндекс.Диск под 400Мбит/с например наблюдаю). Очень вероятно, что там и ZFS (как раз оно у меня в Proxmox), и что-то гораздо более энтерпрайзное. Но это уже не наша забота, это их внутренняя "заоблачная" кухня.
Тут более важен факт, что rclone имеет единый интерфейс к целой куче облачных и не очень хранилищ. Тупо проще охватить кучу стораджей одним скриптом.

3. Сторонние системы централизованного бакапа - amanda и bacula лучше и универсальнее нет

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

[demian]

duply(duplicity) интерфейс управления для бакапов и сервисов хранения. для одного профиля может быть только одно назначение(локально, ftp, s3, s2, webdaw, dropbox, windows share и пр )

rclone не взаимодействует напрямую с хранилищами, а работает через те же утилиты командной строки что использует duply, только бакапить не уммет.

бесплатный сыр в мышеловке. нормальный хостинг бесплатным не бывает - догма. также как и сАвсем дешевым.

amanda и bacula ставятся на выделенный сервер, на продакшенах только клиенты, выполняющие действия согласно планировщику сервера

К сожалению, мы не можем выбирать тип ФС на сторонних хранилищах

но можно выбрать хранилище. S3 работает наиболее оптимально с точки зрения функционала и возможностей расширения. во многих движках S3 поддерживается в качестве хранилище статичного контента(бесплатные движки мной не рассматриваются см выще)

zfs не годится для веб сервера т.к. для своей полноценной работы с приемлемой скоростью требует не менее 4 ГБ оперативной памяти на 2 Терабайта дискового пространства и 2 ядра проца. LVM(для упрощения работы со снапшотами)+xfs дает максимальный выхлоп на серверах выше чем 2 гига оперативы и более 2 ядер проца.
В линух zfs портирована крайне плохо целом. модуль ядра так нормально не допилили, fuse лишняя прокладка. zfs - BSD (solaris, freebsd)

ЗЫ: написанное выше информация к размышлению.

[Ansy]

Нет пока времени подробно дискутировать вышеописанные моменты, но похоже я накопал более подходящую утилиту, включающую большинство стратегий бэкапа. Рассмотрите вариант restic

Средство резервного копирования restic от BorgBackup отличает, навскидку:

1. Встроенный механизм доступа к облачным хранилищам (или напрямую, или ещё туча через тот же rclone)
2. ... в силу чего можно лить сразу в облака разные (для Borg надо или монтировать заранее, или иметь агента на том конце)
3. Более высокая скорость работы, многопоточность
4. ... в силу отсутствия встроенной компрессии (а у нас и так уже архивы, не критично)
5. Меньшая зависимость от окружения (Go-бинарник вместо Python, но тут я не могу судить, не писец на обоих)

Они не лучше или хуже друг друга -- просто restic более подходит IMHO под конкретно здесь решаемую задачу.

[demian]

restic
- нет в стандартных репозиториях, подключать пользовательские репозитории на продакшен сервер не айс.
- отсутствую файлы конфигурации. общие и пользовательские --> усложняет интеграцию.
- And many other services via the rclone Backend (с github)
дальше не смотрел

не придумывайте велосипед его давно сделали, собрали, проверили и положили туда где просто взять.

Code: Select all

# yum search duply
***
duply.noarch : Wrapper for duplicity

Code: Select all

$ aptitude search duply
p   duply                                                                      - Простой в использовании интерфейс для системы резервного копирования duplicity

[Stesh]

Блин.
Вот реально, все что нужно весте - это стабильный олдскульный tar с вменяемыми исключениями и система хуков.
Первое даст готовую систему бекапов из коробки (в принципе оно уже как бы есть, только весьма неуклюжая система, с ребилдом конфигов и т.д), второе даст более продвинутому админу запилить свою систему бекапов (rclone, duplicity, bakula, etc) в лучших традициях 3rd party application, не трогая скрипты самой панели.

[Ansy]

restic
- нет в стандартных репозиториях, подключать пользовательские репозитории на продакшен сервер не айс.

+ Есть на гитхабе, не намного сложнее.
+ Можно вообще скачать-залить один бинарник и не париться с репами, новичкам и клиентам особенно.
+ В свежих версиях добавили команду self-update -- само скачивается, проверяет GPG и обновляет бинарник.

- отсутствую файлы конфигурации. общие и пользовательские --> усложняет интеграцию.

+ Только упрощает переносимость -- не надо помнить, где что раскидано и форматы файлов.
+ Из конфигурации надо только переменные среды, и можно наскриптить ключи командной строки.
+ Файлы конфигурации тоже можно использовать (пароли те же, списки исключений), в ключах указать где искать.

- And many other services via the rclone Backend (с github)
дальше не смотрел

+ А зря. Удачный ход rclone перекрывает даже больше вариантов хранилищ, чем в "нативном" функционале.
+ Ставится rclone столь же просто, и конфигурируется менюшкой -- новичкам меньше шансов накосячить.
+ Кроме платных сервисов есть толпа других, в т.ч. бесплатных -- тот же Яндекс.Диск шустро жужжит. Далеко не у всех есть возможность пользоваться забугорными платными сервисами.

не придумывайте велосипед его давно сделали, собрали, проверили и положили туда где просто взять.

Code: Select all

# yum search duply
***
duply.noarch : Wrapper for duplicity

Code: Select all

$ aptitude search duply
p   duply                                                                      - Простой в использовании интерфейс для системы резервного копирования duplicity

Вот именно что велосипед.
Различия в скорости обработки, объёмах перекачиваемого трафика, способах хранения, организации дедупликации, удобстве применения restic (borgbackup) vs duply (duplicity) легко нагуглить.
Особенно в применении к современным облачным хранилищам.