Свободная программа для резервного копирования в Windows 10 и 7. Используется веб-интерфейс на русском языке. Позволяет создавать зашифрованные резервные копии.
- Главная
- Резервное копирование
- Duplicati 2
15 апреля 2023 г. 13:28 Русский GNU LGPL v2.1
Свободный клиент резервного копирования Windows 7 и 10, который надежно сохранит данные благодаря шифрованию. Инкрементные, сжатые резервные копии могут быть перемещены в облачные хранилища и на удаленные файловые сервера. Вторая версия программы работает через веб-интерфейс. Переведен на русский язык.
Duplicati 2 работает с:
- Amazon S3;
- OneDrive;
- Google Диск;
- Rackspace Cloud Files;
- HubiC;
- Backblaze (B2);
- Amazon Cloud Drive (AmzCD);
- Swift / OpenStack;
- WebDAV;
- SSH (SFTP);
- FTP и многое другое!
Duplicati 2 работает с распространенными протоколами, например, FTP, SSH, WebDAV, и популярные сервисы, например, Microsoft OneDrive, Amazon Cloud Drive и S3, Google Drive, box.com, Mega, hubiC и множество других.
Программы для поиска и удаления дубликатов файлов на компьютере или ноутбуке 🔍🗂️💻
Резервное копирование в Windows 10 и 7 файлов и папок с мощным шифрованием AES-256. Сохранение пространства с использованием инкрементными резервными копиями и дедупликацией данных. Существует возможность запускать резервное копирование на любом компьютере через веб-интерфейс или через интерфейс командной строки. У Duplicati есть встроенный планировщик и автообновление.
Duplicati 2 можно использовать полностью бесплатно даже в коммерческих целях. Исходный код лицензируется по LGPL. Duplicati работает под Windows, Linux, MacOS. Для этого требуется .NET 4.5 или Mono.
Duplicati 2 использует мощное шифрование AES-256 для защиты конфиденциальности. Также можно использовать GPG для шифрования резервной копии.
Duplicati 2 был разработан для резервного копирования в облако. Он прекрасно справляется с сетевыми проблемами. Например, прерванные задачи резервного копирования на Windows 10 и 7 могут быть возобновлены, и Duplicati 2 регулярно проверяет содержимое резервных копий. Таким образом, резервные копии с проблемами на поврежденных системах хранения могут быть обнаружены.
Duplicati 2 настраивается при помощи веб-интерфейса, который работает в любом браузере (даже мобильном) и может быть доступен — если необходимо — откуда угодно.
Характеристики:
- первоначально Duplicati 2 загружает полную резервную копию, а далее сохраняет меньшие инкрементные обновления, чтобы сохранить пропускную способность и свободное место;
- планировщик автоматически обновляет резервные копии;
- интегрированный инструмент обновления уведомляет о выходе новой версии;
- зашифрованные резервные копии загружаются в облачные сервисы, такие как Cloudfiles, WebDAV, SSH (SFTP), Amazon S3, FTP и многие другие;
- позволяет создавать резервные копии папок, определенных типов документов, например, документов или изображений, или настраиваемые правила фильтрации;
- Duplicati 2 доступно как приложение с простым интерфейсом пользователя и инструментом командной строки;
- позволяет создавать резервные копии открытых или заблокированных файлов с помощью службы моментальных снимков тома (VSS) под Windows или Logical Volume Manager (LVM) под Linux. Это позволяет Duplicati 2 создавать резервную копию файла PST Microsoft Outlook во время работы Outlook;
- фильтры, правила удаления, параметры передачи и пропускной способности и т.д.
Источник: xn--90abhbolvbbfgb9aje4m.xn--p1ai
Что такое Dropbox и для чего он нужен?
Duplicati
Duplicati — система резервного копирования, с удобным, лёгким и приятным для глаз интерфейсом, позволяющая делать локальные и удалённые бекапы в облака или просто на удалённые хранилища.
Установка Duplicati.
В рамках этой заметки, посмотрим на Duplicati 2.0, она находится в статусе beta, но основной функционал доступен для работы уже сейчас. Для установки разработчики подготовили пакеты для всех популярных ОС, так что нам достаточно будет скачать их и поставить штатными средствами. Ставить будем на CentOS 7, здесь потребуется репозиторий EPEL.
# yum install epel-release wget # wget https://github.com/duplicati/duplicati/releases/download/v2.0.2.17-2.0.2.17_canary_2018-01-23/duplicati-2.0.2.17-2.0.2.17_canary_20180123.noarch.rpm # yum localinstall duplicati-2.0.2.17-2.0.2.17_canary_20180123.noarch.rpm
У меня, при установке на сервер, не оказалось Unit файла для запуска (возможно позже разработчики добавят его), так что я просто набросал простейший юнит для него:
# cat /etc/systemd/system/duplicati.service [Unit] Description=Duplicati backup After=network.target [Service] EnvironmentFile=-/etc/default/duplicati ExecStart=/usr/bin/duplicati-server $DAEMON_OPTS [Install] WantedBy=multi-user.target
# systemctl daemon-reload # systemctl restart duplicati
Если всё сделано верно, то на порте 8200 у нас запускается веб-интерфейс панели:
# netstat -nlp | grep mono tcp 0 127.0.0.1:8200 0.0.0.0:* LISTEN 18365/mono-sgen
И вот здесь есть важный момент — по умолчанию, в первый раз у меня duplicati запустился на локалхосте, и достучаться извне до панели я после первого запуска не мог. В данном случае помог трюк с пробросом порта по SSH:
1. На локальном ПК выполняем команду (1.2.3.4 — сервер с системой бекапа):
2. На локальном же ПК, открываем в браузере адрес http://127.0.0.1:8888 и получаем доступ к панели управления.
Настройка Duplicati.
При первом запуске и доступе в панель, система попросит нас указать пароль для авторизации, конечно же соглашаемся с этим и оказываемся в настройках. Здесь мы указываем пароль, разрешаем удалённый доступ к панели, выбираем язык, при необходимости скрываем донат и выбираем тему оформления.
Здесь же, в нижней части страницы доступен расширенный редактор дополнительных настроек, но к нему имеет смысл обращаться только если это действительно необходимо. Заданные по умолчанию настройки подходят для большинства возникающих у администратора задач.
Когда удалённый доступ в панель будет разрешён, перезапускаем сервис duplicati на сервере, и убеждаемся что теперь он слушает внешний интерфейс:
# netstat -nlp | grep mono
tcp 0 0.0.0.0:8200 0.0.0.0:* LISTEN 18365/mono-sgen
К слову, выполнив команду:
Резервное копирование, часть 3: Обзор и тестирование duplicity, duplicati
В данной статье рассмотрены средства резервного копирования, которые выполняют резервное копирование путем создания архивов на резервном сервере.
Из тех, которые удовлетворяют требованиям — duplicity (к которому есть приятный интерфейс в виде deja dup) и duplicati.
Еще одно весьма примечательное средство резервного копирования — dar, но поскольку у него имеется весьма обширный список опций — методика тестирования покрывает едва ли 10% от того, на что он способен, — его в рамках текущего цикла не тестируем.
Ожидаемые результаты
Поскольку оба кандидата так или иначе создают архивы, то в качестве ориентира можно использовать обычный tar.
Дополнительно оценим, насколько хорошо оптимизируется хранение данных на сервере хранения путем создания резервных копий, содержащих только разницу между полной копией и текущим состоянием файлов, или между прошлым и текущим архивами (инкрементальные, декрементальные и т.п.).
Поведение при создании резервных копий:
- Сравнительно небольшое число файлов на сервере хранения резервных копий (сравнимо с числом резервных копий или размером данных в гб), но достаточно большой их размер (десятки-сотни мегабайт).
- Размер репозитория будет включать только изменения — дубликаты не будут храниться, таким образом размер репозитория будет меньше, чем при работе ПО на основе rsync.
- Ожидается большая нагрузка на процессор при использовании сжатия и/или шифрования, а также, вероятно, достаточно большая нагрузка на сеть и дисковую подсистему, если процесс архивации и/или шифрования будет работать на сервере хранения резервных копий.
В качестве эталонного значения запустим следующую команду:
cd /src/dir; tar -cf — * | ssh backup_server «cat > /backup/dir/archive.tar»
Результаты выполнения получились такие:
Время выполнения 3m12s. Видно, что скорость уперлась в дисковую подсистему сервера хранения резервных копий, как и в примере с rsync. Только чуть быстрее, т.к. запись идет в один файл.
Также для оценки сжатия запустим тот же вариант, но включим сжатие на стороне сервера резервного копирования:
cd /src/dir; tar -cf — * | ssh backup_server «gzip > /backup/dir/archive.tgz»
Время выполнения 10m11s. Вероятнее всего, узкое место — однопоточный компрессор на принимающей стороне.
Та же команда, но с переносом сжатия на сервер с исходными данными для проверки гипотезы, что узкое место — однопоточный компрессор.
cd /src/dir; tar -czf — * | ssh backup_server «cat > /backup/dir/archive.tgz»
Время выполнения составило 9m37s. Явно видно загрузку одного ядра компрессором, т.к. скорость передачи по сети и нагрузка на дисковую подсистему источника — аналогичные.
Для оценки шифрования можно использовать openssl или gpg, подключая дополнительную команду openssl или gpg в pipe. Для ориентира будет такая команда:
cd /src/dir; tar -cf — * | ssh backup_server «gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc»
Результаты вышли такие:
Время выполнения получилось 10m30s, поскольку запущено 2 процесса на принимающей стороне — узкое место опять однопоточный компрессор, плюс небольшие накладные расходы на шифрование.
UPD: По просьбе bliznezz добавляю тесты с pigz. Если использовать только компрессор — получилось за 6m30s, если еще добавить и шифрование — примерно 7m. Провал на нижнем графике — несброшенный дисковый кэш:
Тестирование duplicity
Duplicity — программное обеспечение на python для резервного копирования путем создания шифрованных архивов в формате tar.
Для инкрементальных архивов применяется librsync, следовательно, можно ожидать поведения, описанного в предыдущей заметке цикла.
Резервные копии могут шифроваться и подписываться с помощью gnupg, что немаловажно при использовании различных провайдеров для хранения резервных копий (s3, backblaze, gdrive и т.п.)
Посмотрим, какие будут результаты:
Вот такие результаты получились при запуске без шифрования
Время работы каждого тестового запуска:
| 16m33s | 17m20s | 16m30s |
| 8m29s | 9m3s | 8m45s |
| 5m21s | 6m04s | 5m53s |
А вот результаты при включении шифрования gnupg, с размером ключа 2048 бит:
Время работы на тех же данных, с шифрованием:
| 17m22s | 17m32s | 17m28s |
| 8m52s | 9m13s | 9m3s |
| 5m48s | 5m40s | 5m30s |
Был указан размер блока — 512 мегабайт, что отчетливо видно на графиках; загрузка процессора фактически держалась на уровне 50%, значит, программа утилизирует не более одного процессорного ядра.
Также достаточно хорошо видно принцип работы программы: взяли кусочек данных, пожали его, отправили на сервер хранения резервных копий, который может быть достаточно медленным.
Еще одна особенность — предсказуемое время работы программы, которое зависит только от размера измененных данных.
Включение шифрования не особенно увеличило время работы программы, но повысило загрузку процессора примерно на 10%, что может быть весьма неплохим приятным бонусом.
К сожалению, данная программа не смогла корректно обнаружить ситуацию с переименованием каталога, и результирующий размер репозитория оказался равен размеру изменений (т.е. все 18гб), но возможность использовать недоверенный сервер для резервного копирования однозначно перекрывает такое поведение.
Тестирование duplicati
Данное программное обеспечение написано на C#, запускается, используя набор библиотек от Mono. Имеется GUI, а также cli версия.
Примерный список основных возможностей близок к duplicity, включая различных провайдеров для хранения резервных копий, однако, в отличие от duplicity, большинство возможностей доступно без сторонних средств. Плюс это или минус — зависит от конкретного случая, однако для новичков, вероятнее всего, проще иметь перед глазами список сразу всех возможностей, нежели доустанавливать пакеты для python, как в случае с duplicity.
Еще один небольшой нюанс — программа активно пишет локальную базу sqlite от имени того пользователя, который запускает резервное копирование, поэтому нужно дополнительно следить за корректным указанием нужной базы при каждом запуске процесса используя cli. При работе через GUI или WEBGUI детали будут скрыты от пользователя.
Давайте посмотрим, какие показатели может выдать данное решение:
Если выключить шифрование (причем WEBGUI делать этого не рекомендует), результаты таковы:
| 20m43s | 20m13s | 20m28s |
| 5m21s | 5m40s | 5m35s |
| 7m36s | 7m54s | 7m49s |
С включенным шифрованием, используя aes, получается так:
| 29m9s | 30m1s | 29m54s |
| 5m29s | 6m2s | 5m54s |
| 8m44s | 9m12s | 9m1s |
А если использовать внешнюю программу gnupg, выходят такие результаты:
| 26m6s | 26m35s | 26m17s |
| 5m20s | 5m48s | 5m40s |
| 8m12s | 8m42s | 8m15s |
Как видно — программа умеет работать в несколько потоков, но от этого не является более производительным решением, а если сравнивать работу шифрования — запуск внешней программы
получился более быстрым, чем применение библиотеки из набора Mono. Возможно, это связано с тем, что внешняя программа больше оптимизирована.
Приятным моментом также стал тот факт, что размер репозитория занимает ровно столько, сколько реально было измененных данных, т.е. duplicati обнаружил переименование каталога и корректно обработал данную ситуацию. Это можно увидить при прогоне второго теста.
В целом, достаточно положительные впечатления от программы, включая достаточную дружелюбность к новичкам.
Результаты
Оба кандидата достаточно неспешно отработали, но в целом, по сравнению с обычным tar, есть прогресс, как минимум у duplicati. Цена такого прогресса также понятна — заметная нагрузка
процессора. В целом, никаких особых отклонений при прогнозировании результатов нет.
Выводы
Если никуда спешить не нужно, а также есть запас по процессору — подойдет любое из рассмотренных решений, во всяком случае проделана достаточно большая работа, которую не стоит повторять путем написания скриптов-оберток поверх tar. Наличие шифрования весьма нужное свойство, если сервер для хранения резервных копий не может быть полностью доверенным.
Если сравнивать с решениями на основе rsync — производительность может быть хуже в несколько раз, несмотря на то, что в чистом виде tar отработал быстрее rsync на 20-30%.
Экономия на размере репозитория есть, но только у duplicati.
Источник: habr.com