Restic: Rclone делает большинство бэкэндов избыточными

В этом даже нет никакого смысла. Rclone - это утилита передачи, а не утилита резервного копирования. Он не может заменить restic репозитории.

Он, вероятно, просто имеет в виду отказаться от собственного бэкэнд-кода restic, за исключением кода для rclone, чтобы интеграция с rclone стала той, через которую проходят все бэкенды.

@jtagcat Я думаю, вы имеете в виду «бэкэнд», а не «репозитории».

Я согласен с этим предложением по духу.
На самом деле удаление всех других серверных программ может быть слишком разрушительным, но, по крайней мере, в документации можно выделить rclone как предпочтительный серверный процесс и пометить другие удаленные серверные модули как «устаревшие».

На самом деле я думаю, что мы можем добиться большего, если пометим серверные ВМ как унаследованные.
В документации пометьте их как устаревшие, но во внутренних делах переводите устаревшие в rclone на лету. На некоторых серверах rclone вы можете напрямую переводить ( пример из моей головы - http ), другие вы переводите во временный файл конфигурации, а затем используете --config /path/to/config с rclone.

Если вы спросите меня, как пользователя restic, я бы сказал, что использовать rclone для всех бэкэндов было бы ужасно. Это требует настройки конфигураций rclone для ваших бэкэндов и сохранения двоичного файла rclone, первый из которых очень сильно удаляет ad-hoc и свободную от конфигурации природу restic, что действительно приятно. Что мне не нравится в rclone, так это то, что я должен его настроить перед запуском, вместо того, чтобы просто дать ему два URI в качестве источника и цели.

Лучшее предложение, IMO, - если бы мы могли встроить rclone в restic, чтобы вы могли продолжать использовать restic так же, как и сейчас, но с бэкэнд-поддержкой, которую предоставляет rclone. Если бы это произошло, было бы нормально отказаться от текущего внутреннего кода, предполагая, что соответствующий код rclone предоставляет те же функции.

Как бы вы встроили rclone в рестик? Если бы этот вопрос был решительно закрыт, это нужно было бы сделать.
Вы бы сказали, что «rclone не найден, запущен curl https://rclone.org/install.sh | sudo bash » (curl и sudo могут не существовать в системе)? Потому что вы не можете просто добавить его как зависимость в менеджеры пакетов, если вы не устанавливаете через pkg manager.

Трансляция текущих бэкэндов во временные конфигурации rclone на лету возможна , когда я использую только rclone для разных вещей, меня это тоже немного раздражает.

Как бы вы встроили rclone в рестик?

Я не исследовал, что возможно в этом отношении. Я думал об этом несколько раз.

Подумал об этом немного подробнее, встраивание, вероятно, закончится как «установка как зависимость», чтобы позволить rclone быть в актуальном состоянии без необходимости обновления restic.
Вероятно, лучшим способом было бы добавить rclone в качестве зависимости, где это возможно, и повсюду иметь «rclone not found, install» (когда зависимость rclone не найдена по какой-либо причине в качестве резервной копии).

Хотя установщик rclone представляет несколько проблем. Сделайте его совместимым с posix.

• curl - я видел одну или две системы, где ее не устанавливали из коробки.
• sudo - то же, что и выше
• unzip / другая вещь для распаковки, вы, вероятно, испытали это, устанавливая rclone на минимальной установке.

Я больше думаю о том, чтобы сделать rclone встраиваемым как библиотеку al или что-то еще, чтобы его можно было интегрировать в restic. Выпустить новую рестичную версию не составит труда, если в rclone есть что-то, что обновляется до такой степени, что это требует нового выпуска.

Вероятно, лучшим способом было бы добавить rclone в качестве зависимости, где это возможно, и повсюду иметь «rclone not found, install» (когда зависимость rclone не найдена по какой-либо причине в качестве резервной копии).

Извините за это, но попытка (автоматически) установить программное обеспечение на машину пользователя - (вероятно) худшая идея, которую я когда-либо читал в обсуждениях проблем Restic.

Потому что:

• Среда может не допускать установку нового программного обеспечения.
• Пользователь (или системный администратор) может не захотеть устанавливать новое программное обеспечение.
• Доступ в Интернет без явного запроса может быть нежелательным.
• Установщик может угадать неправильное место для нового программного обеспечения.
• Установка нового программного обеспечения может мешать нормальным функциям среды (например, предоставляя исполняемые файлы вне обычных мест, где пользователи / менеджеры пакетов / администраторы / аудиторы / все, что еще ожидают их найти, и тем самым создавая путаницу).
• Установка может завершиться ошибкой или дать неверные результаты; либо очевидным образом, либо тонким и трудным для обнаружения способом.

Вероятно, лучшим способом было бы добавить rclone в качестве зависимости, где это возможно, и повсюду иметь «rclone not found, install» (когда зависимость rclone не найдена по какой-либо причине в качестве резервной копии).

Извините за это, но попытка (автоматически) установить программное обеспечение на машину пользователя - (вероятно) худшая идея, которую я когда-либо читал в обсуждениях проблем Restic.

Потому что:

* The environment may not allow installation of new software.

* The user (or the system administrator) may not want new software to be installed.

* Accessing the Internet without explicit request may be undesirable.

* The installer may guess a wrong place for the new software.

* Installation of new software may interfere with the normal functions of the environment (for example, by providing executables outside of regular places where users/package managers/administrators/auditors/whatever else expect to find them, and thus creating confusion).

* The installation may fail or produce incorrect results; either in an obvious manner, or in a subtle and hard-to-discover way.

да, что вы предлагаете?

я имел в виду вот что:

restic rclone not found...
Install 'rclone' with command 'curl https://rclone.org/install.sh | sudo bash'  to provide rclone backends? [Y/n]

Я бы не стал заменять существующие бэкенды на rclone, если последний не будет успешно встроен как библиотека и, следовательно, всегда включен в дистрибутив restic.

Пока это не будет сделано (или вместо этого), я бы сделал rclone дополнительной зависимостью в диспетчерах пакетов, которые позволяют это (например, apt и portage). Если rclone не установлен, restic может показать сообщение, относящееся к веб-странице rclone, предлагающее либо (1) обратиться к странице, чтобы узнать о способах установки, (2) установить rclone с помощью системного диспетчера пакетов, (3) выдать команду "curl + bash "с предупреждением, что" убедитесь, что вы знаете, что делаете ".

Я бы не стал выполнять команду от имени пользователя, даже если бы спросил об этом.

Природа RESTIC (особенно в Linux) как статического двоичного файла без зависимостей была АБСОЛЮТНО НЕЦЕННОЙ в сценариях восстановления и восстановления с нуля.

В настоящее время я предпочитаю использовать "rest-server" (с интерфейсом haproxy для аутентификации) для внутренних резервных копий и полагаюсь на то, что restic поддерживает его изначально. Если бы мне пришлось возиться с RESTIC и RCLONE во время критичного по времени восстановления, я бы, вероятно, нашел другое решение.

Природа RESTIC (особенно в Linux) как статического двоичного файла без зависимостей была АБСОЛЮТНО НЕЦЕННОЙ в сценариях восстановления и восстановления с нуля.

В настоящее время я предпочитаю использовать "rest-server" (с интерфейсом haproxy для аутентификации) для внутренних резервных копий и полагаюсь на то, что restic поддерживает его изначально. Если бы я был вынужден возиться с RESTIC _и_ RCLONE во время критичного по времени восстановления, я бы, вероятно, нашел другое решение.

Бэкэнд Rest не будет удален, поскольку он уникален для Restic. Я тоже использую rest-server, очень удобно просто залить учетные данные.

Я думаю, что проблема в состоянии «только если rclone встроен». Поскольку это никому не нужно (хотя встроенный rclone был бы необходим). Я предполагаю, что прямо сейчас это больше `` не добавляйте новые бэкенды, то, что еще не поддерживается rclone '', и запрос функции для кого-то (возможно, через много-много месяцев, меня), кто потрудится сделать это, встроить rclone .

Что касается базовых версий, необходимо выпустить альтернативные выпуски, которые не используют bzip (насколько я слышал, единственная причина установки bzip - restic). Что касается этого, если никто не сделает этого, я, вероятно, сделаю это, так как задача для меня - # 2705.

Единственное, что мне не нравится в rclone, это то, что я _ должен_ настраивать его перед запуском, вместо того, чтобы просто дать ему два URI в качестве источника и цели.

@rawtaz
Вы можете сделать это , так как rclone не требует ничего настраивать.
Вы можете полностью удалить любые _ ~ / .rclone.conf_ или _ ~ / .config / rclone / rclone.conf_, они просто запрашивают параметры по умолчанию или резервные параметры.
А теперь попробуйте это:

rclone copy ./file.txt :sftp:subdir --sftp-host=localhost --sftp-key-file=~/.ssh/id_rsa

Это совершенно верно и описано в документации: https://rclone.org/docs/#backend -path-to-dir

Вы также можете передать все параметры через среду или смешать их с аргументами CLI:

export RCLONE_SFTP_HOST=localhost
export RCLONE_SFTP_KEY_FILE=~/.ssh/id_rsa
rclone ls :sftp:

Использование rclone в качестве библиотеки обсуждается в https://github.com/rclone/rclone/issues/633.