company_banner

Краткий обзор open source средств резервного копирования

    Средства для резервного копирования информации можно разделить на несколько категорий:
    — Для домашнего/офисного применения (резервирование важных документов, фотографий и пр. на NAS либо в облако);
    — Для средних и крупных (offline) предприятий (резервирование важных документов, отчетности, баз данных и пр. как на серверах так и на рабочих станциях сотрудников);
    — Для малых веб-проектов (резервирование файлов и баз данных с хостинговой площадки либо VPS/VDS на удаленный хост (или наоборот));
    — Для крупных веб-проектов с распределенной архитектурой (почти то же самое, что и на offline-предприятиях только с учетом работы в глобальной сети, а не локальной, и как правило с использование open source средств).

    С программными продуктами для дома и офиса все достаточно просто есть масса решений как открытых так и проприетарных, от cmd/bash скриптов до решений известных производителей ПО.
    В enterprise секторе все достаточно скучно есть масса программных продуктов которые давно и успешно работают на многих предприятиях, в крупных банках и пр, рекламировать никого не будем. Многие из этих продуктов хорошо упростили жизнь системных администраторов, за достаточно «скромные деньги» по меркам некоторых предприятий.
    В данной статье более подробно рассмотрим open source решения для резервного копирования веб-проектов разного масштаба, а также проведем тест на скорость резервирования файлов.
    Статья будет полезна веб-мастерам, небольшим веб-студиям, ну и возможно даже бывалый админ найдет здесь что-то полезное.

    Что нужно для резервирования небольшого сайта или блога, или нескольких сайтов, например с VPS-ки на которой дискового пространства впритык?
    Напрашивается резервирование на удаленный хост. Т.е. чтобы сэкономить драгоценное место на вашем хостинге или VPS, вы можете подключаться, например со своего домашнего/офисного компьютера (возможно у вас есть NAS), по протоколам ftp или sftp, вручную или по расписанию забирать файлики и бережно складывать их каком-то надежном месте. Сойдет любой клиент ftp или sftp, хороший вариант rsync.

    С Rsync выглядит это примерно так:
    rsync -avzPch user@remote.host:/path/to/copy /path/to/local/storage

    И это вроде бы неплохо, но что если нужно хранить несколько версий бекапов БД? Или по каким-то причинам понадобилось делать инкрементальные копии, а еще бы неплохо и шифрование добавить. Можно немножко посидеть и сделать хороший велосипед скрипт под свои нужды (например наш rsync-backup), либо взять что-то из готовых утилит.

    Рассмотрим несколько утилит которые подойдут для различных случаев применения, в частности и для случая описанного выше.

    Duplicity

    Duplicity консольная утилита для резервного копирования с достаточно широкими возможностями.
    Существует несколько графических оболочек для Duplicity — Deja-dup для среды Gnome и test-drive для KDE. Также существует консольная обертка duply.

    Duplicity производит бекап в зашифрованные тома в tar-формате локально или на удаленный хост. Делать инкрементальные записи файлов позволяет библиотека librsync, для компрессии используется gzip и gpg делает шифрование.
    Конфигурационного файла нет. Автоматизировать процесс резервирования придется самому.

    Примеры использования:

    Резервирование локальной папки на удаленный хост
    duplicity /usr scp://host.net/target_dir
    Резервирование с удаленного хоста в локальную папку
    duplicity sftp://user@remote.host/var/www /home/backup/var/www
    Восстановление
    duplicity restore /home/backup/var/www sftp://user@remote.host/var/www

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

    Rsnapshot

    Про rsnapshot также не мало сказано на Хабре, тут и тут. А здесь еще хорошая статья. Rsnapshot в целом, хороший инструмент для создания инкрементальных бекапов (снапшотов). Написан на perl, использует rsync для копирования файлов. Достаточно быстрый (быстрее rdiff-backup) и неплохо экономит место на диске за счет жестких ссылок. Умеет делать pre и post-backup операции, не умеет (без костылей) шифровать и делать бекап на удаленный хост. Файлы хранятся в первозданном виде — легко восстанавливать. Достаточно удобно организовано конфигурирование. Поддерживает несколько временных уровней резервирования (дневной, недельный, месячный). Есть достаточно активное сообщество.

    После того как вы пропишете в конфиге необходимые строки (что бекапить и куда), можно запустить бекап:
    rsnapshot -v hourly
    По умолчанию будет храниться несколько ежечасных и дневных снапшотов. От прочих утилит Rsnapshot отличается тем что он из коробки автоматизирован (актуально для Debian/Ubuntu), т.е. в крон пропишутся необходимые строки, а в конфиге прописано резервирование каталогов "/home", "/etc", "/usr/local"

    Rdiff-backup

    Rdiff-backup очень похож на Rsnapshot, но в отличии от него написан на Python и использует библиотеку librsync для передачи данных. Умеет копировать файлы на удаленный хост, чем кстати мы довольно успешно пользовались и кое где еще пользуемся. Также можно делать бекап с удаленного хоста, но предварительно нужно установить там Rdiff-backup. Хранит информацию об изменениях файлов (дельты) в сжатом виде, хорошо для больших файлов, позволяет экономить место на диске даже по сравнению с rsnapshot.
    Метаданные (права, даты, владелец) хранятся в отдельных файлах.
    Запуск бекапа производится из консоли:
    rdiff-backup remote.host::/home/web/sites/ /home/backup/rdiff/
    Наличие конфигурационного файла не предполагается. Автоматизировать придется самому.

    Obnam

    Obnam — открытое клиент-серверное приложение для резервного копирования, код программы написан на языке Python для передачи данных используется протокол SSH. Может эксплуатироваться в двух видах:
    — Push резервирование с локального хоста на удаленный сервер на котором работает демон Obnam.
    — Pull демон сам забирает файлы с удаленных хостов по протоколу ssh. В этом случае клиент Obnam не нужен.
    Умеет делать снапшоты, дедупликацию и шифрование GnuPG. Резервные копии файлов хранятся в томах. Метаданные хранятся в отдельных файлах. Восстановление производится через консоль.

    Небольшая выдержка из описания на Opennet (http://www.opennet.ru/opennews/art.shtml?num=39323):
    «Предлагаемый в Obnam подход к резервному копированию нацелен на достижение трёх целей: обеспечение высокой эффективности хранения, простоты использования и безопасности. Эффективность хранения достигается благодаря размещению резервных копий в специальном репозитории, данные в котором хранятся в оптимальном представлении с использованием дедупликации. В одном репозитории могут храниться бэкапы разных клиентов и серверов. При этом объединение дубликатов осуществляется для всех хранимых бэкапов, независимо от их типа, времени создания и источника резервной копии. Для проверки целостности репозитория и его восстановления после сбоя предоставляется специальный вариант утилиты fsck.

    Если на группе серверов используется одинаковая операционная система, то в репозитории будет сохранена только одна копия повторяющихся файлов, что позволяет существенно сэкономить дисковое пространство при организации резервного копирования большого числа типовых систем, например, виртуальных окружений. Репозиторий для хранения резервных копий может быть размещён как на локальном диске, так и на внешних серверах (для создания сервера для хранения резервных копий не требуется установка дополнительных программ, достаточно доступа по SFTP). Возможен доступ к резервным копиям через монтирование виртуального раздела при помощи специально подготовленного FUSE-модуля.»

    Все это хорошо, НО для копирования на удаленный хост используется scp со всеми вытекающими.

    Bacula

    Bacula — кроссплатформенное клиент-серверное программное обеспечение, позволяющее управлять резервным копированием, восстановлением, и проверкой данных по сети для компьютеров и операционных систем различных типов. На данный момент Bacula можно использовать практически на любых unix-подобных системах (Linux (включая zSeries), NetBSD, FreeBSD, OpenBSD, Solaris, HP-UX, Tru64, IRIX, Mac OS X) и на Microsoft Windows.

    Bacula также может выполняться полностью на единственном компьютере или, распределённо, на нескольких, и может записывать резервные копии на различные типы носителей, включая ленты, ленточные библиотеки (autochangers/libraries) и диски.

    Bacula — это сетевая клиент-серверная программа для резервного копирования, архивирования и восстановления. Предлагая широкие возможности для управления хранилищами данных, облегчает поиск и восстановление потерянных или повреждённых файлов. Благодаря модульной структуре, Bacula масштабируется и может работать как на маленьких так и на крупных системах, состоящих из сотен компьютеров, расположенных в большой сети.

    К Bacula имеются GUI и веб-интерфейсы (Almir, Webmin) различной степени сложности.
    Некоторое время назад мне пришлось сильно и безрезультатно повозится с Almir чтобы запустить его на Debian Wheezy.

    Bacula это надежная проверенная временем система резервного копирования в том числе хорошо зарекомендовавшая себя на многих крупных предприятиях. От Obnam принципиально Bacula отличается схемой работы. В случае варианта клиент-сервер Bacula будет являться 100% централизованной системой. Также необходимо наличие клиентского приложения на хосте который нужно бекапить. На сервере работают одновременно три демона SD, FD. DIR — Storage Daemon, File Daemon и Director соответственно. Нетрудно догадаться кто за что отвечает.

    Резервные копии файлов Bacula хранит в томах. Метаданные хранятся в БД (SQLite, MySQL, PostgreSQL) Восстановление производится с помощью консольной утилиты либо посредством графической оболочки. Процесс восстановления через консоль, прямо скажем, не самый удобный.

    Цифры
    Я решил проверить скорость резервирования небольшой папки (626M) с несколькими сайтами на WP.
    Для этого я даже не поленился развернуть и настроить весь этот софт. :)
    Тест состоит из двух частей:
    1. Участники Duplicity, Rsync, Rsnapshot, Rdiff-Backup. Копируем с удаленного сервера на домашний компьютер, при этом поскольку Rsnapshot не умеет делать remote-бекап, то он и Rdiff-backup (для сравнения) будут работать домашней машине, т.е. будут тянуть (pull) с файлы с сервера, а остальные наоборот, будут толкать (push) на домашнюю машину.
    Все утилиты запускались с минимально необходимыми опциями.

    Rsync
    rsync -az /home/web/sites/ home.host:/home/backup/rsync
    Full backup
    Время выполнения:
    real	4m23.179s
    user	0m31.963s
    sys	0m2.165s
    

    Incremental
    Время выполнения
    real	0m4.963s
    user	0m0.437s
    sys	0m0.562s
    

    Занимаемое место:
    626M /home/backup/duplicity/

    Duplicity
    duplicity full /home/web/sites/ rsync://home.host//home/backup/duplicity
    Full backup
    Время выполнения:
    real	5m52.179s
    user	0m46.963s
    sys	0m4.165s
    

    Incremental
    Время выполнения
    real	0m49.883s
    user	0m5.637s
    sys	0m0.562s
    

    Занимаемое место:
    450M /home/backup/duplicity/

    Rsnapshot
    rsnapshot -v hourly
    Full backup
    Время выполнения:
    real	4m23.192s
    user	0m32.892s
    sys	0m2.185s
    

    Incremental
    Время выполнения
    real	0m5.266s
    user	0m0.423s
    sys	0m0.656s
    

    Занимаемое место:
    626M /home/tmp/backup/rsnap/

    Rdiff-backup
    rdiff-backup remote.host::/home/web/sites/ /home/backup/rdiff/
    Full backup
    Время выполнения:
    real	7m26.315s
    user	0m14.341s
    sys	0m3.661s
    

    Incremental
    Время выполнения
    real	0m25.344s
    user	0m5.441s
    sys	0m0.060s
    

    Занимаемое место:
    638M /home/backup/rsnap/

    Результаты достаточно предсказуемы. Самый быстрый оказался Rsync, практически такой же результат у Rsnapshot. Duplicity немного медленней но меньше занимает места на диске. Rdiff-backup ожидаемо хуже.

    2. Теперь интересное. Проверим как работают Obnam и Bacula. Оба решения достаточно универсальны плюс имеют некоторые сходства. Посмотрим кто шустрее.
    Obnam
    Первый раз я запустил копирование с удаленного хоста на свой домашний, ждать пришлось долго:
    obnam backup --repository sftp://home.host/home/backup/obnam/ /home/web/sites/
    Full backup
    Backed up 23919 files, uploaded 489.7 MiB in 1h42m16s at 81.7 KiB/s average speed
    Время выполнения:
    real	102m16.469s
    user	1m23.161s
    sys	0m10.428s
    

    obnam backup --repository sftp://home.host/home/backup/obnam/ /home/web/sites/
    Incremental
    Backed up 23919 files, uploaded 0.0 B in 3m8s at 0.0 B/s average speed
    Время выполнения
    real	3m8.230s
    user	0m4.593s
    sys	0m0.389s
    

    Занимаемое место:
    544M /home/tmp/backup/rsnap/
    Не очень хороший результат как мне кажется, хотя понятный.
    Попробуем второй раз, но уже на соседний сервер по гигабитной сети и добавим компрессию.
    obnam backup --compress-with=deflate --repository sftp://remote.host/home/backup/obnam/ /home/web/sites/
    Full backup
    Backed up 23919 files, uploaded 489.7 MiB in 2m15s at 3.6 MiB/s average speed
    Время выполнения:
    real	2m15.251s
    user	0m55.235s
    sys	0m6.299s
    

    obnam backup --compress-with=deflate --repository sftp://remote.host/home/backup/obnam/ /home/web/sites/
    Incremental
    Backed up 23919 files, uploaded 0.0 B in 8s at 0.0 B/s average speed
    Время выполнения
    real	0m7.823s
    user	0m4.053s
    sys	0m0.253s
    

    Занимаемое место:
    434M /home/tmp/backup/rsnap/
    Так побыстрее и размер бекапа поменьше. Шифрование я не стал пробовать, может быть позже, если будет время.

    Bacula
    Для Bacula я подготовил полноценный клиент-сервер вариант. Клиент и сервер в одной гигабитной сети.
    Задание я запустил в фоновом режиме и пошел пить чай. Когда вернулся обнаружил, что уже все готово, а в логе следующее:
    ...
    Scheduled time:         23-Apr-2014 22:14:18
      Start time:             23-Apr-2014 22:14:21
      End time:               23-Apr-2014 22:14:34
      Elapsed time:           13 secs
      Priority:               10
      FD Files Written:       23,919
      SD Files Written:       23,919
      FD Bytes Written:       591,680,895 (591.6 MB)
      SD Bytes Written:       596,120,517 (596.1 MB)
      Rate:                   45513.9 KB/s
    ...
    

    Я даже немного удивился. Все сделалось за 13 секунд, следующий запуск прошел за одну секунду.

    Итого
    С помощью rsnapshot вы можете легко решить задачу резевного копирования файлов и БД (c дополнительным скриптом) вашего VPS на ваш домашний компьютер/ноутбук/NAS. Также неплохо rsnapshot справится с небольшим парком серверов 10-25 хостов (можно и больше конечно, зависит от вашего желания). Rdiff будет хорош для бекапа больших файлов (Видео-контент, базы данных и пр.)
    Duplicity поможет не только сохранить ваши данные в целости но защитить их в случае кражи (к сожалению от себя самого защититься нельзя, будьте внимательны и осторожны, храните ключи в надежном и недоступном никому постороннему месте).
    Bacula — open source промышленный стандарт, поможет держать в сохранности данные большого парка компьютеров и серверов любого предприятия.
    Obnam интересный инструмент имеющих ряд полезных достоинств, но я пожалуй рекомендовать никому не буду.
    Если же, вас все таки, по каким-то причинам, не устраивает ни одно из этих решений, не стесняйтесь изобретать свои велосипеды. Это может стать полезным как для вас лично, так и для многих людей.

    UPD: Небольшая сводная таблица:

    Какие средства для РК вы используете?

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Southbridge 87,48
    Обеспечиваем стабильную работу серверов
    Поделиться публикацией
    Похожие публикации
    Комментарии 45
    • +1
      С удовольствием почитал бы, в каком из вариантов проще всего восстанавливать из бекапов. А то недавно намучался с rdiff-backup =/
      • +3
        Проще всего из plain-файлов конечно. Т.е. либо свой скрипт с использование rsync (можно наш кстати), либо rsnapshot. Хотя, если разберетесь с теми же Bacula или Duplicity, то и там не очень сложно.
        • 0
          По-моему, из obnam быстрее всего и проще, потому что он не проходится по всем генерациям для вытаскивания файлов — у него есть прямой доступ к ним сразу.

          Ну и у него есть FUSE-based файловая система для удобного просмотра этих генераций.
          • 0
            Восстанавливать удобнее бакулой, за любую дату, на любого клиента, в любое место и тд.
            Если рассматривать именно процесс востановления то бакуле нет равных в удобстве. Настраивать ее изначально значительно дольше, но после настройки она доставляет только удовольствие.
          • 0
            А всё же скажите, почему obnam Вы рекомендовать никому не будете, довольно интересное заявление ведь.

            Да, и что плохого в sftp?
            • 0
              Плохого-то ничего. Просто меня «слегка» смущает его скорость по сравнению с rsync.
              Вы видели результаты теста?
              • 0
                Видел. И что там плохого?
                • +2
                  Ну если не считать, что по сравнению с Bacula он медленнее в 10 раз, то ничего конечно.
            • +4
              В очередной раз очень и очень советую Bareos, форк Bacula. Все то же самое, можно прикрутить админку webacula, но есть несколько отличий, из них два главнейших:
              — bacula отныне платный пакет, новые версии только за кэш можно получить, bareos же остался абсолютно бесплатным
              — в bareos имеется возможность ограничения сетевого канала, что иногда очень полезно, если выполняется бэкап сервера из удаленного офиса, в котором не самый хороший канал в интернет.
              • 0
                А откуда инфа про платный пакет?

                Цитата с главной страницы:
                Most of the Bacula source code is released under the AGPL version 3 license. If you wish additional details, please follow the License link to your left.


                Насколько я понял, ребята предоставляют платную поддержку, но сам Bacula все еще бесплатен.
                • 0
                  хм…
                  Не далее, чем год назад натыкался на то, что новые версии отныне в открытом доступе не будут.
                  Либо я ошибся и что-то не так понял, либо они сами передумали.

                  В любом случае, Bareos уже год стоит, шуршит, бэкапит и добавляет уверенности нашим админам :)
                  • 0
                    Ну то что они закрывали проект я не в курсе. Они прекратили поддержку windows клиента бесплатного.
                    В новой версии он тоже не появился. Придется все таки смотреть тогда в сторону bareos.
                • 0
                  Ну зачем дезинформировать людей.
                  Bacula не платная, есть у нее платная версия, но бесплатная доступна всем.
                  Мало того она еще и обновляется. 2 апреля состоялся релиз 7.0 и через пару дней уже было обновление. В итоге текущая версия 7.0.2.
                  Так что bacula работает и все нормально.
                  Сам думал в следующий раз ставить bareos тк bacula давно не обновлялась. В итоге пока останусь на проверенном продукте, тем более что и 5 версии за глаза.
                  • 0
                    прошу прощения еще раз.
                  • 0
                    Спасибо!

                    Я писал пару репортов в трекер бакулы (http://bugs.bacula.org/view.php?id=1964, bugs.bacula.org/view.php?id=1966) и понял, что отзывчивости там можно не ждать. Но т.к. аналогов не было, продолжал пользоваться. Теперь выбор есть, это очень хорошо.
                    • 0
                      А сообщество в bareos такое же тухлое как у бакулы или лучше?
                      • 0
                        На счёт ограничения сетевого канала… В организации, в которой я работаю, вместо ограничений применён QoS с самым низшим приоритетом backup трафика. Получается, что днём бекапы передаются неспешно, не нарушая работы VoIP и всего важного, а в ночные часы под эту задачу утилизируется большая часть полосы пропускания.
                      • +1
                        Наверно стоит еще упомянуть про форк bacula который называется bareos. Представляет собой старую добрую bacula но с новым функционалом и активным сообществом. Мне в нем понравился passive mode, позволяющий работать с клиентами за NAT.
                        • 0
                          Время инкрементального бэкапа rsync и duplcity одинаковые? кажется ошибочка
                          • 0
                            Да, ошибочка. Спасибо, поправил.
                          • +1
                            Я пользуюсь бэкап-фреймворком, если так можно выразиться, backupninja. В качестве бэкендов можно использовать те же rdiff и duplicity, можно написать свои плагины. Конфигурация довольно простая — по шагам описываем что нужно сделать для бэкапа. В общем, в не сильно замороченных случаях рекомендую.
                            • 0
                              Пытаюсь уйти с duplicity по причине нестабильной работы через Webdav и ssh.
                              Сейчас активно тестирую duplicati в связке с Яндекс.диск.
                              Отличительными особенностями этих программ является штатная возможность ротации резервных копий (т.е. удаления старых backup)
                              • 0
                                rsnapshot тоже хранит определенный период, потом удаляет
                              • 0
                                Остановился в своё время на rsnapshot, исходя из его скорости (в статье есть ссылка на сравнение с rdiff) и удобности поиска отдельных файлов по бэкапу. И проверять корректность созданных копий удобно по этой же причине — полная копия за любой период, открыл посмотрел что там. За всё время использования столкнулся только с одной проблемой — миллиарды мелких файлов бэкапить им не стоит. Процесс превращается в постоянное перекладывание пустого в порожнее и енотов (inode) перестает хватать.
                                • 0
                                  В случае если для хранения бэкапов используются ленты — Bacula практически единственный вариант.
                                  И справедливости ради, стоит добавить, что Bacula поддерживает клиента для AIX.

                                  Bacula Enterprise по сравнению с Bacula Community умеет несколько полезных плюшек: Oracle Plugin, Block-level incremental Plugin.
                                  Но плагины не под всем ОС работают, оракловый, например, работает только на линукс-серверах.
                                  Ценник вполне адекватный, но как ни парадоксально, Oracle Secure Backup вышел в 2 раза дешевле с перманентной лицензией.
                                  • 0
                                    Backup-pc не рассматривали? Тоже rsync-based, когда-то у меня было много ликсячьих серверов, и я ей активно пользовался. Пофайловое восстановление, веб-интерфейс с версиями файлов, все дела.
                                    • 0
                                      Использую самописные скрипты, которые берут что нужно, архивируют, шифруют, кладут в заданную директорию, попутно поддерживая нужное количество бэкапов каждого уровня. А дальше bittorentsync всё уносит на отдельную машину (при этом можно ограничить максимальную скорость).

                                      ЗЫ. А что можно посоветовать для бэкапа образов виртуалок? Весят много, останавливать нежелательно.
                                      • 0
                                        Виртуалки у вас на чем крутятся?
                                        • 0
                                          qemu-KVM под Убунтой
                                          • +2
                                            Я делаю так:
                                            1. qemu-ga (guest agent) freeze-fs
                                            2. snapshot хранилища образов ВМ на гипервизоре
                                            3. qemu-ga unfreeze-fs
                                            4. Бэкап
                                            5. удаление snapshot

                                            У меня CentOS 6, но не думаю, что в Ubuntu не этого функционала.
                                            • +1
                                              мы у себя так делаем xgu.ru/wiki/kvm_backup
                                        • 0
                                          По Bacula уточню:
                                          1. Резервное копирование на удаленный хост:
                                          — Копирование идет на StorageDaemon, который может быть на любом компютере. Причем для разных типов бекапа можно использовать разные файлохранилища: для полных бекапов — один, для диф — другой, для 2х-недельныз — третий.
                                          2. Шифрование
                                          — Бакула умеет шифровать как хранимую информацию, хотя можно ее хранить и в том же трукрипте, так и передаваемую информацию. Но есть пара ньюансов. Первый — метаданые не шифруются (название файлов, пути, владелец… ), второе — восстановить при полной потере директора — use the force, Luke.
                                          3. На одному клиенту может быть несколько одновременных задач которые будут писать на разные файлохранилища используя/неиспользуя сжатие и шифрование. Такое дает определенную гибкость и повышение производительности при копирование большого к-ва мелких файлов, большых файлов, файлов с разных дисков: т.е. дает возможность переключать контекст «бутылочного горлышка» между скорость сети/ производительность ЦП / производительность файловой подсистемы

                                          Из неявных минусов:
                                          1. Восстановление при полной потере директора/каталога. Из єтого следует:
                                          а. Всегда иметь бекап БД (каталога), мы используем Master-Slave. Плюс дампы БД и хранение отдельно.
                                          б. Всегда отдельно хранить bootstrap-ы
                                          в. Использовать multi-direct/multi-storage схему
                                          • 0
                                            Каталог можно восстановить полностью просканировав ленты (насчёт других форматов хранилища не уверен)
                                            • 0
                                              Да, есть такая возможность. Я не говорил что это минус и все, можно восстановить даже и без bootstrap-а, имея не шифрованное хранилище. Но как показала практика намного «дешевле» как по времени так и по железу иметь копию каталога и бутстрапа на черный день, тогда «неявный минус» отпадает.
                                          • 0
                                            Советую посмотреть еще в сторону attic
                                            • 0
                                              DAR есть в тегах, но его обзора нет.
                                              • 0
                                                Изначально писал и про него, но в последний момент решил его убрать, все таки это немного иного плана утилита.
                                              • 0
                                                Можно еще BittorentSync использовать для бекапов — www.severalnines.com/blog/use-bittorrent-sync-transfer-backups
                                                • 0
                                                  Есть еще Backup. Удобно рубистам и тем, у кого есть puppet.
                                                  • 0
                                                    использую Areca.
                                                    • 0
                                                      Почему-то не упомянули DAR. Недавно была неплохая статья habrahabr.ru/post/215449/. Разработчик оперативно отвечает на баги и feature request'ы. Но и без того выглядит достаточно стабильно и весьма гибко.
                                                      • 0
                                                        Почему это rsnapshot не умеет на удаленный хост бэкапить? Вполне себе может. Только по протоколу rsync.
                                                        Сам пользуюсь rsnapshot'ом, бэкаплю на удаленный NFS сторадж. Заставил бэкапить на NFS посредством написания скрипта из 3х строк :)
                                                        • 0
                                                          Где возможно пользуюсь ZFS снапшотами, правда пришлось шаманить с mbuffer, т.к. поверх ssh скорость передачи снапшотов печальная, но возможность полного и быстрого восстановления состояний превосходит все минусы лично для меня.
                                                          • +1
                                                            Почему Bacula так быстро создал копию, а другие в разы медленнее?
                                                            • 0
                                                              Сжатие происходит на клиенте, после чего все файлы передаются одним сжатым потоком.
                                                              Такая она быстрая и надежная, проверенная годами. Иногда месяцами не получаю писем от бакулы — зайду на сервер — а там все прекрасно ротируется :)

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

                                                            Самое читаемое