根据这个，你可以使用环境变量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 unlock”然后“ restic prune”。 但是不必担心那些额外的命令会很好。

restic backup然后是restic forget和restic prune是通常的工作流程，它将对其进行清理。 无论如何，我都会添加另一个问题，因此我们可以跟踪这个想法。

太好了，谢谢！ 现在，我将使用该流程。

此处可能有帮助的另一个选项是超时参数。 如果您知道cron作业每X个小时安排一次备份，则可以将--timeout传递给restic，这样它将在下一个备份开始之前结束。 对于其他事情也很方便。 （这可能已经存在，我是Restic的新手）

检测到Restic已经开始运行听起来很棘手，我不知道如何从Restic本身中准确而干净地完成该操作。 特别是因为您可能同时运行不同的Restic备份，这不应该计算在内。

也许与许多其他Linux启动脚本相似的启动脚本会在启动时获取Restic的PID，然后将其保存到tmp文件中，然后在Restic结束时将其删除。 每次运行脚本时，都会检查文件。 每个唯一的预定备份都需要一个不同的tmp文件。

不幸的是，任何检测正在运行的Restic实例的方法都将在除本地后端之外的所有后端（SFTP，REST，S3 ...）上失败。

@zcalusic我们可以使用存储在锁定文件中的信息来做到这一点： https :

我仍然看不到机器A上的Restic，如何在备份服务器机器B上找到锁，区分a）当前在机器C上运行Restic会话，以及b）在机器C上的Restic崩溃后留下过时的锁？

还是我们在这里开始谈论RPC机制？ 甚至更好的分布式锁管理器？ 😄

@zcalusic我正在谈论＃711：检测何时启动同一台计算机上具有相同目录的第二个备份。 那应该是可能的。

@bwmarrin我不明白您的建议：

如果您知道cron作业每X个小时安排一次备份，则可以将--timeout传递给restic，这样它将在下一个备份开始之前结束。

备份将一直运行到最后，或者被取消/终止。 我认为不可能以某种方式计时备份，该备份最多花费假设的--timeout参数给出的持续时间。 那怎么工作？

您能否描述这种参数的语义？ 谢谢！

@ fd0我是说如果备份没有在--timeout值内完成，它将终止。 我意识到这意味着备份将不完整或未完成。 但是，由于restic的增量设计确实不是什么大问题。 下次调用备份时，它将从上次中断的地方开始。

这意味着如果您计划将cron作业每小时运行一次，并且将--timeout 50m参数传递给restic。 如果耗时超过50分钟，它将中止/终止备份。 在这种情况下，十分钟后，cron作业将再次启动它，并且它将在中断处继续执行。 这将防止同一备份的多个实例同时运行。

感谢您的解释。 我认为这不是一个好主意。 如果备份位置太慢而又没有注意（网络中的某人忘记了一个Bittorrent客户端，这会最大化您的上游带宽），会导致备份无法完成，中止，再次重启，再次中止等等，该怎么办？ 。 这样一来，您永远都不会获得完整的工作备份。

或者考虑一个目录树，要为其不断添加数据。 一次单独的Restic最终将完成（以这种方式设计），但是如果在两次运行之间添加了太多新数据，则重新启动Restic可能永远不会完成。

此外，您可以通过运行timeout 40m restic backup [...]使用标准实用程序timeout （来自coreutils）轻松实现此行为。 因此，我认为在restic中添加此选项不是一个好主意。

我知道我参加聚会迟到了，但是不能有一个锁文件让第二个实例在第一个实例开始之前等待它完成吗？

@ Karl-Gustav，也许您可​​以通过一些脚本来实现。 https://stackoverflow.com/a/1985512/244009

那比我的锁还先进：-)我只用if file {wait 5sec and check again}

我可能对讨论有点晚了，但是我创建了一些系统单元，您可以在这里找到。
这些是我的Restic配置文件，它们可能对某人有用。

嗨，我正在阅读如何使用Restic安排备份。 现在，我的想法是使用anacron安排每周备份2天的Backblaze，例如。 关键是，如果我的备份是使用anacron计划的，例如星期二和星期五的下午12点，而我的笔记本电脑在星期二关闭，并且直到星期五的上午11:59才重新启动，那会发生什么？ AFAIK（如果我没记错的话）anacron应该开始星期二错过的工作； 一分钟后（第一个Restic实例正在运行时），将运行第二个备份，为同一目录生成2个并发备份吗？

还是使用某种/ tmp锁定文件来阻止第二个实例运行？
我应该如何管理它以正确安排备份时间？ 谢谢 ：）

@gerardbosch嗨！ 这个问题更适合该论坛，请下次再考虑:)

一种解决方法是编写一个脚本，为您运行Restic，并在此过程中创建一个运行文件（例如，包含Restic进程的PID的/var/run/restic.pid ），然后可以检查以确定Restic是否已在工作。

如果要运行两个并发备份，它将不会以任何方式harm ，但是，如果它们包含或多或少的相同文件和时间点，则毫无意义。

我不知道anacron是否试图追赶错过的备份运行，应该在其文档中说明。 如果您使用的是macOS，并使用launchd进行调度，则可以选择是否执行此操作，这取决于您。

仅供参考，以便更多人通过Google搜索登陆此处：

这是我使用系统服务和时间而不是cron作业按计划执行备份的方法。 备份失败时还具有电子邮件通知功能。

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

@erikw很棒的时间表脚本，
一些问题：

• 与cron或anacron相比，使用systemd计时器的主要优点是什么？
• Systemd脚本/安装程序可以安装在homedir中而不是/ etc中吗？
• 可以在$ HOME中的某个位置放置anacron选项卡吗？

我打算备份笔记本电脑的homedir，因此，在灾难恢复的情况下，备份相同的调度程序脚本将提供现成的计划备份系统（即在灾难发生后还原整个备份）。新的用户帐户，该帐户已配置为按照以前的时间表进行备份）。

@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中使用它！ 感谢您的这项工作。

restic backup然后是restic forget和restic prune是通常的工作流程，它将对其进行清理。 无论如何，我都会添加另一个问题，因此我们可以跟踪这个想法。

如果我要设置每日排定的任务/计划任务，但又不希望可能会有并行任务，脚本是否仍应执行restic backup -> restic forget -> restic prune ？ 如果一次只执行一个实例，似乎会增加更多的开销

我们可以重新打开它作为文档任务吗？ 我认为我们应该在手册中添加一个“计划”部分，以使该主题更清晰。 我们可以这样说：

调度不在Restic的范围内。 但是，有一些外部工具可用于此目的。

• Backupninja和Restic支持分支
• 使用systemd服务和计时器进行自动Restic备份
• Restic备份配置

有什么想法吗？

另一个建议重新开放。 如果restic不支持备份计划/监视，则文档可以对此进行解释并链接到支持备份/监视的东西，因为这是使用备份工具的主要方式。

@SigmaX如何安排时间完全取决于您可以使用的操作系统和软件。 我认为类似的建议超出了文档的讨论范围，但确实可以在某人的博客甚至论坛的“食谱”部分中提供有用的文章。 它也可以是Restic doc网站https://restic.readthedocs.io/en/latest/080​​_examples.html上“示例”部分的候选内容，但必须以最低要求的方式编写维护方面，因为我们不想维护一组详细的说明以了解如何在几个不同的平台上安排此操作（因为这是一个非常复杂的主题）。 综上所述，如果有人进行搜索，那么网上已经有很多关于此的文章和示例（例如，使用cron和systemd）。 我不完全确定是否需要在docs网站中添加它。

我不完全确定是否需要在docs网站中添加它。

我可以看到这将是一个有见地的问题，尤其是因为Restic是跨平台的。 对我来说，这令人惊讶。 在我看来，拥有一个没有杰出的文档安排时间的备份工具，听起来像是卖没有车轮的汽车。 假设我遗漏了一些东西，我花了相当长的时间搜索文档。 我永远不会手动启动备份，但这就是所有文档所描述的。

至少，一个docs部分可以节省用户时间：表明用户需要搜索其他地方/找到其他工具来设置带有restic的常规备份。

在我看来，拥有一个没有重要文档来安排时间的备份工具，听起来像是卖没有车轮的汽车

并不是的。 我们“卖”给您的是一个程序，您可以告知要备份的内容，并对其进行备份。 您需要多久执行一次操作是一个单独的问题：）但是我离题了。

如果没有在文档中找到某个主题，我希望大多数用户只是简单地使用DDG / Google，然后在一两分钟内找到答案。 但这并不意味着我们不应该在文档中添加某种指针，即使我们没有详细说明如何设置各种调度软件也是如此。

我们“卖”给您的是一个程序，您可以告知要备份的内容，并对其进行备份。 您要多久执行一次操作是一个单独的问题：）

说“这是一个自己动手做的工具包–找到自己的轮子！”是完全合法的。

如果没有在文档中找到某个主题，我希望大多数用户只是简单地使用DDG / Google，然后在一两分钟内找到答案。

实际上，谷歌搜索“固定备份计划”使我来到了第一场比赛：微笑：

2122是相关的，因为它提供了一些示例系统计时器和其他有关调度的讨论。

我认为这里的“最少维护”方法似乎是有道理的……也许包括有关日志记录输出的提示，并防止同时运行多个？

可能包括有关记录输出并防止同时运行多个提示？

我喜欢这个主意。 我将在本周晚些时候草拟一份草案，最有可能在文档的备份部分下放置一个“指针”部分。