Улучшить 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) легко нагуглить.
Особенно в применении к современным облачным хранилищам.