We are happy to announce that Vesta is back under active development as of 25 February 2024. We are working on v1 candidate and expect to engage more with the community over the coming months. We are committed to open source, and we encourage contributors to help us build the future of Vesta.
Улучшить BACKUP
Re: Улучшить BACKUP
Да, именно так.
-
- Posts: 30
- Joined: Tue Sep 24, 2013 4:58 pm
Re: Улучшить BACKUP
Спасибо!skid wrote:Да, именно так.
Надеюсь, реализация продвинутого бекапа станет для вас приоритетной задачей)
Спасибо и за панель управления, удачи в разработке. Отличный продукт!
Re: Улучшить BACKUP
Апну тему конструктивно.
Дабы решить сразу множество проблем с бэкапами -- а попробуйте впилить в VestaCP готовую утилиту BorgBackup.
Получим сразу:
Если надо выкачать отдельный бэкап из архива -- можно так же легко примонтировать его в каталог (borg mount).
И для пущей сохранности регулярно синхронизировать весь Borg-архив с одним из многочисленных облачных хранилищ посредством замечательной утилитки rclone, что опять же за счет параллельной работы и своего ресурса, и облачного, исключительно быстро (rclone sync на Яндекс.Диск -- под 30МБАйт/с) и ТОЛЬКО изменённые блоки.
Дабы решить сразу множество проблем с бэкапами -- а попробуйте впилить в VestaCP готовую утилиту BorgBackup.
Получим сразу:
- многоуровневый бэкап
- эффективнейшую дедупликацию/инкрементальность для сохранения места (в т.ч. на уровне всего сервера/архива)
- настраиваемой глубины автоматическое удаление старых версий (borg prune)
Если надо выкачать отдельный бэкап из архива -- можно так же легко примонтировать его в каталог (borg mount).
И для пущей сохранности регулярно синхронизировать весь Borg-архив с одним из многочисленных облачных хранилищ посредством замечательной утилитки rclone, что опять же за счет параллельной работы и своего ресурса, и облачного, исключительно быстро (rclone sync на Яндекс.Диск -- под 30МБАйт/с) и ТОЛЬКО изменённые блоки.
Re: Улучшить BACKUP
Не наблюдаю коснтруктива.
1. два непонятных скрипта вместо одного duply(duplicity)
2. эффективная дедубликация может быть только, если она реализована на уровне файловой системы(пока адекватная реализация только в zfs - под хостинг не подходит, скорее под системы хранения).
3. Сторонние системы централизованного бакапа - amanda и bacula лучше и универсальнее нет
Re: Улучшить BACKUP
Тоже вариант. Но лишь бы не так как сейчас -- архив и расход кучи места, особенно в процессе копирования на внешний FTP.
Способы хранения -- на выбор. Я предложил один из удобных имеющихся на одном из распространённых хостингов (бесплатно притом).
К сожалению, мы не можем выбирать тип ФС на сторонних хранилищах, в облачных сервисах, куда бэкапится оооочень шустро (Яндекс.Диск под 400Мбит/с например наблюдаю). Очень вероятно, что там и ZFS (как раз оно у меня в Proxmox), и что-то гораздо более энтерпрайзное. Но это уже не наша забота, это их внутренняя "заоблачная" кухня.
Тут более важен факт, что rclone имеет единый интерфейс к целой куче облачных и не очень хранилищ. Тупо проще охватить кучу стораджей одним скриптом.
Замечательно. Но их же надо ставить к себе на хостинг. А я предлагаю всунуть однострочником или процедуркой в бэкап-скрипты VestaCP, чтоб оно автоматом появилось даже у тех, кому нет даже консольного доступа к серверу.
Re: Улучшить BACKUP
duply(duplicity) интерфейс управления для бакапов и сервисов хранения. для одного профиля может быть только одно назначение(локально, ftp, s3, s2, webdaw, dropbox, windows share и пр )
rclone не взаимодействует напрямую с хранилищами, а работает через те же утилиты командной строки что использует duply, только бакапить не уммет.
бесплатный сыр в мышеловке. нормальный хостинг бесплатным не бывает - догма. также как и сАвсем дешевым.
amanda и bacula ставятся на выделенный сервер, на продакшенах только клиенты, выполняющие действия согласно планировщику сервера
zfs не годится для веб сервера т.к. для своей полноценной работы с приемлемой скоростью требует не менее 4 ГБ оперативной памяти на 2 Терабайта дискового пространства и 2 ядра проца. LVM(для упрощения работы со снапшотами)+xfs дает максимальный выхлоп на серверах выше чем 2 гига оперативы и более 2 ядер проца.
В линух zfs портирована крайне плохо целом. модуль ядра так нормально не допилили, fuse лишняя прокладка. zfs - BSD (solaris, freebsd)
ЗЫ: написанное выше информация к размышлению.
rclone не взаимодействует напрямую с хранилищами, а работает через те же утилиты командной строки что использует duply, только бакапить не уммет.
бесплатный сыр в мышеловке. нормальный хостинг бесплатным не бывает - догма. также как и сАвсем дешевым.
amanda и bacula ставятся на выделенный сервер, на продакшенах только клиенты, выполняющие действия согласно планировщику сервера
но можно выбрать хранилище. S3 работает наиболее оптимально с точки зрения функционала и возможностей расширения. во многих движках S3 поддерживается в качестве хранилище статичного контента(бесплатные движки мной не рассматриваются см выще)
zfs не годится для веб сервера т.к. для своей полноценной работы с приемлемой скоростью требует не менее 4 ГБ оперативной памяти на 2 Терабайта дискового пространства и 2 ядра проца. LVM(для упрощения работы со снапшотами)+xfs дает максимальный выхлоп на серверах выше чем 2 гига оперативы и более 2 ядер проца.
В линух zfs портирована крайне плохо целом. модуль ядра так нормально не допилили, fuse лишняя прокладка. zfs - BSD (solaris, freebsd)
ЗЫ: написанное выше информация к размышлению.
Re: Улучшить BACKUP
Нет пока времени подробно дискутировать вышеописанные моменты, но похоже я накопал более подходящую утилиту, включающую большинство стратегий бэкапа. Рассмотрите вариант restic
Средство резервного копирования restic от BorgBackup отличает, навскидку:
Средство резервного копирования restic от BorgBackup отличает, навскидку:
- Встроенный механизм доступа к облачным хранилищам (или напрямую, или ещё туча через тот же rclone)
- ... в силу чего можно лить сразу в облака разные (для Borg надо или монтировать заранее, или иметь агента на том конце)
- Более высокая скорость работы, многопоточность
- ... в силу отсутствия встроенной компрессии (а у нас и так уже архивы, не критично)
- Меньшая зависимость от окружения (Go-бинарник вместо Python, но тут я не могу судить, не писец на обоих)
Re: Улучшить BACKUP
restic
- нет в стандартных репозиториях, подключать пользовательские репозитории на продакшен сервер не айс.
- отсутствую файлы конфигурации. общие и пользовательские --> усложняет интеграцию.
- And many other services via the rclone Backend (с github)
дальше не смотрел
не придумывайте велосипед его давно сделали, собрали, проверили и положили туда где просто взять.
- нет в стандартных репозиториях, подключать пользовательские репозитории на продакшен сервер не айс.
- отсутствую файлы конфигурации. общие и пользовательские --> усложняет интеграцию.
- 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
Re: Улучшить BACKUP
Блин.
Вот реально, все что нужно весте - это стабильный олдскульный tar с вменяемыми исключениями и система хуков.
Первое даст готовую систему бекапов из коробки (в принципе оно уже как бы есть, только весьма неуклюжая система, с ребилдом конфигов и т.д), второе даст более продвинутому админу запилить свою систему бекапов (rclone, duplicity, bakula, etc) в лучших традициях 3rd party application, не трогая скрипты самой панели.
Вот реально, все что нужно весте - это стабильный олдскульный tar с вменяемыми исключениями и система хуков.
Первое даст готовую систему бекапов из коробки (в принципе оно уже как бы есть, только весьма неуклюжая система, с ребилдом конфигов и т.д), второе даст более продвинутому админу запилить свою систему бекапов (rclone, duplicity, bakula, etc) в лучших традициях 3rd party application, не трогая скрипты самой панели.
Re: Улучшить BACKUP
+ Есть на гитхабе, не намного сложнее.
+ Можно вообще скачать-залить один бинарник и не париться с репами, новичкам и клиентам особенно.
+ В свежих версиях добавили команду self-update -- само скачивается, проверяет GPG и обновляет бинарник.
+ Только упрощает переносимость -- не надо помнить, где что раскидано и форматы файлов.
+ Из конфигурации надо только переменные среды, и можно наскриптить ключи командной строки.
+ Файлы конфигурации тоже можно использовать (пароли те же, списки исключений), в ключах указать где искать.
+ А зря. Удачный ход rclone перекрывает даже больше вариантов хранилищ, чем в "нативном" функционале.
+ Ставится rclone столь же просто, и конфигурируется менюшкой -- новичкам меньше шансов накосячить.
+ Кроме платных сервисов есть толпа других, в т.ч. бесплатных -- тот же Яндекс.Диск шустро жужжит. Далеко не у всех есть возможность пользоваться забугорными платными сервисами.
Вот именно что велосипед.demian wrote: ↑Fri Oct 12, 2018 9:48 amне придумывайте велосипед его давно сделали, собрали, проверили и положили туда где просто взять.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) легко нагуглить.
Особенно в применении к современным облачным хранилищам.