DUPLICITY(1) Довідкові матеріали DUPLICITY(1)
НАЗВА
duplicity - Шифроване інкрементне резервне копіювання на локальне або віддалене сховище.
СИНТАКСИС
Для детальних описів кожної дії дивіться розділ ДІЇ.
duplicity [backup|full|incremental] [options] source_directory target_url
duplicity verify [options] [--compare-data] [--path-to-restore <relpath>] [--time time] source_url target_directory
duplicity collection-status [options] [--file-changed <relpath>] [--show-changes-in-set <index>] [--jsonstat]] target_url
duplicity list-current-files [options] [--time time] target_url
duplicity [restore] [options] [--path-to-restore <relpath>] [--time time] source_url target_directory
duplicity remove-older-than <time> [options] [--force] target_url
duplicity remove-all-but-n-full <count> [options] [--force] target_url
duplicity remove-all-inc-of-but-n-full <count> [options] [--force] target_url
duplicity cleanup [options] [--force] target_url
ОПИС
Duplicity виконує інкрементне резервне копіювання файлів і папок у томи формату tar, зашифровані за допомогою GnuPG, і розміщує їх у віддаленому (або локальному) сховищі. Дивіться розділ ФОРМАТ URL для списку всіх підтримуваних сховищ і способів їх адресації. Завдяки використанню librsync інкрементні резервні копії є ефективними за обсягом і записують лише ті частини файлів, які змінилися з часу останнього резервного копіювання.
Наразі duplicity підтримує видалені файли, повні права доступу Unix, uid/gid, каталоги, символічні посилання, fifo тощо, але не підтримує жорсткі посилання.
Якщо ви створюєте резервну копію кореневого каталогу /, не забудьте використати --exclude /proc, інакше duplicity, ймовірно, завершиться помилкою через незвичайний вміст у цьому каталозі.
ПРИКЛАДИ
Ось приклад резервного копіювання, що використовує sftp для збереження /home/me у папку some_dir на машині other.host:
duplicity /home/me sftp://uid@other.host/some_dir
Якщо виконувати цю команду повторно, перше виконання буде повним резервним копіюванням, а наступні — інкрементними. Щоб примусово виконати повне резервне копіювання, використовуйте дію full:
duplicity full /home/me sftp://uid@other.host/some_dir
або примусове виконання повного резервного копіювання щоразу через місяць за допомогою --full-if-older-than <time>:
duplicity --full-if-older-than 1M /home/me sftp://uid@other.host/some_dir
Припустимо, ми випадково видалили /home/me і хочемо відновити його таким, яким він був на момент останнього резервного копіювання:
duplicity sftp://uid@other.host/some_dir /home/me
Duplicity переходить у режим відновлення, оскільки URL вказаний перед локальним каталогом. Якщо ми хочемо відновити лише файл "Mail/article" у /home/me таким, яким він був три дні тому, у /home/me/restored_file:
duplicity -t 3D --path-to-restore Mail/article sftp://uid@other.host/some_dir /home/me/restored_file
Наступна дія порівнює останню резервну копію з поточними файлами:
duplicity verify sftp://uid@other.host/some_dir /home/me
Нарешті, duplicity підтримує кілька опцій включення/виключення. Наприклад, наступна команда створить резервну копію кореневого каталогу, але виключить /mnt, /tmp і /proc:
duplicity --exclude /mnt --exclude /tmp --exclude /proc / file:///usr/local/backup
У цьому випадку призначенням є локальний каталог /usr/local/backup. Наступна команда створить резервну копію лише каталогів /home і /etc у кореневому каталозі:
duplicity --include /home --include /etc --exclude '**' / file:///usr/local/backup
Duplicity також може отримувати доступ до репозиторію через ftp. Якщо вказано ім’я користувача, змінна середовища BACKEND_PASSWORD читається для визначення пароля:
BACKEND_PASSWORD=mypassword duplicity /local/dir ftp://user@other.host/some_dir
ДІЇ
Duplicity використовує дії, які можуть бути вказані у довгій або короткій формі та налаштовані за допомогою опцій.
Дії 'backup' або 'restore' можуть бути визначені з порядку вказання локального шляху та віддаленого URL. Інші дії потрібно вказувати явно. У рідкісних випадках, коли локальний шлях може бути сприйнятий як назва дії duplicity, до локального шляху можна додати '/' для уникнення помилки.
ПРИМІТКА: Наступні пояснення описують лише деякі опції, які можуть використовуватися з цією дією. Дивіться розділ ОПЦІЇ для детальніших описів.
backup, bu <folder> <url>
Виконує резервне копіювання. Duplicity автоматично виконує інкрементне резервне копіювання, якщо знайдені старі сигнатури. Інакше починається новий ланцюжок резервного копіювання.
full, fb <folder> <url>
Виконує повне резервне копіювання. Новий ланцюжок резервного копіювання починається навіть за наявності сигнатур для інкрементного резервного копіювання.
incremental, ib <folder> <url>
Якщо це вказано, виконується інкрементне резервне копіювання. Duplicity припинить роботу, якщо старі сигнатури не будуть знайдені.
verify, vb [--compare-data] [--time <time>] [--path-to-restore <rel_path>] <url> <local_path>
Перевіряє цілісність архівів резервного копіювання у віддаленому місці, завантажуючи кожен файл і перевіряючи, чи можна відновити архів і чи відповідає відновлений файл сигнатурі, збереженій у резервній копії, тобто порівнює архівований файл із його хеш-значенням на момент архівації. Verify не виконує фактичного відновлення і не перезаписує локальні файли.
Duplicity завершується з ненульовим рівнем помилки, якщо будь-які файли не відповідають збереженій сигнатурі. На рівні деталізації 4 або вище буде записано повідомлення для кожного файлу, що відрізняється від збереженої сигнатури. Файли необхідно завантажити на локальну машину для порівняння. Verify не порівнює архівовану версію файлу з поточною локальною копією, якщо не використовується опція --compare-data (див. нижче).
Опція --path-to-restore обмежує перевірку до цього файлу або папки. Опція --time дозволяє вибрати резервну копію для перевірки. Опція --compare-data вмикає порівняння даних (див. нижче).
collection-status, st [--file-changed <relpath>] [--show-changes-in-set <index>] <url>
Підсумовує стан репозиторію резервного копіювання, виводячи ланцюжки та набори, знайдені, а також кількість томів у кожному.
Опція --file-changed підсумовує зміни у файлі (в останньому ланцюжку резервного копіювання). Опція --show-changes-in-set підсумовує всі зміни файлів у наборі резервного копіювання за індексом (де індекс 0 означає останній набір, 1 — передостанній тощо). --jsonstat виводить зміни у форматі JSON і статистику з файлів jsonstat, якщо резервні копії створювалися з --jsonstat. Якщо <index> встановлено на -1, виводиться статистика для всього ланцюжка резервного копіювання.
list-current-files, ls [--time <time>] <url>
Перелічує файли, що містяться в останній резервній копії або резервній копії на вказаний час. Інформація витягується із сигнатурних файлів, а не з даних архіву. Таким чином, весь архів не потрібно завантажувати, але якщо архів був видалений або пошкоджений, ця дія не виявить цього.
restore, rb [--path-to-restore <relpath>] [--time <time>] <url> <target_folder>
Ви можете відновити повний вміст або вибрані папки/файли з певного часу. Використовуйте відносний шлях, як він виводиться командою list-current-files. Зазвичай не потрібна, оскільки duplicity переходить у режим відновлення, коли виявляє, що URL вказаний перед локальною папкою.
remove-older-than, ro <time> [--force] <url>
Видаляє всі набори резервних копій, старіші за вказаний час. Старі набори резервних копій не будуть видалені, якщо від них залежать новіші набори. Дивіться розділ ФОРМАТИ ЧАСУ для додаткової інформації. Зверніть увагу,
що цю дію не можна поєднувати з резервним копіюванням або іншими діями, такими як очищення. Також потрібна опція --force для видалення файлів, а не лише їх переліку.
remove-all-but-n-full, ra <count> [--force] <url>
Видаляє всі набори резервних копій, старіші за count-ну останню повну резервну копію (іншими словами, зберігає останні count повних резервних копій та пов’язані з ними інкрементні набори). count має бути більшим за нуль. Значення 1 означає, що буде збережений лише останній ланцюжок резервного копіювання. Зверніть увагу, що потрібна опція --force для видалення файлів, а не лише їх переліку.
remove-all-inc-of-but-n-full, ri <count> [--force] <url>
Видаляє інкрементні набори всіх резервних копій, старіших за count-у останню повну резервну копію (іншими словами, зберігає лише старі повні резервні копії без їхніх інкрементів). count має бути більшим за нуль. Значення 1 означає, що буде збережений лише останній ланцюжок резервного копіювання у повному обсязі. Зверніть увагу, що потрібна опція --force для видалення файлів, а не лише їх переліку.
cleanup, cl [--force] <url>
Видаляє зайві файли duplicity у вказаному сховищі. Некритичні файли або файли в повних наборах даних не будуть видалені. Це необхідно лише після невдалого або перерваного сеансу duplicity. Зверніть увагу, що потрібна опція --force для видалення файлів, а не лише їх переліку.
ОПЦІЇ
--allow-source-mismatch
Не припиняє роботу при спробі використовувати той самий архівний каталог або віддалене сховище для резервного копіювання різних каталогів. duplicity повідомить, якщо потрібна ця опція.
--archive-dir path
Каталог для архівів.
ПРИМІТКА: Ця опція змінилася у версії 0.6.0. Каталог архівів тепер необхідний для управління персистентністю для поточних і майбутніх покращень. Таким чином, ця опція використовується лише для зміни розташування каталогу архівів. Каталог архівів не слід видаляти, інакше duplicity доведеться відтворювати його з віддаленого репозиторію (що може вимагати розшифрування вмісту резервної копії).
Під час резервного копіювання або відновлення ця опція вказує, що локальний каталог архівів має бути створений у path. Якщо каталог архівів не вказано, за замовчуванням він буде створений у ~/.cache/duplicity/.
Каталог архівів може бути спільним для кількох резервних копій у різних цільових сховищах, оскільки для окремих резервних копій використовується підкаталог архівного каталогу (див. --name).
Комбінація каталогу архівів і назви резервної копії має бути унікальною, щоб розділити дані різних резервних копій.
Взаємодія між опціями --archive-dir і --name дозволяє чотири можливі комбінації для розташування каталогу архівів:
1. жоден не вказано (за замовчуванням)
~/.cache/duplicity/hash-of-url
2. --archive-dir=/arch, без --name
/arch/hash-of-url
3. без --archive-dir, --name=foo
~/.cache/duplicity/foo
4. --archive-dir=/arch, --name=foo
/arch/foo
--asynchronous-upload
(ПРИПИНЕНО) Ця опція припинена через нестабільність. Замість неї використовується '--concurrency'.
--azure-blob-tier
Стандартний рівень зберігання, що використовується для файлів резервного копіювання (Hot|Cool|Archive).
--azure-max-single-put-size
Вказує максимальний розмір завантаження, який підтримується, коли бібліотека Azure виконує лише один виклик put. Якщо розмір вмісту відомий і менший за це значення, бібліотека Azure виконає лише один запит put для завантаження одного блоку. Очікується, що число буде в байтах.
--azure-max-block-size
Вказує розмір блоку, який використовується бібліотекою Azure для завантаження блобів, якщо вони розбиваються на кілька блоків. Максимальний розмір блоку, який підтримує служба, становить 104857600 (100 МБ), а за замовчуванням — 4194304 (4 МБ).
--azure-max-connections
Вказує максимальну кількість з’єднань для передачі одного блобу, якщо розмір блобу перевищує 64 МБ. За замовчуванням значення становить 2.
--b2-hide-files
Змушує Duplicity приховувати файли в B2 замість їх видалення. Корисно в поєднанні з правилами життєвого циклу B2.
--backend-retry-delay number
Вказує кількість секунд, які duplicity чекає після виникнення помилки перед повторною спробою операції.
--cf-backend backend
Дозволяє явно вибрати бекенд cloudfiles. За замовчуванням використовується pyrax. Альтернативою може бути cloudfiles.
--concurrency number
Вказує кількість фонових процесів, які слід використовувати для виконання паралельних завдань бекенду. Це відокремлює локальні операції, такі як шифрування/розшифрування, створення томів тощо, від передачі до/з бекендів.
Метою є прискорення резервного копіювання за рахунок більш ефективного використання локального процесора та пропускної здатності мережі. Використання цієї опції вимагає додаткового дискового простору в тимчасовому сховищі; замість одного тому одночасно потрібно місце для зберігання n+1 томів. Залежно від бекенду та мережі паралельні операції можуть прискорити процес. Хорошим початковим значенням для concurrency є 1-4. Перегляньте статистику duplicity для тонкого налаштування. У більшості випадків це не повинно перевищувати кількість ядер процесора вашої системи мінус один.
--config-dir path
Дозволяє вибрати каталог конфігурації duplicity. За замовчуванням — ~/.config/duplicity.
--copy-blocksize kilos
Дозволяє вибрати розмір блоку в кілобайтах для копіювання. Збільшення цього значення може прискорити копіювання великих файлів. За замовчуванням — 128.
--no-check-remote
Вимикає перевірку віддаленого маніфесту. Перевірка є за замовчуванням. Відсутність перевірки дозволяє створювати резервну копію без приватного ключа, але це означає, що віддалений маніфест може існувати і бути пошкодженим, що може призвести до неможливості відновлення резервної копії.
--compare-data
Вмикає порівняння даних звичайних файлів під час дії verify. Це виконує перевірку, як описано вище, для підтвердження цілісності архівів резервного копіювання, але додатково порівнює відновлені файли з тими, що знаходяться в target_directory. Duplicity не замінить жодних файлів у target_directory. Duplicity завершується з ненульовим рівнем помилки, якщо файли не перевіряються коректно або якщо будь-які файли з архіву відрізняються від тих, що в target_directory. На рівні деталізації 4 або вище буде записано повідомлення для кожного файлу, що відрізняється від його еквівалента в target_directory.
--copy-links
Розв’язує символічні посилання під час резервного копіювання. Увімкнення цієї опції призведе до резервного копіювання даних файлу/папки, на які вказує символічне посилання, замість самого посилання, що може збільшити розмір резервної копії.
--dry-run
Розраховує, що було б зроблено, але не виконує жодних дій із бекендом.
--encrypt-key key-id
Під час резервного копіювання шифрує за допомогою вказаного публічного ключа замість симетричного (традиційного) шифрування. Може бути вказано кілька разів. key-id може бути вказаний у будь-якому форматі, підтримуваному GnuPG; дивіться gpg(1), розділ "HOW TO SPECIFY A USER ID" для деталей.
--encrypt-secret-keyring filename
Ця опція може використовуватися лише з --encrypt-key і змінює шлях до секретного кільця ключів для ключа шифрування на filename. Це кільце ключів не використовується під час створення резервної копії. Якщо не вказано, використовується стандартне секретне кільце ключів, яке зазвичай розташоване в .gnupg/secring.gpg.
--encrypt-sign-key key-id
Зручний параметр. Те саме, що --encrypt-key key-id --sign-key key-id.
--exclude shell_pattern
Виключає файл або файли, що відповідають шаблону shell_pattern. Якщо відповідає каталог, файли в цьому каталозі також будуть виключені. Дивіться розділ ВИБІР ФАЙЛІВ для додаткової інформації.
--exclude-device-files
Виключає всі файли пристроїв. Це може бути корисним з міркувань безпеки/дозволів або якщо duplicity неправильно обробляє файли пристроїв.
--exclude-filelist filename
Виключає файли, перелічені у filename, при цьому кожний рядок списку файлів інтерпретується за тими ж правилами, що й --include та --exclude. Дивіться розділ ВИБІР ФАЙЛІВ для додаткової інформації.
--exclude-if-present filename
Виключає каталоги, якщо присутній filename. Дозволяє користувачу вказати папки, які він не бажає резервувати, додаючи певний файл (наприклад, ".nobackup") замість ведення повного списку виключень/включень.
--exclude-older-than time
Виключає будь-які файли, дата модифікації яких раніше за вказаний час. Це може бути використано для створення часткової резервної копії, що містить лише нещодавно змінені файли. Дивіться розділ ФОРМАТИ ЧАСУ для додаткової інформації.
--exclude-other-filesystems
Виключає файли на файлових системах (визначених за номером пристрою), крім файлової системи, на якій розташований корінь вихідного каталогу.
--exclude-regexp regexp
Виключає файли, що відповідають вказаному регулярному виразу. На відміну від опції --exclude, ця опція не відповідає файлам у каталозі, який вона виключає. Дивіться розділ ВИБІР ФАЙЛІВ для додаткової інформації.
--files-from filename
Читає список файлів для резервного копіювання з filename, замість пошуку в усьому вихідному каталозі. Операція в іншому виконується як зазвичай, лише для вказаного підмножини вихідного каталогу.
Файли мають бути вказані по одному на рядок і відносно вихідного каталогу. Абсолютні шляхи викликають помилку. Усі символи в рядку вважаються частиною шляху, включаючи початкові та кінцеві пробіли. Рядки розділяються новими рядками або нулями, залежно від того, чи використовується перемикач --null-separator.
Не потрібно включати батьківський каталог вказаних файлів, їх включення мається на увазі. Однак вміст явно вказаних каталогів не мається на увазі. Усі необхідні файли повинні бути перелічені, коли використовується ця опція.
--file-prefix prefix
--file-prefix-manifest prefix
--file-prefix-archive prefix
--file-prefix-signature prefix
Додає префікс до всіх файлів або лише до маніфестів, архівів, сигнатурних файлів. Той самий набір префіксів необхідно передати під час резервного копіювання та відновлення.
Якщо встановлені як глобальні, так і специфічні для типу префікси, глобальний префікс буде передувати специфічним для типу префіксам.
Дивіться також ПРИМІТКА ПРО ПРЕФІКСИ НАЗВ ФАЙЛІВ
--path-to-restore path
Ця опція може бути вказана в режимі відновлення, що призведе до відновлення лише path замість усього вмісту архіву резервної копії. path має бути вказаний відносно кореня каталогу, що резервується.
--filter-globbing
--filter-ignorecase
--filter-literal
--filter-regexp
--filter-strictcase
Змінює інтерпретацію шаблонів, переданих опціям вибору файлів --exclude та --include (і їх варіаціям, включаючи списки файлів). Ці опції можуть з’являтися кілька разів, щоб перемикатися між шаблонами оболонки (за замовчуванням), літералами та регулярними виразами, з урахуванням регістру (за замовчуванням) чи без нього. Вказана інтерпретація застосовується до всіх наступних умов вибору до наступної опції --filter.
Дивіться розділ ВИБІР ФАЙЛІВ для додаткової інформації.
--full-if-older-than time
Виконує повне резервне копіювання, якщо запитано інкрементне резервне копіювання, але останнє повне резервне копіювання в колекції старіше за вказаний час. Дивіться розділ ФОРМАТИ ЧАСУ для додаткової інформації.
--force
Продовжує виконання, навіть якщо це може призвести до втрати даних. Duplicity повідомить, коли ця опція потрібна.
--ftp-passive
Використовує пасивні (PASV) з’єднання даних. За замовчуванням використовується пасивне з’єднання, але якщо воно не вдається або завершується за тайм-аутом, застосовується звичайне.
--ftp-regular
Використовує звичайні (PORT) з’єднання даних.
--gio
Використовує бекенд GIO і інтерпретує будь-які URL як це робить GIO.
--gpg-binary file_path
Дозволяє примусово використовувати file_path як бінарний файл командного рядка gpg. Може бути абсолютним або відносним шляхом до файлу або назвою файлу. За замовчуванням — 'gpg'. Бінарний файл буде локалізований через змінну середовища PATH.
--gpg-options='options'
Дозволяє передавати опції для шифрування gpg. Список опцій має бути у формі '--opt1 --opt2=val2', де рядок взятий у лапки, а єдині дозволені пробіли — між опціями.
ПРИМІТКА: Значення цієї опції має бути зв’язане з '=' як у
--gpg-options='--gpg-option=value'
Дивіться ПРОБЛЕМА ARGPARSE для деталей.
--hidden-encrypt-key key-id
Те саме, що --encrypt-key, але приховує ідентифікатор ключа користувача у зашифрованому файлі. Використовує команду gpg --hidden-recipient для приховування власника резервної копії. Під час відновлення gpg автоматично спробує всі доступні секретні ключі для розшифрування резервної копії. Дивіться gpg(1) для деталей.
--ignore-errors
Намагається ігнорувати певні помилки, якщо вони виникають. Ця опція призначена лише для дозволу відновлення резервної копії у разі певних проблем, які інакше призвели б до її невдачі. Її ніколи не рекомендується використовувати, якщо у вас немає ситуації, коли ви намагаєтесь відновити резервну копію і вона не вдається через проблему, яку ви хочете, щоб duplicity проігнорував. Навіть у цьому випадку, залежно від проблеми, ця опція може не мати ефекту.
Зверніть увагу, що хоча ігноровані помилки будуть записані в лог, у кінці операції не буде підсумку, який би вказував, що було проігноровано, якщо взагалі щось було. Якщо ця опція використовується для аварійного відновлення даних, рекомендується виконувати резервне копіювання так, щоб можна було переглянути лог резервного копіювання (шукайте рядки, що містять рядок IGNORED_ERROR).
Якщо вам доводиться використовувати цю опцію з причин, які не зрозумілі або зрозумілі, але не є вашою відповідальністю, будь ласка, зверніться до розробників duplicity. Необхідність використання цієї опції в робочих умовах зазвичай вважається помилкою.
--imap-full-address email_address
Повна адреса електронної пошти імені користувача під час входу на сервер IMAP. Якщо не вказано, використовується лише частина імені користувача електронної адреси.
--imap-mailbox option
Дозволяє вказати іншу поштову скриньку. За замовчуванням — "INBOX". Для інших мов може знадобитися інша поштова скринька.
--idr-fakeroot
idrived використовує концепцію "fakeroot" каталогу, визначеного через перемикач --idr-fakeroot=.... Це може бути існуючий каталог, або каталог створюється під час виконання на корені файлової системи (застереження: ви повинні мати доступ до запису в корінь!). Каталоги, створені під час виконання, автоматично видаляються після завершення!
Отже, у вищенаведеній схемі ми можемо зробити:
duplicity --idr-fakeroot=nicepath idrived://DUPLICITY
наші файли опиняться в
<MYBUCKET>/DUPLICITY/nicepath
--include shell_pattern
Аналогічно до --exclude, але включає відповідні файли. На відміну від --exclude, ця опція також відповідає батьківським каталогам відповідних файлів (хоча не обов’язково їх вмісту). Дивіться розділ ВИБІР ФАЙЛІВ для додаткової інформації.
--include-filelist filename
Аналогічно до --exclude-filelist, але включає перелічені файли. Дивіться розділ ВИБІР ФАЙЛІВ для додаткової інформації.
--include-regexp regexp
Включає файли, що відповідають регулярному виразу regexp. Лише файли, явно відповідні regexp, будуть включені цією опцією. Дивіться розділ ВИБІР ФАЙЛІВ для додаткової інформації.
--jsonstat
Записує статистичні дані, подібні до стандартної статистики, що виводиться в кінці завдання резервного копіювання, додатково включає деякі метадані про ланцюжок резервного копіювання, наприклад, коли було створено повне резервне копіювання і скільки інкрементних резервних копій було зроблено до цього. Формат виведення — JSON. Виводиться на stdout на рівні notice (як класична статистика), а статистика зберігається як окремий файл поруч із маніфестом, але з розширенням "jsonstat". collection-status --show-changes-in-set <index> --jsonstat додає дані, зібрані під час завдання резервного копіювання, і перемикає формат виведення на JSON. Якщо <index> встановлено на -1, виводиться статистика для всього ланцюжка резервного копіювання.
--log-fd number
Записує спеціально відформатовані версії вихідних повідомлень у вказаний дескриптор файлу. Використаний формат призначений для легкого споживання іншими програмами.
--log-file filename
Записує спеціально відформатовані версії вихідних повідомлень у вказаний файл. Використаний формат призначений для легкого споживання іншими програмами.
--log-timestamp
Записує лог із міткою часу та рівнем логу перед повідомленням, подібно до syslog.
--max-blocksize number
Обмежує максимальний розмір блоків, що перевіряються на зміни під час процесу diff.
За замовчуванням використовується ціле квадратне кореня з довжини файлу як розмір блоку librsync. Мінімум становить 512 байт без максимуму, якщо не вказано --max-blocksize. Розмір блоку округляється до найближчої межі 512 байт.
Якщо ви вкажете більший max_blocksize, ваші файли difftar будуть більшими, але файли sigtar — меншими. Якщо ви вкажете менший max_blocksize, відбудеться зворотне.
Опція --max-blocksize має бути кратною 512.
За замовчуванням max_blocksize не вказано.
--mf-purge
Опція для mediafire для очищення файлів при видаленні замість відправлення в кошик.
--mp-segment-size megs
Розмір сегмента бекенду Swift у мегабайтах.
--name symbolicname
Встановлює символічну назву резервної копії, над якою виконується операція. Мета — використовувати окрему назву для кожної логічно окремої резервної копії. Наприклад, хтось може використовувати "home_daily_s3" для щоденного резервного копіювання домашнього каталогу в Amazon S3. Структура назви залежить від користувача, важливо лише, щоб назви були різними. Символічна назва наразі використовується лише для впливу на розширення --archive-dir, але в майбутньому може використовуватися для додаткових функцій. Користувачам, які виконують більше однієї окремої резервної копії, рекомендується використовувати цю опцію.
Якщо не вказано, за замовчуванням використовується хеш URL бекенду.
--no-check-remote
Вимикає перевірку віддаленого маніфесту. Перевірка є за замовчуванням. Відсутність перевірки дозволяє створювати резервну копію без приватного ключа, але це означає, що віддалений маніфест може існувати і бути пошкодженим, що може призвести до неможливості відновлення резервної копії.
--no-compression
Не використовує GZip для стиснення файлів у віддаленій системі.
--no-encryption
Не використовує GnuPG для шифрування файлів у віддаленій системі.
--no-print-statistics
За замовчуванням duplicity виводить статистику про поточний сеанс після успішного резервного копіювання. Цей перемикач вимикає цю поведінку.
--no-files-changed
За замовчуванням duplicity збирає назви файлів і дії зі змінами (додавання, видалення, зміна) у пам’яті під час резервного копіювання. Це може бути досить витратним за пам’яттю, особливо для мільйонів маленьких файлів. Цей прапорець вимикає цю збірку. Це означає, що опція --file-changed для collection-status не поверне нічого.
--null-separator
Використовує нулі (\0) замість нових рядків (\n) як роздільники рядків, що може допомогти при роботі з іменами файлів, що містять нові рядки. Це впливає на очікуваний формат файлів, указаних за допомогою перемикачів --{include|exclude}-filelist і опції --{files-from}, а також на формат файлу статистики каталогів.
--numeric-owner
Під час відновлення завжди використовує числові uid/gid з архіву, а не архівовані імена користувачів/груп, що є поведінкою за замовчуванням. Рекомендується для відновлення з живих CD, де користувачі з однаковими іменами можуть мати різні uid/gid.
--no-restore-ownership
Ігнорує uid/gid з архіву і зберігає поточного користувача. Рекомендується для відновлення даних на змонтовані файлові системи, які не підтримують власність Unix, або коли привілеї root недоступні.
--num-retries number
Кількість повторних спроб при помилках перед завершенням.
--par2-options='options'
Дослівні опції для передачі par2.
ПРИМІТКА: Значення цієї опції має бути зв’язане з '=' як у
--par2-options='-a -b'
Дивіться ПРОБЛЕМА ARGPARSE для деталей.
--par2-redundancy percent
Налаштовує рівень надлишковості у відсотках для файлів відновлення Par2 (за замовчуванням 10%).
--par2-volumes number
Кількість томів Par2 для створення (за замовчуванням 1).
--progress
При виборі цієї опції duplicity виводить поточний прогрес завантаження та оцінку часу завантаження. Для анотації змін він спочатку виконує пробний запуск перед повним або інкрементним резервним копіюванням, а потім виконує реальну операцію, оцінюючи реальний прогрес завантаження.
--progress-rate number
Встановлює частоту оновлення, з якою duplicity виводить повідомлення про прогрес завантаження (потрібна опція --progress). За замовчуванням статус виводиться кожні 3 секунди.
--rename <original path> <new path>
Вважає шлях orig у резервній копії таким, ніби це шлях new. Може бути передано кілька разів. Приклад:
duplicity restore --rename Documents/metal Music/metal sftp://uid@other.host/some_dir /home/me
--rsync-options='options'
Дозволяє передавати опції бекенду rsync. Список опцій має бути у формі "opt1=parm1 opt2=parm2", де рядок опцій взятий у лапки, а єдині дозволені пробіли — між опціями. Рядок опцій передається дослівно rsync після будь-яких внутрішньо згенерованих опцій, що визначають віддалений порт. Ось приклад, який може бути корисним:
duplicity --rsync-options="--partial-dir=.rsync-partial" /home/me rsync://uid@other.host/some_dir
ПРИМІТКА: Значення цієї опції має бути зв’язане з '=' як у
--rsync-options='--partial-dir=.rsync-partial'
Дивіться ПРОБЛЕМА ARGPARSE для деталей.
--s3-endpoint-url url
Вказує URL кінцевої точки сховища S3.
--s3-multipart-chunk-size
Розмір фрагмента (у МБ, за замовчуванням 20 МБ), що використовується для багатокомпонентного завантаження S3. Налаштуйте це для максимізації використання пропускної здатності. Наприклад, розмір фрагмента 10 МБ і volsize 100 МБ призведуть до 10 фрагментів на завантаження тому.
ПРИМІТКА: Це значення оптимально має бути кратним вашому --volsize для найкращої продуктивності.
Дивіться також ПРИМІТКА ПРО AMAZON S3 нижче.
--s3-multipart-max-procs
Максимальна кількість одночасних завантажень під час багатокомпонентного завантаження. За замовчуванням — 4. Ви можете налаштувати це число для максимізації використання пропускної здатності та процесора.
ПРИМІТКА: Занадто багато одночасних завантажень може мати зменшену віддачу.
Дивіться також ПРИМІТКА ПРО AMAZON S3 нижче.
--s3-region-name
Вказує регіон сховища S3. Зазвичай обов’язково, якщо відро створено в певному регіоні.
--s3-unencrypted-connection
Вимикає SSL для з’єднань з S3. Це може бути значно швидше, але за певну втрату конфіденційності.
З увімкненням цієї опції будь-хто між вашим комп’ютером і S3 може спостерігати за трафіком і визначити: що ви використовуєте Duplicity, назву відра, ваш AWS Access Key ID, дати інкрементів і обсяг даних у кожному інкременті.
Ця опція впливає лише на з’єднання, а не на шифрування GPG файлів інкрементного резервного копіювання. Якщо шифрування не відключене, спостерігач не зможе побачити назви файлів або їх вміст.
Дивіться також ПРИМІТКА ПРО AMAZON S3 нижче.
--s3-use-deep-archive
Зберігає томи з використанням Glacier Deep Archive S3 під час завантаження в Amazon S3. Цей клас зберігання має нижчу вартість зберігання, але вищу вартість за запит разом із затримками до 48 годин з моменту запиту на відновлення. Вартість зберігання розраховується з мінімальним терміном зберігання 180 днів. За даними Amazon, це зберігання ідеально підходить для архівування даних і довгострокового резервного копіювання з 99.999999999% надійністю. Для відновлення резервної копії вам доведеться вручну перенести всі дані, збережені в AWS Glacier Deep Archive, назад у Standard S3 і дочекатися завершення міграції AWS.
ПРИМІТКА: Duplicity зберігатиме файли manifest.gpg і sigtar.gpg з повних і інкрементних резервних копій у стандартному сховищі AWS S3 для швидкого доступу для подальших інкрементних резервних копій, усі інші дані зберігаються в S3 Glacier Deep Archive.
--s3-use-glacier
Зберігає томи з використанням Glacier Flexible Storage під час завантаження в Amazon S3. Цей клас зберігання має нижчу вартість зберігання, але вищу вартість за запит разом із затримками до 12 годин з моменту запиту на відновлення. Вартість зберігання розраховується з мінімальним терміном зберігання 90 днів. За даними Amazon, це зберігання ідеально підходить для архівування даних і довгострокового резервного копіювання з 99.999999999% надійністю. Для відновлення резервної копії вам доведеться вручну перенести всі дані, збережені в AWS Glacier, назад у Standard S3 і дочекатися завершення міграції AWS.
ПРИМІТКА: Duplicity зберігатиме файли manifest.gpg і sigtar.gpg з повних і інкрементних резервних копій у стандартному сховищі AWS S3 для швидкого доступу для подальших інкрементних резервних копій, усі інші дані зберігаються в S3 Glacier.
--s3-use-glacier-ir
Зберігає томи з використанням Glacier Instant Retrieval під час завантаження в Amazon S3. Цей клас зберігання подібний до Glacier Flexible Storage, але пропонує миттєве відновлення на стандартних швидкостях.
ПРИМІТКА: Duplicity зберігатиме файли manifest.gpg і sigtar.gpg з повних і інкрементних резервних копій у стандартному сховищі AWS S3 для швидкого доступу для подальших інкрементних резервних копій, усі інші дані зберігаються в S3 Glacier.
--s3-use-ia
Зберігає томи з використанням Standard - Infrequent Access під час завантаження в Amazon S3. Цей клас зберігання має нижчу вартість зберігання, але вищу вартість за запит, і вартість зберігання розраховується з мінімальним терміном зберігання 30 днів. За даними Amazon, це зберігання ідеально підходить для довгострокового зберігання файлів, резервного копіювання та відновлення після аварій.
--s3-use-onezone-ia
Зберігає томи з використанням One Zone - Infrequent Access під час завантаження в Amazon S3. Це зберігання подібне до Standard - Infrequent Access, але зберігає дані об’єктів лише в одній зоні доступності.
--s3-use-rrs
Зберігає томи з використанням Reduced Redundancy Storage під час завантаження в Amazon S3. Це знижує вартість зберігання, але також знижує надійність збережених томів до 99.99% замість 99.999999999% надійності, пропонованої Standard Storage на S3.
--s3-use-server-side-kms-encryption
--s3-kms-key-id key_id
--s3-kms-grant grant
Вмикає шифрування на стороні сервера з використанням служби управління ключами.
--skip-if-no-change command
За замовчуванням створюється порожня інкрементна резервна копія, якщо жоден файл не змінився. Установка цієї опції пропускає створення резервної копії, якщо дані не змінилися. Нічого не буде надіслано до цільового сховища, і інформація не буде кешована.
--scp-command command
(лише бекенд ssh pexpect із увімкненим --use-scp)
Ця команда використовується замість "scp" для надсилання або отримання файлів. Для переліку та видалення наявних файлів використовується команда sftp.
Дивіться також розділ ПРИМІТКА ПРО SSH БЕКЕНДИ, бекенд SSH pexpect.
--sftp-command command
(лише бекенд ssh pexpect)
Ця команда використовується замість "sftp".
Дивіться також розділ ПРИМІТКА ПРО SSH БЕКЕНДИ, бекенд SSH pexpect.
--sign-key key-id
Цю опцію можна використовувати під час резервного копіювання, відновлення або перевірки. Під час резервного копіювання всі файли резервної копії будуть підписані ключем key-id. Під час відновлення duplicity видасть помилку, якщо будь-який віддалений файл не підписаний указаним key-id. key-id може бути вказаний у будь-якому форматі, підтримуваному GnuPG; дивіться gpg(1), розділ "ЯК ВКАЗАТИ ІДЕНТИФІКАТОР КОРИСТУВАЧА" для деталей. Слід вказувати лише один раз, оскільки наразі підтримується лише один ключ підпису. Останній запис замінює всі попередні.
Дивіться також ПРИМІТКА ПРО СИМЕТРИЧНЕ ШИФРУВАННЯ ТА ПІДПИС.
--ssh-askpass
Наказує бекенду ssh запитувати пароль віддаленої системи у користувача, якщо він не був визначений у цільовому URL і змінна середовища BACKEND_PASSWORD не встановлена. Цей пароль також використовується для ключів ssh, захищених паролем.
--ssh-options='options'
Дозволяє передавати опції бекенду ssh. Може бути вказано кілька разів або як список опцій, розділених пробілами. Список опцій має бути у формі "-oOpt1='parm1' -oOpt2='parm2'", де рядок опцій взятий у лапки, а єдині дозволені пробіли — між опціями. Рядок опцій передається дослівно до scp і sftp, чия синтакси командного рядка дещо відрізняється, тому опції слід вказувати у форматі довгих опцій, описаному в ssh_config(5).
Приклад списку:
duplicity --ssh-options="-oProtocol=2 -oIdentityFile='/my/backup/id'" /home/me scp://user@host/some_dir
Приклад із кількома параметрами:
duplicity --ssh-options="-oProtocol=2" --ssh-options="-oIdentityFile='/my/backup/id'" /home/me scp://user@host/some_dir
ПРИМІТКА: Бекенд ssh paramiko наразі підтримує лише налаштування -i, -oIdentityFile, -oUserKnownHostsFile або -oGlobalKnownHostsFile. Якщо потрібні додаткові параметри для конкретного хоста, надайте їх через файл ssh_config.
ПРИМІТКА2: Значення цієї опції має бути зв’язане з '=' як у
--ssh-options='-oProtocol=2 -oIdentityFile=/my/backup/id'
Дивіться ПРОБЛЕМА ARGPARSE для деталей.
--ssl-cacert-file file
(лише бекенди webdav та lftp) Надає файл cacert для перевірки SSL-сертифікатів.
Дивіться також ПРИМІТКА ПРО ПЕРЕВІРКУ SSL-СЕРТИФІКАТІВ.
--ssl-cacert-path path/to/certs/
(лише бекенд webdav і python 2.7.9+ АБО lftp+webdavs і недавній lftp) Надає шлях до папки, що містить файли cacert для перевірки SSL-сертифікатів.
Дивіться також ПРИМІТКА ПРО ПЕРЕВІРКУ SSL-СЕРТИФІКАТІВ.
--ssl-no-check-certificate
(лише бекенди webdav та lftp) Вимикає перевірку SSL-сертифікатів.
Дивіться також ПРИМІТКА ПРО ПЕРЕВІРКУ SSL-СЕРТИФІКАТІВ.
--swift-storage-policy
Використовує цю політику зберігання під час роботи з контейнерами Swift.
Дивіться також ПРИМІТКА ПРО ДОСТУП ДО SWIFT (OPENSTACK OBJECT STORAGE).
--metadata-sync-mode mode
Ця опція за замовчуванням встановлена на 'partial', але ви можете встановити її на 'full'.
Використовуйте 'partial', щоб уникнути синхронізації метаданих для ланцюжків резервного копіювання, які ви не збираєтеся використовувати. Це економить час під час першого відновлення і дозволяє відновити стару резервну копію, зашифровану іншим паролем, надаючи лише цільовий пароль.
Використовуйте 'full' для синхронізації метаданих усіх ланцюжків резервного копіювання на віддаленому сховищі.
--tempdir directory
Використовує цей існуючий каталог для тимчасових файлів duplicity замість системного за замовчуванням, який зазвичай є каталогом /tmp. Ця опція замінює будь-яку змінну середовища.
Дивіться також ЗМІННІ СЕРЕДОВИЩА.
-t time, --time time, --restore-time time
Вказує час, з якого потрібно відновити або перелічити файли.
Дивіться розділ ФОРМАТИ ЧАСУ для деталей.
--time-separator char
Використовує char як роздільник часу в іменах файлів замість двокрапки (":").
ПРИМІТКА: Ця опція застосовується лише до дій відновлення та статусу. Ми більше не створюємо та не записуємо імена файлів із роздільниками часу, але читатимемо старіші резервні копії, які можуть потребувати цієї опції.
--timeout seconds
Використовує seconds як значення тайм-ауту сокета, якщо duplicity починає завершуватися за тайм-аутом під час мережевих операцій. За замовчуванням — 30 секунд.
--use-agent
Якщо ця опція вказана, то --use-agent передається процесу шифрування GnuPG, і він спробує підключитися до gpg-agent перед запитом пароля для --encrypt-key або --sign-key, якщо це потрібно.
ПРИМІТКА: На відміну від попередніх версій duplicity, ця опція також буде підтримуватися GnuPG 2 і новішими версіями. Якщо використовується GnuPG 2, duplicity передає опцію --pinentry-mode=loopback процесу gpg, якщо --use-agent не вказано в командному рядку duplicity. Це означає, що GnuPG 2 використовує агент лише тоді, коли вказано --use-agent, як і GnuPG 1.
--use-gpgsm
Якщо ця опція вказана, процес шифрування GnuPG використовує бінарний gpgsm замість gpg. Це частина пакету GnuPG, але використовує формат файлів Cryptographic Message Syntax (CMS) (також відомий як PKCS#7, цей формат файлів також сумісний з іншими інструментами, такими як openssl smime).
Зашифровані файли матимуть розширення .p7m замість .gpg. Будь-яка операція, що вимагає розшифрування (відновлення, list-current-files тощо), також повинна вказувати --use-gpgsm.
gpgsm не підтримує симетричне (парольне) шифрування або прихованих отримувачів.
--verbosity level, -vlevel
Вказує рівень деталізації виводу (рівень логу). Названі рівні та відповідні значення: 0 Error, 2 Warning, 4 Notice (за замовчуванням), 8 Info, 9 Debug (найдетальніший).
level також може бути
символом: e, w, n, i, d
словом: error, warning, notice, info, debug
Опції -v4, -vn і -vnotice є функціонально еквівалентними, як і змішані/великі версії -vN, -vNotice і -vNOTICE.
--version
Виводить версію duplicity і завершує роботу.
--volsize number
Змінює розмір тому на number МБ. За замовчуванням — 200 МБ.
--webdav-headers csv formatted key,value pairs
Формат введення — список пар ключ,значення, розділених комами. Може використовуватися стандартне кодування CSV.
Наприклад, щоб установити Cookie, використовуйте 'Cookie,name=value' або '"Cookie","name=value"'.
Ви можете встановити кілька заголовків, наприклад, '"Cookie","name=value","Authorization","xxx"'.
ЗМІННІ СЕРЕДОВИЩА
TMPDIR, TEMP, TMP
У порядку спадання важливості визначає каталог для використання для тимчасових файлів (успадковано від модуля tempfile Python). Опція --tempdir переважає будь-яку з цих змінних.
BACKEND_PASSWORD, FTP_PASSWORD (застаріло)
Підтримується більшістю бекендів, які дозволяють використання пароля. Безпечніше, ніж установка в URL бекенду (який може бути видимим у списку процесів операційної системи для інших користувачів на тій же машині).
PASSPHRASE
Цей пароль передається до GnuPG. Якщо його не встановлено, користувача буде запрошено ввести пароль. GPG використовує метод шифрування AES для парольного шифрування.
SIGN_PASSPHRASE
Пароль для використання з --sign-key. Якщо не вказано і ключ підпису також є одним із ключів для шифрування, замість нього буде використано PASSPHRASE. Інакше, якщо пароль потрібен, але не встановлений, користувача буде запрошено його ввести. GPG використовує метод шифрування AES для парольного шифрування.
Інші змінні середовища можуть використовуватися для налаштування конкретних бекендів. Дивіться примітки для відповідного бекенду.
ФОРМАТ URL
Duplicity використовує формат URL (наскільки це можливо стандартний) для визначення розташувань даних. Основна відмінність полягає в тому, що для деяких бекендів секція хоста є необов’язковою.
ПРИМІТКА: Якщо шлях починається з додаткового '/', це зазвичай означає абсолютний шлях у бекенді.
Загальний формат URL:
scheme://[[user[:password]@]host[:port]/][/]path
або
scheme://[/]path
Використовуйте BACKEND_PASSWORD (Як безпечно надати пароль)
Не рекомендується вказувати пароль у командному рядку, наприклад, як частину цільового URL, оскільки він може бути видимим для будь-кого з правами перегляду списку процесів. Однак це можливо.
Натомість розгляньте можливість встановлення змінної середовища BACKEND_PASSWORD або інших специфічних для бекенду змінних середовища, які не мають цієї проблеми безпеки.
Деталі та описові приклади для кожного бекенду
У протоколах, що підтримують це, шлях може починатися з одного слеша, '/path', для позначення відносного шляху до цільового домашнього каталогу, або з подвійного слеша, '//path', для позначення абсолютного шляху у файловій системі.
ПРИМІТКА: Доступ до схеми (протоколу) може надаватися кількома бекендами. Якщо стандартний бекенд має помилки або не працює в конкретному випадку, варто спробувати альтернативну реалізацію. Альтернативні бекенди можна вибрати, додавши префікс до схеми, наприклад, ncftp+ftp://, і вони згадуються нижче синтаксису схеми.
Формати для кожного з бекендів:
Amazon Drive Backend
ad://some_dir
Дивіться також ПРИМІТКА ПРО AMAZON DRIVE
Azure azure://container-name
Дивіться також ПРИМІТКА ПРО ДОСТУП ДО AZURE
B2 b2://account_id[:application_key]@bucket_name/[folder/]
Box box:///some_dir[?config=path_to_config]
Дивіться також ПРИМІТКА ПРО ДОСТУП ДО BOX
Cloud Files (Rackspace)
cf+http://container_name
Дивіться також ПРИМІТКА ПРО ДОСТУП ДО CLOUD FILES
Dropbox
dpbx:///some_dir
Спочатку ознайомтеся з ПРИМІТКОЮ ПРО ДОСТУП ДО DROPBOX!
File (локальна файлова система)
file://[relative|/absolute]/local/path
FISH (Files transferred over Shell protocol) через ssh
fish://user[:password]@other.host[:port]/[relative|/absolute]_path
FTP ftp[s]://user[:password]@other.host[:port]/some_dir
ПРИМІТКА: використовуйте префікси lftp+, ncftp+, щоб примусово вибрати конкретний бекенд, за замовчуванням lftp+ftp://...
Google Cloud Storage (GCS через Interoperable Access)
s3://bucket[/path]
Дивіться ПРИМІТКУ ПРО GOOGLE CLOUD STORAGE про необхідну опцію кінцевої точки та змінні середовища для автентифікації.
Google Docs
gdocs://user[:password]@other.host/some_dir
ПРИМІТКА: використовуйте префікси pydrive+, gdata+, щоб примусово вибрати конкретний бекенд, за замовчуванням pydrive+gdocs://...
Google Drive
gdrive://<service account' email address>@developer.gserviceaccount.com/some_dir
Дивіться також ПРИМІТКА ПРО БЕКЕНД GDRIVE нижче.
HSI hsi://user[:password]@other.host/some_dir
hubiC cf+hubic://container_name
Дивіться також ПРИМІТКА ПРО HUBIC
IMAP email storage
imap[s]://user[:password]@host.com[/from_address_prefix]
Дивіться також ПРИМІТКА ПРО IMAP
MediaFire
mf://user[:password]@mediafire.com/some_dir
Дивіться також ПРИМІТКА ПРО БЕКЕНД MEDIAFIRE нижче.
MEGA.nz cloud storage (працює лише для акаунтів, створених до листопада 2018, використовує "megatools")
mega://user[:password]@mega.nz/some_dir
ПРИМІТКА: якщо не вказано в URL, залежить від пароля, збереженого в $HOME/.megarc (як використовується утилітами "megatools")
MEGA.nz cloud storage (працює для всіх акаунтів MEGA, використовує інструменти "MEGAcmd")
megav2://user[:password]@mega.nz/some_dir megav3://user[:password]@mega.nz/some_dir[?no_logout=1] (Для останнього MEGAcmd)
ПРИМІТКА: незважаючи на те, що "MEGAcmd" більше не використовує конфігураційний файл, для зручності зберігання пароля користувача цей бекенд шукає його в файлі $HOME/.megav2rc (той же синтаксис, що й у старому $HOME/.megarc)
[Login]
Username = MEGA_USERNAME
Password = MEGA_PASSWORD
multi multi:///path/to/config.json
Дивіться також ПРИМІТКА ПРО БЕКЕНД MULTI нижче.
OneDrive Backend
onedrive://some_dir Дивіться також ПРИМІТКА ПРО БЕКЕНД ONEDRIVE
Par2 Wrapper Backend
par2+scheme://[user[:password]@]host[:port]/[/]path
Дивіться також ПРИМІТКА ПРО БЕКЕНД PAR2 WRAPPER
Public Cloud Archive (OVH)
pca://container_name[/prefix]
Дивіться також ПРИМІТКА ПРО ДОСТУП ДО PCA
pydrive
pydrive://<service account' email address>@developer.gserviceaccount.com/some_dir
Дивіться також ПРИМІТКА ПРО БЕКЕНД PYDRIVE нижче.
Rclone Backend
rclone://remote:/some_dir
Дивіться також ПРИМІТКА ПРО БЕКЕНД RCLONE
Rsync через демон
rsync://user[:password]@host.com[:port]::[/]module/some_dir
Rsync через ssh (лише автентифікація за ключем)
rsync://user@host.com[:port]/[relative|/absolute]_path
S3 storage (Amazon)
s3:///bucket_name[/path]
Дивіться також ПРИМІТКА ПРО AMAZON S3 нижче.
SCP/SFTP Secure Copy Protocol/SSH File Transfer Protocol
scp://.. або
sftp://user[:password]@other.host[:port]/[relative|/absolute]_path
за замовчуванням paramiko+scp:// і paramiko+sftp://
як альтернатива спробуйте pexpect+scp://, pexpect+sftp://, lftp+sftp://
Дивіться також --ssh-askpass, --ssh-options і ПРИМІТКА ПРО SSH БЕКЕНДИ.
slate slate://[slate-id]
Дивіться також ПРИМІТКА ПРО БЕКЕНД SLATE
Swift (Openstack)
swift://container_name[/prefix]
Дивіться також ПРИМІТКА ПРО ДОСТУП ДО SWIFT (OPENSTACK OBJECT STORAGE)
Tahoe-LAFS
tahoe://alias/directory
WebDAV webdav[s]://user[:password]@other.host[:port]/some_dir
як альтернатива спробуйте lftp+webdav[s]://
Optical media (ISO9660 CD/DVD/Bluray using xorriso)
xorriso:///dev/byOpticalDrive[:/path/to/directory/on/iso]
xorriso:///path/to/image.iso[:/path/to/directory/on/iso]
Дивіться також ПРИМІТКА ПРО БЕКЕНД XORRISO
ФОРМАТИ ЧАСУ
duplicity використовує рядки часу в двох місцях. По-перше, багато файлів, створених duplicity, міститимуть час у своїх іменах у форматі w3 datetime, як описано в примітці w3 за адресою
http://www.w3.org/TR/NOTE-datetime. По суті, вони виглядають як "2001-07-15T04:09:38-07:00", що означає саме те, що виглядає. Секція "-07:00" означає, що часовий пояс відстає від UTC на 7 годин.
По-друге, опції -t, --time і --restore-time приймають рядок часу, який може бути вказаний у будь-якому з кількох форматів:
1. рядок "now" (посилається на поточний час)
2. послідовність цифр, наприклад, "123456890" (вказує час у секундах після епохи)
3. рядок типу "2002-01-25T07:00:00+02:00" у форматі datetime
4. інтервал, який є числом, за яким слідує один із символів s, m, h, D, W, M або Y (що вказує секунди, хвилини, години, дні, тижні, місяці або роки відповідно) або серія таких пар.
У цьому випадку рядок посилається на час, що передував поточному часу на довжину інтервалу. Наприклад, "1h78m" вказує на час, який був годину і 78 хвилин тому.
Календар тут спрощений: місяць завжди становить 30 днів, рік — 365 днів, а день — 86400 секунд.
5. Формат дати у вигляді YYYY/MM/DD, YYYY-MM-DD, MM/DD/YYYY або MM-DD-YYYY, який вказує на північ за вказаною датою відносно поточних налаштувань часового поясу.
Наприклад, "2002/3/5", "03-05-2002" і "2002-3-05" усі означають 5 березня 2002 року.
ВИБІР ФАЙЛІВ
Під час запуску duplicity він сканує вказаний вихідний каталог і створює резервні копії всіх файлів, визначених системою вибору файлів, якщо не вказано --files-from, у такому випадку використовується переданий список окремих файлів.
Система вибору файлів складається з низки умов вибору файлів, які встановлюються за допомогою однієї з наступних опцій командного рядка:
--exclude
--exclude-device-files
--exclude-if-present
--exclude-filelist
--exclude-regexp
--include
--include-filelist
--include-regexp
Для кожного окремого файлу, знайденого у вихідному каталозі, умови вибору перевіряються в порядку їх вказання в командному рядку. Якщо умова вибору відповідає, файл включається або виключається відповідно, і система вибору файлів переходить до наступного файлу без перевірки решти умов.
Ранніші аргументи мають пріоритет, коли кілька умов відповідають одному файлу, і зазвичай указуються в порядку зменшення специфіки. Якщо жодна умова вибору не відповідає даному файлу, файл неявно включається.
Наприклад,
duplicity --include /usr --exclude /usr /usr scp://user@host/backup
є точно таким же, як
duplicity /usr scp://user@host/backup
оскільки директива --include відповідає всім файлам у вихідному каталозі резервного копіювання і має пріоритет над суперечливою опцією --exclude, оскільки вказана раніше.
Як більш значущий приклад,
duplicity --include /usr/local/bin --exclude /usr/local /usr scp://user@host/backup
створить резервну копію каталогу /usr/local/bin (і його вмісту), але не /usr/local/doc. Зверніть увагу, що це не те саме, що просто вказати /usr/local/bin як вихідний каталог, оскільки інші файли та папки під /usr також будуть (неявно) включені.
Порядок аргументів --include і --exclude важливий. У попередньому прикладі, якби менш специфічна директива --exclude мала пріоритет, вона б завадила відповідності більш специфічної --include.
Шаблони, передані опціям --include, --exclude, --include-filelist і --exclude-filelist, за замовчуванням інтерпретуються як розширені шаблони оболонки. Цю поведінку можна змінити за допомогою наступних аргументів режиму фільтра:
--filter-globbing
--filter-literal
--filter-regexp
Ці аргументи змінюють інтерпретацію шаблонів, що використовуються в умовах вибору файлів, впливаючи на всі наступні опції вибору файлів, передані в командному рядку. Їх можна вказувати кілька разів, щоб перемикатися між інтерпретаціями шаблонів за потреби.
Літерали відрізняються від шаблонів оболонки тим, що шаблон має точно відповідати імені файлу. Це може бути корисним, коли імена файлів містять символи, що мають спеціальне значення в шаблонах оболонки або регулярних виразах. Якщо ви передаєте динамічно згенеровані списки файлів до duplicity за допомогою опцій --include-filelist або --exclude-filelist, рекомендується використовувати --filter-literal, якщо явно не потрібні регулярні вирази або шаблони оболонки.
Мова регулярних виразів, що використовується для умов вибору, указаних за допомогою --include-regexp, --exclude-regexp або коли діє --filter-regexp, реалізується стандартною бібліотекою Python.
Розширені шаблони оболонки можуть містити: *, **, ?, і [...] (діапазони символів). Як у звичайній оболонці, * розширюється до будь-якого рядка символів, що не містить "/", ? розширюється до будь-якого окремого символу, крім "/", і [...] розширюється до одного символу із зазначених (допустимі діапазони). Шаблон ** розширюється до будь-якого рядка символів, незалежно від того, чи містить він "/".
На додаток до вищезазначених аргументів режиму фільтра, наступні можуть використовуватися аналогічно для ввімкнення (за замовчуванням) або вимкнення чутливості до регістру при оцінці умов вибору файлів:
--filter-ignorecase
--filter-strictcase
Приклад перемикання режиму фільтра, включаючи нечутливість до регістру:
--filter-ignorecase --include /usr/bin/*.PY --filter-literal --filter-include /usr/bin/special?file*name --filter-strictcase --exclude /usr/bin
це створить резервну копію файлів *.py, *.pY, *.Py і *.PY у /usr/bin, а також одного явно вказаного файлу з символами шаблонів у назві. Використання --filter-strictcase технічно не є необхідним тут, але включено як приклад, який може (залежно від вихідного шляху резервного копіювання) спричинити несподівані взаємодії між опціями --include і --exclude, якщо частина шляху каталогу (/usr/bin) містить великі літери.
Якщо шаблон починається з "ignorecase:" (нечутливість до регістру), цей префікс буде видалений, і будь-який символ у рядку може бути замінений на його велику або малу версію. Ця функція є застарілою і підтримується лише для умов вибору шаблонів оболонки, але з міркувань зворотної сумісності вважається частиною самого шаблону (використовуйте --filter-ignorecase замість цього).
Пам’ятайте, що шаблони, можливо, потрібно брати в лапки при введенні в оболонку, щоб оболонка не інтерпретувала шаблони оболонки або пробіли перед тим, як їх побачить duplicity.
Шаблони вибору зазвичай слід розглядати як шляхи файлової системи, а не як довільні рядки. Для умов вибору, що використовують розширені шаблони оболонки, опція --exclude відповідає файлу, якщо:
1. шаблон може бути розширений до імені файлу, або
2. файл знаходиться в каталозі, що відповідає опції.
Навпаки, опція --include відповідає файлу, якщо:
1. шаблон може бути розширений до імені файлу, або
2. файл знаходиться в каталозі, що відповідає опції, або
3. файл є каталогом, який містить файл, що відповідає опції.
Наприклад,
--exclude /usr/local
відповідає, наприклад, /usr/local, /usr/local/lib і /usr/local/lib/netscape. Це те саме, що --exclude /usr/local --exclude '/usr/local/**'.
З іншого боку,
--include /usr/local
вказує, що /usr, /usr/local,/usr/local/lib та /usr/local/lib/netscape (але не /usr/doc) мають бути включені до резервної копії. Таким чином, вам не потрібно турбуватися про включення батьківських каталогів, щоб переконатися, що підкаталоги, які потрібно включити, матимуть куди зберігатися.
Нарешті,
--include ignorecase:'/usr/[a-z0-9]foo/*/**.py'
відповідатиме файлу, наприклад, /usR/5fOO/hello/there/world.py. Якщо відповідність знайдено, це також включатиме /usr. Якщо немає файлу, який відповідає вказаному шаблону, опція не відповідатиме лише /usr.
Обробка шаблонів у режимах globbing та literal як шляхів файлової системи зменшує кількість необхідних явних умов. Однак це вимагає, щоб шляхи, описані всіма варіантами опцій --include або --exclude, були повністю визначені відносно вихідного каталогу резервного копіювання.
Для умов вибору, що використовують буквальні рядки, застосовується та сама логіка, за винятком того, що сценарій 1 передбачає точну відповідність шаблону.
Для умов вибору, що використовують регулярні вирази, шаблон оцінюється як регулярний вираз, а не як шлях файлової системи. Таким чином, сценарій 3, описаний вище, не застосовується, наслідки цього розглядаються в кінці цього розділу.
Опції --include-filelist та --exclude-filelist також додають умови вибору файлів. Вони наказують duplicity читати текстовий файл (у форматі ASCII або UTF-8), де кожен рядок є специфікацією файлу, і включати або виключати відповідні файли. Рядки розділяються новими рядками або нулями, залежно від того, чи було вказано опцію --null-separator.
Кожен рядок у списку файлів інтерпретується як шаблон вибору так само, як опції --include та --exclude, за винятком того, що рядки, які починаються з "+ ", інтерпретуються як директиви включення, навіть якщо вони знаходяться у списку, вказаному через --exclude-filelist. Аналогічно, рядки, що починаються з "- ", виключають файли, навіть якщо вони знаходяться у списку включення.
Наприклад, якщо файл "list.txt" містить рядки:
/usr/local
- /usr/local/doc
/usr/local/bin
+ /var
- /var
то команда --include-filelist list.txt включатиме /usr, /usr/local та /usr/local/bin. Вона виключатиме /usr/local/doc, /usr/local/doc/python тощо. Також включатиме /usr/local/man, оскільки це входить до /usr/local. Поведінка для /var є невизначеною, оскільки один список файлів не повинен містити суперечливих специфікацій файлів.
Кожен рядок у списку файлів інтерпретується відповідно до поточного режиму фільтра так само, як опції --include та --exclude. Наприклад, якщо файл "list.txt" містить рядки:
dir/foo
+ dir/bar
- **
то команда --include-filelist list.txt буде еквівалентною вказанню --include dir/foo --include dir/bar --exclude ** у командному рядку.
Зверніть увагу, що вказання дуже великої кількості правил вибору у вигляді списків файлів може спричинити значне зниження продуктивності, оскільки ці правила (потенційно) перевірятимуться для кожного файлу у вихідному каталозі резервного копіювання. Якщо вам потрібно створювати резервні копії довільних списків конкретних файлів (тобто не описаних регулярними виразами або шаблонами оболонки), тоді опція --files-from, ймовірно, буде більш продуктивною.
Нарешті, опції --include-regexp та --exclude-regexp дозволяють включати або виключати файли, якщо їхні імена відповідають регулярному виразу. Синтаксис регулярних виразів занадто складний для пояснення тут, але описаний у довідці бібліотеки Python. На відміну від опцій --include та --exclude, опції регулярних виразів не відповідають файлам, що містяться в або містять відповідні файли. Наприклад,
--include-regexp '[0-9]{7}(?!foo)'
відповідає будь-яким файлам, чиї повні шляхи містять 7 послідовних цифр, за якими не йде 'foo'. Однак це не відповідатиме /home, навіть якщо існує /home/ben/1234567.ПРИМІТКА ПРО AMAZON DRIVE 1. Ключи API, використані для Amazon Drive, не отримали лімітів для продакшену. Amazon не вказує, які обмеження застосовуються для розробки, і не відповідає на запити щодо внесення duplicity до білого списку. Пов’язаний інструмент, acd_cli, був переведений на обмеження для розробки, але продовжує працювати нормально, за винятком випадків надмірного використання. Якщо ви стикаєтеся з обмеженнями або подібними проблемами при використанні Amazon Drive з цим бекендом, повідомте про це на поштову розсилку.
2. Якщо раніше ви використовували бекенд acd+acdcli, настійно рекомендується перейти на бекенд ad, оскільки він працює безпосередньо з Amazon Drive. Вам потрібно буде ще раз налаштувати OAuth, але в іншому ви можете зберегти свої резервні копії та конфігурацію.ПРИМІТКА ПРО AMAZON S3 Резервне копіювання в Amazon S3 використовує бібліотеку boto3.
Бекенд boto3 не підтримує створення відер. Це свідомий вибір для спрощення коду та уникнення проблем, пов’язаних із вибором регіону. Крім того, надання ролі резервного копіювання прав на створення відер, ймовірно, не є гарною практикою. У більшості випадків роль, використана для резервного копіювання, має бути обмежена конкретними відрами.
Бекенд boto3 підтримує лише нові відра у стилі доменів. Amazon планує припинити підтримку старого стилю відер, тому рекомендується міграція.
Наразі бекенд boto3 не підтримує ініціацію відновлення з класу зберігання Glacier. Для відновлення резервної копії з Glacier або Glacier Deep Archive файли резервної копії спочатку потрібно відновити поза межами duplicity. Існує кілька варіантів відновлення з холодного сховища, які різняться за вартістю та швидкістю. Дивіться документацію Amazon для деталей.
Для автентифікації потрібні наступні змінні середовища:
AWS_ACCESS_KEY_ID (обов’язково),
AWS_SECRET_ACCESS_KEY (обов’язково)
або
BOTO_CONFIG (обов’язково), що вказує на файл конфігурації boto.
Для простоти ми документуємо лише використання змінних AWS_*. Дослідіть документацію boto3, доступну в Інтернеті, якщо ви хочете використовувати файл конфігурації.
Приклад команди резервного копіювання для бекенду boto3:
AWS_ACCESS_KEY_ID=<key_id> AWS_SECRET_ACCESS_KEY=<access_key> duplicity /some/path s3:///bucket/subfolder
Ви можете додати --s3-endpoint-url (для доступу до не-Amazon S3 сервісів або регіональних кінцевих точок) і, можливо, знадобиться --s3-region-name (для відер, створених у певних регіонах) та інші опції --s3-..., описані вище.ПРИМІТКА ПРО ДОСТУП ДО AZURE Бекенд Azure вимагає встановлення бібліотеки клієнта Microsoft Azure Storage Blobs для Python на системі. Дивіться ВИМОГИ.
Використовується змінна середовища AZURE_CONNECTION_STRING (обов’язково). Цей рядок містить усю необхідну інформацію, таку як ім’я облікового запису зберігання та ключ для автентифікації. Ви можете знайти його в розділі "Ключі доступу" для облікового запису зберігання.
Duplicity подбає про створення контейнера під час виконання резервного копіювання. Не створюйте його вручну заздалегідь.
Ім’я контейнера (як вказано в URL резервного копіювання) має бути дійсним DNS-ім’ям, що відповідає наступним правилам:
1. Імена контейнерів повинні починатися з літери або цифри і можуть містити лише літери, цифри та символ тире (-).
2. Кожен символ тире (-) має бути безпосередньо перед і після літери або цифри; послідовні тире в іменах контейнерів не допускаються.
3. Усі літери в імені контейнера мають бути малими.
4. Імена контейнерів повинні мати довжину від 3 до 63 символів.
Ці правила встановлені Azure; див. https://docs.microsoft.com/en-us/rest/api/storageservices/naming-and-referencing-containers--blobs--and-metadataПРИМІТКА ПРО ДОСТУП ДО BOX Бекенд Box вимагає встановлення boxsdk з підтримкою JWT на системі. Дивіться ВИМОГИ.
Використовується змінна середовища BOX_CONFIG_PATH (необов’язково). Цей рядок містить шлях до файлу config.json власної програми Box. Потрібно вказати або цю змінну середовища, або параметр запиту config в URL; якщо вказано обидва, параметр запиту має пріоритет. Створення власної програми Box Для використання бекенду Box потрібно створити власну програму Box у консолі розробника Box (https://app.box.com/developers/console).
Після створення нової власної програми переконайтеся, що вона налаштована наступним чином:
1. Виберіть "Тільки доступ до програми" для "Рівня доступу до програми".
2. Позначте "Записувати всі файли та папки, збережені в Box".
3. Згенеруйте пару відкритий/приватний ключ.
Користувач також має надати створеній програмі дозвіл у консолі адміністратора (https://app.box.com/master/custom-apps), натиснувши кнопку "+" та ввівши client_id, який можна знайти на сторінці конфігурації програми.ПРИМІТКА ПРО ДОСТУП ДО CLOUD FILES Pyrax — це API управління хмарою наступного покоління від Rackspace, включаючи доступ до Cloud Files. Бекенд cfpyrax вимагає встановлення бібліотеки pyrax на системі. Дивіться ВИМОГИ.
Cloudfiles — це застаріла реалізація протоколу OpenStack Object Storage від Rackspace. Користувачам, які бажають використовувати Duplicity з Rackspace Cloud Files, рекомендується перейти на новий плагін Pyrax для забезпечення підтримки.
Бекенд вимагає встановлення python-cloudfiles на системі. Дивіться ВИМОГИ.
Для автентифікації використовуються три змінні середовища: CLOUDFILES_USERNAME (обов’язково), CLOUDFILES_APIKEY (обов’язково), CLOUDFILES_AUTHURL (необов’язково).
Якщо CLOUDFILES_AUTHURL не вказано, буде використано значення за замовчуванням, надане python-cloudfiles, яке вказує на Rackspace, тому це значення потрібно встановити для використання інших постачальників Cloud Files.ПРИМІТКА ПРО ДОСТУП ДО DROPBOX 1. Бекенд Dropbox вимагає дійсного токена автентифікації. Його слід передати через змінну середовища DPBX_ACCESS_TOKEN.
Щоб отримати його, створіть програму 'Dropbox API' за адресою: https://www.dropbox.com/developers/apps/create
Потім перейдіть до налаштувань програми та використовуйте "Згенерований токен доступу" в розділі OAuth2.
Як альтернатива, ви можете дозволити duplicity самому згенерувати токен доступу. У такому випадку тимчасово експортуйте DPBX_APP_KEY, DPBX_APP_SECRET, використовуючи значення зі сторінки налаштувань програми, і запустіть duplicity в інтерактивному режимі.
Програма виведе URL, який потрібно відкрити в браузері, щоб отримати токен OAuth2 для програми. Дотримуйтесь інструкцій на екрані, а потім помістіть згенерований токен у змінну DPBX_ACCESS_TOKEN. Після цього можна видалити DPBX_APP_KEY і DPBX_APP_SECRET.
2. "some_dir" має вже існувати в папці Dropbox. Залежно від типу токена доступу це може бути:
Повний Dropbox: шлях є абсолютним і починається з кореневої папки 'Dropbox'.
Папка програми: шлях відносний до папки програми. Клієнт Dropbox покаже її в ~/Dropbox/Apps/<app-name>.
3. Під час використання Dropbox для зберігання враховуйте, що всі файли, включно з тими, що знаходяться в папці Apps, синхронізуються на всіх підключених комп’ютерах. Ви можете віддати перевагу використанню окремого облікового запису Dropbox спеціально для резервних копій і не підключати до нього жодних комп’ютерів. Як альтернатива, ви можете налаштувати вибіркову синхронізацію на всіх комп’ютерах, щоб уникнути синхронізації файлів резервних копій.ПРИМІТКА ПРО ПРЕФІКСИ НАЗВ ФАЙЛІВ Префікси імен файлів можна використовувати в бекенді multi в режимі дзеркала для визначення правил афінності. Вони також можуть використовуватися разом із правилами життєвого циклу S3 для переведення архівних файлів у Glacier, зберігаючи метадані (файли сигнатур і маніфестів) у S3.
Duplicity не вимагає доступу до архівних файлів, крім випадків відновлення з резервної копії.ПРИМІТКА ПРО GOOGLE CLOUD STORAGE (GCS через Interoperable Access) Огляд Доступ Duplicity до GCS наразі залежить від API Interoperability (по суті, S3 для GCS). Його потрібно активувати перед початком роботи. Дивіться розділ "Підготовка" нижче. Підготовка 1. Увійдіть на https://console.cloud.google.com/
2. Перейдіть до Cloud Storage -> Налаштування -> Interoperability
3. Створіть обліковий запис служби (за потреби)
4. Створіть ключ доступу HMAC для облікового запису служби та секретний ключ (обов’язково скопіюйте секрет негайно, його не можна відновити пізніше)
5. Перейдіть до Cloud Storage -> Браузер
6. Створіть відро
7. Додайте дозволи для облікового запису служби, використаного для налаштування доступу Interoperability
Після налаштування ви можете використовувати згенеровані ключ доступу та секретний ключ Interoperable Storage і передати їх до duplicity, як описано в наступному розділі. Використання Наступні приклади показують доступ до GCS через S3 для дії collection-status. Показані змінні середовища, опції та формат URL також можуть застосовуватися до всіх інших дій.
Використання boto3 із вказанням --s3-endpoint-url вручну:
AWS_ACCESS_KEY_ID=<keyid> AWS_SECRET_ACCESS_KEY=<secret> duplicity collection-status s3:///<bucket>/<folder> --s3-endpoint-url=https://storage.googleapis.comПРИМІТКА ПРО БЕКЕНД GDRIVE GDrive — це переписаний бекенд PyDrive із меншою кількістю залежностей і простішим налаштуванням — він використовує JSON-ключи, завантажені безпосередньо з Google Cloud Console.
Зверніть увагу, що Google має два методи Drive: "Shared (раніше Team) Drives" і "My Drive", обидва можуть бути спільними, але потребують різного адресування.
Для папки Google Shared Drives
Ідентифікатор спільного диска вказується як параметр запиту driveID у URL бекенду. Приклад:
gdrive://developer.gserviceaccount.com/target-folder/?driveID=<SHARED DRIVE ID>
Для спільної папки на основі Google My Drive
Ідентифікатор папки My Drive вказується як параметр запиту myDriveFolderID у URL бекенду. Приклад:
export GOOGLE_SERVICE_ACCOUNT_URL=<serviceaccount-name>@<serviceaccount-name>.iam.gserviceaccount.com
gdrive://${GOOGLE_SERVICE_ACCOUNT_URL}/<target-folder-name-in-myDriveFolder>?myDriveFolderID=root
Існує два способи автентифікації для використання GDrive: зі звичайним обліковим записом або з "обліковим записом служби". З обліковим записом служби створюється окремий обліковий запис, доступний лише через Google API, а не через веб-вхід. Зі звичайним обліковим записом ви можете зберігати резервні копії у вашому звичайному Google Drive.
Для використання облікового запису служби перейдіть до консолі розробників Google за адресою https://console.developers.google.com. Створіть проєкт і переконайтеся, що API Drive увімкнено для проєкту. У розділі "Облікові дані" натисніть "Створити облікові дані", потім виберіть Обліковий запис служби з ключем JSON.
Змінна середовища GOOGLE_SERVICE_JSON_FILE має містити шлях до файлу JSON під час виклику duplicity.
export GOOGLE_SERVICE_JSON_FILE=<path-to-serviceaccount-credentials.json>
Альтернативою є використання звичайного облікового запису. Для цього почніть так само, але під час створення нового Client ID виберіть "OAuth client ID" із типом програми "Desktop app". Завантажте файл client_secret.json і встановіть змінну середовища GOOGLE_CLIENT_SECRET_JSON_FILE на шлях до цього файлу, а також GOOGLE_CREDENTIALS_FILE на шлях до файлу, де duplicity зберігатиме токен автентифікації — це місце має бути доступним для запису.
**ПРИМІТКА**: Як перевірка безпеки, GDrive перевіряє хост і ім’я користувача з URL проти ключа JSON і відмовляється продовжувати, якщо адреси не збігаються. Або електронна адреса (для облікових записів служби), або Client ID (для звичайних OAuth-акаунтів) мають бути присутніми в URL. Дивіться ФОРМАТ URL вище. Перший запуск / Авторизація OAuth 2.0 Під час першого запуску вам буде запропоновано відвідати URL у вашому браузері, щоб надати доступ до вашого Google Drive. Для цього буде запущено тимчасовий HTTP-сервіс на локальному мережевому інтерфейсі (за замовчуванням на http://localhost:8080/). IP-адресу/хост і порт можна налаштувати за потреби, вказавши змінні середовища GOOGLE_OAUTH_LOCAL_SERVER_HOST, GOOGLE_OAUTH_LOCAL_SERVER_PORT відповідно.
Якщо ви запускаєте duplicity у віддаленому розташуванні, переконайтеся, що ви зможете отримати доступ до вищезгаданого HTTP-сервісу через браузер, використовуючи, наприклад, переадресацію портів або тимчасовий дозвіл брандмауера.
Облікові дані доступу будуть збережені у вищезгаданому JSON-файлі для подальшого використання після успішної авторизації.ПРИМІТКА ПРО HUBIC Бекенд hubic вимагає встановлення бібліотеки pyrax на системі. Дивіться ВИМОГИ. Вам потрібно буде встановити свої облікові дані для hubiC у файлі ~/.hubic_credentials за наступним шаблоном:
[hubic]
email = your_email
password = your_password
client_id = api_client_id
client_secret = api_secret_key
redirect_uri = http://localhost/ПРИМІТКА ПРО IMAP Обліковий запис IMAP може використовуватися як ціль для завантаження. Можна вказати ідентифікатор користувача, а пароль буде запитаний.
Параметр from_address_prefix може бути вказаний (і, ймовірно, повинен бути). Текст використовуватиметься як адреса "Від" на сервері IMAP. Під час дії відновлення (або списку) from_address_prefix відрізнятиме різні резервні копії.ПРИМІТКА ПРО БЕКЕНД MEDIAFIRE Цей бекенд вимагає встановлення бібліотеки MediaFire Python на системі. Дивіться ВИМОГИ.
Використовуйте екранування URL для імені користувача (і пароля, якщо він надається через командний рядок):
mf://duplicity%40example.com@mediafire.com/some_folder
Цільова папка буде створена для вас, якщо вона ще не існує.ПРИМІТКА ПРО БЕКЕНД MULTI Бекенд multi дозволяє duplicity комбінувати сховища, доступні в кількох бекендах (наприклад, ви можете зберігати дані одночасно в обліковому записі Google Drive і OneDrive, щоб отримати ефективно комбінований обсяг зберігання). Шлях у URL вказує на JSON-файл конфігурації, що містить список бекендів, які використовуватимуться. URL також може містити параметри запиту для налаштування загальної поведінки. Кожен елемент списку повинен мати елемент "url" і може містити необов’язковий "description" та необов’язковий список "env" змінних середовища, які використовуються для налаштування цього бекенду. Параметри запиту Параметри запиту вказуються після URL файлу у стандартному форматі HTTP, наприклад:
multi:///path/to/config.json?mode=mirror&onfail=abort
multi:///path/to/config.json?mode=stripe&onfail=continue
multi:///path/to/config.json?onfail=abort&mode=stripe
multi:///path/to/config.json?onfail=abort
Порядок не має значення, однак невідомі параметри вважаються помилкою.
**mode=stripe**
Цей режим (за замовчуванням) виконує почерговий доступ до списку бекендів. У цьому режимі всі бекенди повинні бути надійними, оскільки втрата одного означає втрату одного з архівних файлів.
**mode=mirror**
Цей режим використовує бекенди як RAID1-сховище, зберігаючи кожен файл у всіх бекендах і читаючи файли з першого успішного бекенду. Втрата будь-якого бекенду не повинна призводити до збою. Зверніть увагу, що бекенди, додані пізніше, отримуватимуть лише нові файли і можуть потребувати ручної синхронізації з одним із діючих.
**onfail=continue**
Ця настройка (за замовчуванням) продовжує всі операції запису на основі принципу "найкраще зусилля". Будь-яка помилка призводить до спроби з наступним бекендом. Помилка повідомляється лише тоді, коли всі бекенди не можуть виконати певну операцію, із результатом помилки від останньої спроби.
**onfail=abort**
Ця настройка вважає будь-яку помилку запису бекенду умовою припинення і повідомляє про помилку. Операції читання даних і переліку є незалежними від цього і спробують наступний бекенд у разі помилки. Приклад JSON-файлу [
{
"description": "коментар про бекенд",
"url": "abackend://myuser@domain.com/backup",
"env": [
{
"name": "MYENV",
"value": "xyz"
},
{
"name": "FOO",
"value": "bar"
}
],
"prefixes": ["prefix1_", "prefix2_"]
},
{
"url": "file:///path/to/dir"
}
]ПРИМІТКА ПРО БЕКЕНД ONEDRIVE Бекенд onedrive:// працює як із особистими, так і з бізнес-акаунтами OneDrive, а також із дисками SharePoint. Під час першого використання вам буде надано URL для автентифікації за допомогою облікового запису Microsoft. Відкрийте його у веб-браузері.
Після автентифікації скопіюйте перенаправлений URL назад до duplicity. Duplicity отримає токен і збереже його в ~/.duplicity_onedrive_oauthtoken.json. Це розташування можна змінити, встановивши змінну середовища DUPLICITY_ONEDRIVE_TOKEN.
Duplicity використовує стандартний App ID, зареєстрований у Microsoft Azure AD. Для бізнес-акаунтів його потрібно схвалити адміністратором вашого тенанта Office365. Реєстрація та встановлення власного App ID Microsoft 1. Відвідайте https://portal.azure.com
2. Виберіть "Enterprise Applications", потім "Create your own Application".
3. Введіть назву вашої програми та виберіть "Register an application to integrate with Azure AD".
4. Перейдіть на наступну сторінку та встановіть redirect uri на "https://login.microsoftonline.com/common/oauth2/nativeclient", вибравши "Public client/native" зі спадного меню. Натисніть "Створити".
5. Знайдіть ідентифікатор програми в "Enterprise Applications" і встановіть змінну середовища DUPLICITY_ONEDRIVE_CLIENT_ID на нього.
Додаткова інформація про програми Microsoft: https://learn.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app Резервне копіювання на сайт SharePoint замість OneDrive Для використання сайту SharePoint потрібно знайти та надати ідентифікатор тенанта та сайту.
1. Увійдіть за допомогою облікового запису Microsoft на https://<o365_tenant>.sharepoint.com/
2. Перейдіть до https://<o365_tenant>.sharepoint.com/sites/<path_to_site>/_api/site/id
3. Скопіюйте відображений UUID (site_id) і встановіть змінну середовища DUPLICITY_ONEDRIVE_ROOT на "sites/<o365_tenant>.sharepoint.com,<site_id>/drive"ПРИМІТКА ПРО БЕКЕНД PAR2 WRAPPER Бекенд Par2 Wrapper можна використовувати в поєднанні з усіма іншими бекендами для створення файлів відновлення. Просто додайте par2+ перед звичайною схемою (наприклад, par2+ftp://user@host/dir або par2+s3+http://bucket_name). Це створить файли відновлення par2 для кожного архіву та завантажить їх усі до обгорнутого бекенду.
Перед відновленням архіви будуть перевірені. Пошкоджені архіви будуть відновлені на ходу, якщо доступно достатньо блоків відновлення.
Використовуйте --par2-redundancy percent для налаштування розміру (і надлишковості) файлів відновлення у відсотках.ПРИМІТКА ПРО ДОСТУП ДО PCA PCA — це рішення для довгострокового архівування даних від OVH. Воно використовує дещо модифіковану версію OpenStack Swift, що додає затримку в процесі отримання даних. Це хороший вибір для конфігурації з кількома бекендами, де томи отримуються, тоді як інший бекенд використовується для зберігання маніфестів і сигнатур.
Бекенд вимагає встановлення python-swiftclient на системі. Також потрібен python-keystoneclient для взаємодії з сервісом ідентифікації Keystone від OpenStack. Дивіться ВИМОГИ.
Для автентифікації використовуються наступні змінні середовища: PCA_USERNAME (обов’язково), PCA_PASSWORD (обов’язково), PCA_AUTHURL (обов’язково), PCA_USERID (необов’язково), PCA_TENANTID (необов’язково, але потрібно вказати або ім’я тенанта, або ідентифікатор тенанта), PCA_REGIONNAME (необов’язково), PCA_TENANTNAME (необов’язково, але потрібно вказати або ім’я тенанта, або ідентифікатор тенанта).
Якщо користувач раніше автентифікувався, замість цього можна використовувати наступні змінні середовища: PCA_PREAUTHURL (обов’язково), PCA_PREAUTHTOKEN (обов’язково).
Якщо PCA_AUTHVERSION не вказано, за замовчуванням використовується версія 2.ПРИМІТКА ПРО БЕКЕНД PYDRIVE Бекенд pydrive вимагає встановлення пакета Python PyDrive на системі. Дивіться ВИМОГИ.
Існує два способи використання PyDrive: зі звичайним обліковим записом або з "обліковим записом служби". З обліковим записом служби створюється окремий обліковий запис, доступний лише через Google API, а не через веб-вхід. Зі звичайним обліковим записом ви можете зберігати резервні копії у вашому звичайному Google Drive.
Для використання облікового запису служби перейдіть до консолі розробників Google за адресою https://console.developers.google.com. Створіть проєкт і переконайтеся, що API Drive увімкнено для проєкту. У розділі "APIs and auth" натисніть "Create New Client ID", потім виберіть Service Account із ключем P12.
Завантажте файл ключа .p12 для облікового запису та конвертуйте його у формат .pem:
openssl pkcs12 -in XXX.p12 -nodes -nocerts > pydriveprivatekey.pem
Вміст файлу .pem слід передати змінній середовища GOOGLE_DRIVE_ACCOUNT_KEY для автентифікації.
Електронна адреса облікового запису використовуватиметься як частина URL. Дивіться ФОРМАТ URL вище.
Альтернативою є використання звичайного облікового запису. Для цього почніть так само, але під час створення нового Client ID виберіть "Installed application" типу "Other". Створіть файл із наступним вмістом і передайте його ім’я у змінну середовища GOOGLE_DRIVE_SETTINGS:
client_config_backend: settings
client_config:
client_id: <Client ID із консолі розробників>
client_secret: <Client secret із консолі розробників>
save_credentials: True
save_credentials_backend: file
save_credentials_file: <filename для кешування облікових даних>
get_refresh_token: True
У цьому сценарії частини імені користувача та хоста в URL не відіграють жодної ролі; важливий лише шлях. Під час першого запуску вам буде запропоновано відвідати URL у вашому браузері, щоб надати доступ до вашого диска. Після надання доступу ви отримаєте код підтвердження, який потрібно вставити назад у Duplicity. Облікові дані потім кешуються у файлі, вказаному вище, для подальшого використання.ПРИМІТКА ПРО БЕКЕНД RCLONE Rclone — це потужна програма командного рядка для синхронізації файлів і каталогів із різними постачальниками хмарного зберігання. Використання Після налаштування віддаленого сховища rclone за допомогою
rclone config
і успішного налаштування віддаленого сховища (наприклад, gdrive для Google Drive), якщо ви можете переглянути файли віддаленого сховища за допомогою
rclone ls gdrive:mydocuments
ви можете розпочати резервне копіювання за допомогою
duplicity /mydocuments rclone://gdrive:/mydocuments
Зверніть увагу на слеш після другої двокрапки. Деякі постачальники сховищ працюють із слешем або без нього після двокрапки, але деякі — ні. Оскільки duplicity видасть помилку про неправильно сформований URL, якщо слеш відсутній, завжди додавайте його після двокрапки, і бекенд обробить це за вас. Опції Зверніть увагу, що всі опції rclone також можна встановити через змінні середовища. Це детально описано тут:
https://rclone.org/docs/
Коротко, вам потрібно взяти довгу назву опції, видалити початковий --, замінити - на _, зробити великими літерами та додати префікс RCLONE_. Наприклад,
еквівалент '--stats 5s' буде змінною середовища RCLONE_STATS=5sПРИМІТКА ПРО БЕКЕНД SLATE З бекендом slate використовуються три змінні середовища:
1. ‘SLATE_API_KEY‘ — ваш ключ API Slate
2. ‘SLATE_SSL_VERIFY‘ — або '1' (True), або '0' (False) для перевірки SSL (необов’язково, за замовчуванням True)
3. ‘PASSPHRASE‘ — ваш пароль GPG для шифрування (необов’язково, буде запитаний, якщо не встановлено або не використовується з параметром ‘--no-encryption‘)
Для використання бекенду slate використовуйте наступну схему:
slate://[slate-id]
Наприклад, повне резервне копіювання поточного каталогу в Slate:
duplicity full . "slate://6920df43-5c3w-2x7i-69aw-2390567uav75"
Ось демонстрація: https://gitlab.com/Shr1ftyy/duplicity/uploads/675664ef0eb431d14c8e20045e3fafb6/slate_demo.mp4ПРИМІТКА ПРО SSH БЕКЕНДИ Бекенди SSH підтримують протоколи передачі sftp і scp/ssh. Це відома проблема, що викликає плутанину у користувачів, оскільки ці протоколи принципово різні. Якщо ви плануєте використовувати один із цих бекендів, ознайомтеся з вимогами до сервера для підтримки доступу sftp або scp/ssh. Щоб ще більше заплутати, користувач може вибрати між кількома бекендами SSH за допомогою префікса схеми: paramiko+ (за замовчуванням), pexpect+, lftp+... .
paramiko та pexpect підтримують --use-scp, --ssh-askpass і --ssh-options. Тільки бекенд pexpect дозволяє визначити --scp-command і --sftp-command.
Бекенд SSH paramiko (за замовчуванням) — це повна повторна реалізація протоколів SSH у Python. Переваги — швидкість і підтримуваність. Незначний недолік — необхідність додаткових пакетів, перелічених у ВИМОГАХ. У режимі sftp (за замовчуванням) усі операції виконуються через відповідні команди sftp. У режимі scp (--use-scp) для операцій put/get використовується доступ scp, але перелік виконується через віддалену оболонку ssh.
Бекенд SSH pexpect — це застарілий бекенд SSH, який використовує бінарні файли командного рядка ssh через pexpect. Старіші версії використовували scp для операцій get і put, а sftp — для операцій списку та видалення. Поточна версія використовує sftp для всіх чотирьох підтримуваних операцій, якщо не вказано опцію --use-scp для повернення до старої поведінки.
Бекенд SSH lftp існує лише тому, що lftp може взаємодіяти з бінарними файлами командного рядка ssh. Він призначений як останній засіб, якщо вищезгадані опції з якихось причин не працюють. Чому використовувати sftp замість scp? Перехід на sftp було зроблено для того, щоб дозволити віддаленій системі використовувати chroot для резервного копіювання, що забезпечує кращу безпеку, а також тому, що sftp не страждає від проблем із цитуванням оболонки, як scp. Scp також не підтримує будь-який вид переліку файлів, тому для цього режиму бекенду завжди потрібен доступ sftp або ssh. Sftp не має цих обмежень, але вимагає запуску служби sftp на сервері бекенду, що іноді неможливо.ПРИМІТКА ПРО ПЕРЕВІРКУ SSL-СЕРТИФІКАТІВ Перевірка сертифікатів, реалізована станом на [02.2016], наразі доступна лише в бекендах webdav і lftp. Старіші версії Python 2.7.8- і старіші бінарні файли lftp потребують файлової бази даних сертифікатів сертифікаційних центрів (cacert file).
Новіші версії Python 2.7.9+ і останні версії lftp підтримують системні сертифікати за замовчуванням (зазвичай у /etc/ssl/certs) і дозволяють вказати альтернативну папку cacert через --ssl-cacert-path.
Файл cacert має бути текстовим файлом у форматі PEM, як наразі надається проєктом CURL. Див.
http://curl.haxx.se/docs/caextract.html
Після створення/отримання дійсного файлу cacert його слід скопіювати до одного з таких розташувань:
~/.duplicity/cacert.pem
~/duplicity_cacert.pem
/etc/duplicity/cacert.pem
Duplicity шукає його в такому порядку і видасть помилку, якщо не знайде. Однак ви можете вказати опцію --ssl-cacert-file <file>, щоб вказати duplicity на копію в іншому розташуванні.
Нарешті, є опція --ssl-no-check-certificate для повного відключення перевірки сертифікатів, якщо бракує бібліотеки ssl або перевірка не потрібна. Використовуйте її з обережністю, оскільки навіть для серверів із самопідписаними сертифікатами надання приватного сертифіката CA вручну є безпечнішим варіантом.ПРИМІТКА ПРО ДОСТУП ДО SWIFT (OPENSTACK OBJECT STORAGE) Swift — це служба об’єктного зберігання OpenStack.
Бекенд вимагає встановлення python-swiftclient на системі. Також потрібен python-keystoneclient для використання служби ідентифікації Keystone від OpenStack. Дивіться ВИМОГИ.
Для автентифікації використовуються наступні змінні середовища:
SWIFT_USERNAME (обов’язково),
SWIFT_PASSWORD (обов’язково),
SWIFT_AUTHURL (обов’язково),
SWIFT_TENANTID або SWIFT_TENANTNAME (обов’язково з SWIFT_AUTHVERSION=2, також може бути визначено в SWIFT_USERNAME, наприклад, SWIFT_USERNAME="tenantname:user"),
SWIFT_PROJECT_ID або SWIFT_PROJECT_NAME (обов’язково з SWIFT_AUTHVERSION=3),
SWIFT_USERID (необов’язково, потрібно лише для IBM Bluemix ObjectStorage),
SWIFT_REGIONNAME (необов’язково).
Якщо користувач раніше автентифікувався, замість цього можна використовувати наступні змінні середовища: SWIFT_PREAUTHURL (обов’язково), SWIFT_PREAUTHTOKEN (обов’язково).
Якщо SWIFT_AUTHVERSION не вказано, за замовчуванням використовується версія 1.ПРИМІТКА ПРО СИМЕТРИЧНЕ ШИФРУВАННЯ ТА ПІДПИС Підписування та симетричне шифрування одночасно за допомогою бінарного файлу gpg у командному рядку, як це використовується в duplicity, є особливо складною проблемою. Тести показали, що наступні комбінації працюють:
1. Налаштуйте gpg-agent належним чином. Використовуйте опцію --use-agent і введіть обидва паролі (симетричний і ключ підпису) у діалоговому вікні gpg-agent.
2. Використовуйте PASSPHRASE для симетричного шифрування на ваш вибір, але ключ підпису має порожній пароль.
3. Використаний PASSPHRASE для симетричного шифрування та пароль ключа підпису є ідентичними.ПРИМІТКА ПРО БЕКЕНД XORRISO Цей бекенд використовує інструмент xorriso для додавання резервних копій до оптичних носіїв або образів ISO9660.
Використовуйте наступні змінні середовища для додаткових налаштувань:
XORRISO_PATH — встановлює альтернативний шлях до виконуваного файлу xorriso
XORRISO_WRITE_SPEED — визначає швидкість запису на оптичний диск. Одне з [min, max]
XORRISO_ASSERT_VOLID — визначає необхідний ідентифікатор тому ISO. Перериває роботу, якщо фактичний ідентифікатор тому відрізняється.
XORRISO_ARGS — лише для експертів. Передає довільні аргументи до xorriso. Приклад: XORRISO_ARGS='-md5 all'ПРОБЛЕМА ARGPARSE Після переходу з optparse на argparse одна помилка переслідує наші зусилля. Значення, які виглядають як опції, інтерпретуються як опції. Це означає, що щось на кшталт
--gpg-options '--homedir=/home/user'
не розглядається як опція та відповідне значення, а як дві різні опції, що призводить до того, що --gpg-options скаржиться на відсутність значення. Щоб обійти цю проблему, потрібно зв’язати їх за допомогою '=' так:
--gpg-options="--homedir=/home/user"
Помилка argparse описана тут:
https://github.com/python/cpython/issues/53580 .
Якщо ви бажаєте, можете перейти за посиланням і додати підтримуючий коментар, щоб сприяти виправленню. За достатньої кількості голосів помилку може бути виправлено.
Зверніть увагу, що в самому звіті про помилку обхід через '=' не згадується, але ми виявили, що це найчистіший і найчитабельніший із відомих нам обхідних шляхів.ВІДОМІ ПРОБЛЕМИ / ПОМИЛКИ Жорсткі посилання наразі не підтримуються (вони обробляються як звичайні файли без посилань).
Некоректні сигнатури будуть вважатися порожніми замість запису відповідного повідомлення про помилку.ФОРМАТ ОПЕРАЦІЙ ТА ДАНИХ Цей розділ описує основні операції duplicity та формат її файлів даних. Читання цього розділу не є обов’язковим для використання duplicity.
Файли, які використовує duplicity для зберігання даних резервного копіювання, є tar-файлами у форматі GNU tar. Для інкрементних резервних копій нові файли зберігаються у tar-файлі звичайним чином. Але коли файл змінюється, замість зберігання повної копії файлу зберігається лише diff, створений за допомогою rdiff(1). Якщо файл видалено, у tar зберігається файл нульової довжини. Можна відновити архів duplicity "вручну", використовуючи tar, а потім cp, rdiff і rm за потреби. Ці архіви duplicity мають розширення difftar.
Як повні, так і інкрементні набори резервних копій мають однаковий формат. По суті, повний набір резервних копій є інкрементним, створеним із порожньої сигнатури (див. нижче). Файли в повних наборах резервних копій починаються з duplicity-full, тоді як інкрементні набори починаються з duplicity-inc. Під час відновлення duplicity застосовує патчі по порядку, тому видалення, наприклад, повного набору резервних копій може зробити пов’язані інкрементні набори непридатними для використання.
Щоб визначити, які файли були видалені, і обчислити diff для змінених файлів, duplicity потрібна інформація про попередні сеанси. Ця інформація зберігається у вигляді tar-файлів, де дані кожного запису містять сигнатуру (створену rdiff) файлу замість вмісту файлу. Ці набори сигнатур мають розширення sigtar.
Файли сигнатур не потрібні для відновлення набору резервних копій, але без актуальної сигнатури duplicity не може додати інкрементну резервну копію до існуючого архіву.
Щоб заощадити пропускну здатність, duplicity створює повні набори сигнатур і інкрементні набори сигнатур. Повний набір сигнатур створюється для кожного повного резервного копіювання, а інкрементний — для кожного інкрементного резервного копіювання. Вони починаються з duplicity-full-signatures і duplicity-new-signatures відповідно. Ці сигнатури зберігаються як локально, так і віддалено. Віддалені сигнатури шифруються, якщо увімкнено шифрування. Локальні сигнатури не шифруються і зберігаються в каталозі архівів (див. --archive-dir).ВИМОГИ Duplicity вимагає POSIX-подібної операційної системи з встановленим інтерпретатором Python версії 3.8+. Найкраще використовувати її під GNU/Linux.
Деякі бекенди також вимагають додаткових компонентів (ймовірно, доступних як пакети для вашої конкретної платформи):
**Amazon Drive backend**
python-requests - http://python-requests.org
python-requests-oauthlib - https://github.com/requests/requests-oauthlib
**azure backend (Azure Storage Blob Service)**
Microsoft Azure Storage Blobs client library for Python - https://pypi.org/project/azure-storage-blob/
**boto3 backend (S3 Amazon Web Services, Google Cloud Storage) (за замовчуванням)**
boto3 version 1.x - https://github.com/boto/boto3
**box backend (box.com)**
boxsdk - https://github.com/box/box-python-sdk
**cfpyrax backend (Rackspace Cloud) і hubic backend (hubic.com)**
Rackspace CloudFiles Pyrax API - http://docs.rackspace.com/sdks/guide/content/python.html
**dpbx backend (Dropbox)**
Dropbox Python SDK - https://www.dropbox.com/developers/reference/sdk
**gdocs gdata backend (застарілий)**
Google Data APIs Python Client Library - http://code.google.com/p/gdata-python-client/
**gdocs pydrive backend (за замовчуванням)**
див. pydrive backend
**gio backend (Gnome VFS API)**
PyGObject - http://live.gnome.org/PyGObject
D-Bus (dbus) - http://www.freedesktop.org/wiki/Software/dbus
**lftp backend (потрібен для ftp, ftps, fish [через ssh] — також підтримує sftp, webdav[s])**
LFTP Client - http://lftp.yar.ru/
**MEGA backend (працює лише для акаунтів, створених до листопада 2018) (mega.nz)**
megatools client - https://github.com/megous/megatools
**MEGA v2 і v3 backend (працює для всіх акаунтів MEGA) (mega.nz)**
MEGAcmd client - https://mega.nz/cmd
**multi backend**
Multi — зберігання в кількох бекендах
(також див. ПРИМІТКА ПРО БЕКЕНД MULTI нижче).
**ncftp backend (ftp, вибір через ncftp+ftp://)**
NcFTP - http://www.ncftp.com/
**OneDrive backend (Microsoft OneDrive)**
python-requests-oauthlib - https://github.com/requests/requests-oauthlib
**Par2 Wrapper Backend**
par2cmdline - http://parchive.sourceforge.net/
**pydrive backend**
PyDrive — бібліотека-обгортка google-api-python-client - https://pypi.python.org/pypi/PyDrive
(також див. ПРИМІТКА ПРО БЕКЕНД PYDRIVE нижче).
**rclone backend**
rclone - https://rclone.org/
**rsync backend**
rsync client binary - http://rsync.samba.org/
**ssh paramiko backend (за замовчуванням)**
paramiko (SSH2 для python) - http://pypi.python.org/pypi/paramiko (завантаження); http://github.com/paramiko/paramiko (сторінка проєкту)
pycrypto (Python Cryptography Toolkit) - http://www.dlitz.net/software/pycrypto/
**ssh pexpect backend (застарілий)**
sftp/scp client binaries OpenSSH - http://www.openssh.com/
Python pexpect module - http://pexpect.sourceforge.net/pexpect.html
**swift backend (OpenStack Object Storage)**
Python swiftclient module - https://github.com/openstack/python-swiftclient/
Python keystoneclient module - https://github.com/openstack/python-keystoneclient/
**webdav backend**
файл бази даних сертифікаційних центрів для перевірки SSL-сертифікатів HTTPS-з’єднань - http://curl.haxx.se/docs/caextract.html
(також див. ПРИМІТКА ПРО ПЕРЕВІРКУ SSL-СЕРТИФІКАТІВ).
Python kerberos module для автентифікації kerberos - https://github.com/02strich/pykerberos
**MediaFire backend**
MediaFire Python Open SDK - https://pypi.python.org/pypi/mediafire/
**xorriso backend**
xorriso - https://www.gnu.org/software/xorriso/АВТОР Оригінальний автор - Ben Escoto <bescoto@stanford.edu>
Поточний супроводжувач - Kenneth Loafman <kenneth@loafman.com>
Постійні учасники
Edgar Soldin, Mike Terry
Більшість бекендів були внесені індивідуально. Інформацію про їх авторство можна знайти у відповідних заголовках файлів.
Також ми хотіли б подякувати всім, хто надсилає звіти про проблеми на поштову розсилку або на launchpad, надсилає патчі чи робить внесок іншим чином. Duplicity не був би таким стабільним і корисним без вас.
Особлива подяка rsync.net, постачальнику хмарного сховища з явною підтримкою duplicity, за кілька грошових пожертв і за надання спеціального тарифу "друзі duplicity" для їхньої служби віддаленого резервного копіювання. Звертайтеся за деталями на info@rsync.net.ДИВІТЬСЯ ТАКОЖ python(1), rdiff(1).
Версія 3.0.5.1 25 червня 2025 DUPLICITY(1)
23 вересня 2025
man duplicity uk i18n
Підписатися на:
Дописати коментарі (Atom)
Немає коментарів:
Дописати коментар