В соответствии с этим вы можете использовать переменную окружения RESTIC_PASSWORD, чтобы указать пароль.

Как уже сказал @pvgoran , вы можете использовать переменную окружения RESTIC_PASSWORD . Это описано в руководстве здесь http://restic.readthedocs.io/en/latest/Manual/#initialize -a-repository. Если у вас есть идея, как это лучше документировать, создайте запрос на перенос.

Также существует проблема № 278, которая касается чтения пароля из файла.

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

Ой, а я думал, что прочитал этот раздел ...

Может быть, дать этому абзацу отдельный заголовок или подзаголовок? Первые четыре абзаца этого раздела охватывают все, что касается инициализации репозитория. Автоматизация резервного копирования не подходит под это.

Спасибо @pvgoran за быстрый ответ, кстати. :улыбка:

Просто быстрый ответ на этот вопрос. Что произойдет, если резервное копирование не завершится к тому времени, когда cron снова выполнит restic?

В этом случае restic запустит вторую (параллельную) резервную копию, которая использует данные, уже загруженные первой (все еще выполняющейся) резервной копией. Думаю, обе резервные копии закончатся почти одновременно. Будет некоторое дублирование данных, которое будет удалено при следующем запуске команды prune . Однако это не приведет к повреждению или потере данных. Формат репозитория разработан таким образом, чтобы разрешить параллельную загрузку данных.

Это интересный случай, о котором я еще не думал. Как вы думаете, нам нужен код, чтобы проверить, выполняется ли уже та же резервная копия на том же хосте, и выйти в этом случае?

@ fd0 Возможно, да. Только для той же резервной копии. Или чистый способ сценария автоматического резервного копирования: подойдут некоторые инструкции, например, «восстановление резервной копии», затем «восстановление блокировки», затем «восстановление восстановления». Но было бы неплохо не беспокоиться об этих дополнительных командах.

restic backup за которым следуют restic forget и restic prune - это обычный рабочий процесс, который очищает его. Я все равно добавлю еще одну проблему, чтобы мы могли отследить эту идею.

Круто, спасибо! А пока я буду использовать этот поток.

Другой вариант, который может помочь, - это параметр тайм-аута. Если вы знаете, что ваше задание cron планирует резервное копирование каждые X часов, вы можете передать --timeout для restic, чтобы оно завершилось до начала следующего. Это было бы удобно и для других вещей. (это может уже существовать, я новичок в restic)

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

Может быть, сценарий запуска, который похож на многие другие сценарии запуска Linux, который принимает PID restic при запуске и сохраняет его в файл tmp, а затем удаляет его, когда restic завершается. Каждый раз, когда запускается сценарий, он будет проверять наличие файла. Для каждой уникальной резервной копии по расписанию вам понадобится отдельный файл tmp.

К сожалению, любые средства обнаружения запущенного экземпляра restic не работают на ВСЕХ бэкэндах (SFTP, REST, S3 ...), кроме локального.

@zcalusic для этого мы могли бы использовать информацию, хранящуюся в файлах блокировки: https://github.com/restic/restic/blob/master/src/restic/lock.go#L27 -L33, возможно, добавить список файлов для резервного копирования или точных аргументов командной строки или чего-то подобного.

Я до сих пор не понимаю, как бы restic на машине A, обнаружив блокировку на резервном сервере B, различать a) текущий сеанс restic на машине C и b) устаревшую блокировку, оставшуюся после отказа restic на машине C?

Или мы начинаем здесь говорить о механизмах RPC? Или, что еще лучше, менеджеры распределенных блокировок? 😄

@zcalusic Я говорю о # 711: обнаружение, когда запускается вторая резервная копия с теми же каталогами на той же машине. Это должно быть возможно.

@bwmarrin Я не понимаю, что вы предлагаете:

Если вы знаете, что ваше задание cron планирует резервное копирование каждые X часов, вы можете передать --timeout для restic, чтобы оно завершилось до начала следующего.

Либо резервное копирование выполняется до конца, либо оно отменяется / прекращается. Я не думаю, что возможно каким-то образом рассчитать время для резервного копирования, которое занимает самое большее время, указанное в гипотетическом параметре --timeout . Как это могло работать?

Не могли бы вы описать семантику такого параметра? Благодаря!

@ fd0 Я говорю, что если резервное копирование не завершается в пределах значения --timeout, оно прекращается. Я понимаю, это означает, что это будет неполная или незаконченная резервная копия. Однако, учитывая инкрементный дизайн Restic, это не имеет большого значения. При следующем вызове резервной копии она начнется с того места, где была остановлена.

Это означает, что если у вас есть задание cron, которое запланировано на ежечасное выполнение, и вы передаете параметр --timeout 50m для restic. Резервное копирование будет прервано / прекращено, если оно займет более 50 минут. В этом случае через 10 минут задание cron снова запустится и возобновит работу с того места, где было остановлено. Это предотвратит одновременное выполнение нескольких экземпляров одной и той же резервной копии.

Спасибо за объяснение. Я считаю, что это плохая идея. Что произойдет, если хранилище резервных копий работает медленно, а вы этого не заметите (кто-то в вашей сети забыл клиент BitTorrent, который максимизирует вашу пропускную способность восходящего потока), поэтому резервное копирование не завершается, прерывается, снова перезагружается, снова прерывается и т. Д. . Тогда у вас никогда не будет полной рабочей резервной копии.

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

Кроме того, вы можете легко реализовать это поведение, используя стандартную утилиту timeout (из coreutils), запустив timeout 40m restic backup [...] . Поэтому я не думаю, что добавление этой опции к restic - хорошая идея.

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

@ Karl-Gustav, может быть, ты сможешь добиться этого с помощью скриптов. https://stackoverflow.com/a/1985512/244009

Это было немного сложнее, чем мои замки :-) Я просто использую if file {wait 5sec and check again}

Возможно, я немного опоздал с обсуждением, но я создал несколько модулей systemd, которые вы можете найти здесь .
Это мои файлы restic config, они могут кому-то пригодиться.

Привет, я читаю о том, как использовать restic для планирования резервного копирования. На данный момент моя идея состоит в том, чтобы использовать anacron для планирования, например, резервного копирования в Backblaze 2 дня в неделю. Дело в том, что если мое резервное копирование запланировано с помощью anacron, например, во вторник и пятницу в 12:00, а мой ноутбук выключен во вторник и не запускать его снова до пятницы, скажем, в 11:59, что произойдет? AFAIK (и если я не ошибаюсь) anacron должен начать пропущенную работу вторника; а через минуту (пока запущен первый экземпляр restic) будет запущено второе резервное копирование, создав 2 одновременных резервных копии для одного и того же каталога?

Или это какой-то файл блокировки / tmp для предотвращения запуска второго экземпляра?
Как мне управлять этим, чтобы правильно запланировать резервное копирование? Спасибо :)

@gerardbosch Привет! Этот вопрос больше подходит для форума , учтите это в следующий раз :)

Один из способов справиться с этим - написать сценарий, который выполняет за вас выполнение restic, и в рамках этого создает файл выполнения (например, /var/run/restic.pid содержащий PID процесса restic`), который затем может проверьте, работает ли рестик уже.

Это никоим образом не будет harm , если вы будете запускать два параллельных резервного копирования, но это, конечно, бессмысленно, если они охватывают более или менее одинаковые файлы и на определенный момент времени.

Я не знаю, пытается ли Anacron наверстать упущенное при пропущенных запусках резервного копирования, полагаю, он должен указать в своей документации. Если вы используете macOS и используете launchd для планирования, у вас есть возможность сделать это или нет, решать вам.

К вашему сведению, больше людей попадают сюда из результатов поиска Google:

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

https://github.com/erikw/restic-systemd-automatic-backup

@erikw Фантастический сценарий расписания, поздравляю!
Некоторые вопросы:

• В чем главное преимущество использования таймеров systemd перед cron или anacron?
• Можно ли установить скрипты / setup systemd в homedir вместо / etc?
• Может ли вкладка anacron находиться где-нибудь в $ HOME?

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

@gerardbosch

• Если у вас есть система systemd, неплохо иметь возможность использовать инструменты по умолчанию, не нужно устанавливать демон cron. Вы получаете полный контроль над статусом невыполненных заданий и, например, можете видеть, когда задание будет выполнено в следующий раз. См. Краткое введение в Arch wiki . Я бы сказал, что просто поиграйте с этим самостоятельно - это самый интересный способ научиться.

• Да, я запускаю несколько таймеров systemd для своего локального пользователя. Проверьте мои точечные файлы на --user для управления таймерами пользователя вместо системных таймеров:

$ systemctl --user list-timers

• Кажется, что они обычно находятся в /var/spool . Можно ли переместить в ~/ я не знаю. https://askubuntu.com/questions/216692/where-is-the-user-crontab-stored

Как здесь еще не упоминалось, Backupninja - отличный способ управлять расписанием. Restic поддержка добавляется в запросе слияния ; это просто еще не было совершено. Тем не менее, все основные функции должны быть там.

@colans Backupninja потрясающий, не могу дождаться, когда смогу использовать его с отдыхом! Спасибо за эту работу.

restic backup за которым следуют restic forget и restic prune - это обычный рабочий процесс, который очищает его. Я все равно добавлю еще одну проблему, чтобы мы могли отследить эту идею.

Если я настраиваю ежедневную запланированную задачу / задание cron без ожидания возможных параллельных заданий, должен ли сценарий по-прежнему выполнять restic backup -> restic forget -> restic prune ? Похоже, это увеличивает накладные расходы, если мы выполняем только один экземпляр за раз

Можем ли мы снова открыть это как задачу документации? Я думаю, нам следует добавить в руководство раздел «Планирование», чтобы прояснить эту тему. Можно сказать что-то вроде:

Планирование выходит за рамки Restic. Однако есть внешние инструменты, которые можно использовать для этой цели.

• Backupninja вместе с веткой поддержки Restic
• Автоматическое восстановление резервных копий с использованием системных служб и таймеров
• Конфиги Restic Backup

Мысли?

Еще предложения открыть заново. Если restic не поддерживает планирование / мониторинг резервного копирования, в документации это можно объяснить и связать с тем, что поддерживает, поскольку это основной способ использования инструментов резервного копирования.

@SigmaX, как планировать, полностью зависит от того, какая ОС и программное обеспечение есть в вашем распоряжении. Я думаю, что подобные предложения выходят за рамки документации для беспокойства, но это действительно может быть полезная статья в чьем-то блоге или даже в разделе рецептов форума. Он также может быть кандидатом в раздел Примеры на веб-сайте restic doc по адресу https://restic.readthedocs.io/en/latest/080_examples.html , но он должен быть написан таким образом, чтобы для него требовалось минимум обслуживания, поскольку мы не хотим поддерживать набор подробных инструкций о том, как запланировать это на нескольких разных платформах (поскольку это довольно сложная тема). С учетом всего сказанного, в сети уже есть несколько статей и примеров по этому поводу (например, с cron и systemd), если это действительно нужно искать. Я не совсем уверен, что это необходимо на веб-сайте документации.

Я не совсем уверен, что это необходимо на веб-сайте документации.

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

По крайней мере, раздел документации может сэкономить время пользователей: указав, что им нужно поискать где-нибудь еще / найти другой инструмент для настройки рутинного резервного копирования с помощью restic.

Мне кажется, что наличие инструмента резервного копирования без заметных документов о том, как составить график, похоже на продажу автомобиля без колес.

На самом деле, нет. Мы «продаем» вам программу, в которой вы указываете, что нужно резервировать, и она поддерживает это. Как часто вы хотите это делать - отдельный вопрос :) Но я отвлекся.

Я ожидаю, что большинство пользователей, если не найдут определенную тему в документации, просто воспользуются ею DDG / Google, а затем найдут ответы в течение минуты или двух. Но это не значит, что мы не должны добавлять какой-либо указатель в документацию, даже если мы не детализируем подробности того, как настроить различные программы для планирования.

Мы «продаем» вам программу, в которой вы указываете, что нужно резервировать, и она поддерживает это. Как часто вы хотите это делать - отдельный вопрос :)

И совершенно законно сказать: «Это комплект для рукоделия - иди и найди свои собственные колеса!»

Я ожидаю, что большинство пользователей, если не найдут определенную тему в документации, просто воспользуются ею DDG / Google, а затем найдут ответы в течение минуты или двух.

На самом деле, поиск в Google "расписания восстановительного резервного копирования" принес мне первое совпадение: smile:

2122 связан, поскольку он предоставляет несколько примеров таймеров systemd и другие обсуждения, касающиеся планирования.

Я думаю, что подход с «минимальным обслуживанием» здесь кажется разумным ... может быть, включить намек на ведение журнала вывода и предотвращение одновременного выполнения нескольких операций?

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

Мне нравится эта идея. Позже на этой неделе я сделаю черновик, скорее всего, для того, чтобы разместить небольшой раздел «указатель» под разделом резервного копирования в документации.