よると、この、パスワードを指定するには、環境変数のRESTIC_PASSWORDを使用することができます。

@pvgoranがすでに述べたように、環境変数RESTIC_PASSWORD使用できます。 これは、こちらのマニュアルhttp://restic.readthedocs.io/en/latest/Manual/#initialize-a-repositoryに記載されています。 これをより適切に文書化する方法についてアイデアがある場合は、プルリクエストを作成してください。

ファイルからパスワードを読み取ることに関する問題＃278もあります。

今は何もする必要がないので、この問題を解決します。 同意できない場合は、コメントを残してください。

痛い、そして私はそのセクションを読んだと思った....

たぶん、その段落にそれ自身の見出しまたは小見出しを付けますか？ そのセクションの最初の4つの段落では、リポジトリの初期化に関するすべてをカバーしています。 バックアップの自動化は、実際にはその下には当てはまりません。

ところで、迅速な回答をしてくれた@pvgoranに感謝します。 ：スマイル：

これに関する簡単なフォローアップの質問です。 cronがresticを再度実行するまでにバックアップが完了しない場合、どうなりますか？

この場合、resticは2番目の（並列）バックアップを開始します。これは、最初の（まだ実行中の）バックアップによって既にアップロードされたデータを使用します。 両方のバックアップがほぼ同時に終了すると思います。 いくつかのデータ重複があり、次回pruneコマンドが実行されたときにクリーンアップされます。 ただし、データの破損やデータの損失は発生しません。 リポジトリ形式は、データの並列アップロードを可能にするように設計されています。

これは私がまだ考えていない興味深いケースです。 同じバックアップが同じホストですでに実行されているかどうかを確認し、この場合は終了するコードが必要だと思いますか？

@ fd0おそらく、そうです。 同じバックアップの場合のみ。 または、自動バックアップをスクリプト化するクリーンな方法：たとえば、「レスティックバックアップ」、「レスティックロック解除」、「レスティックプルーン」など、いくつかの手順で実行できます。 しかし、これらの余分なコマンドについて心配する必要がないのは素晴らしいことです。

restic backup後にrestic forgetとrestic pruneが続くのが通常のワークフローであり、これでクリーンアップされます。 とにかく別の問題を追加して、このアイデアを追跡できるようにします。

かっこいい、ありがとう！ 今のところ、そのフローを使用します。

ここで役立つ可能性のある別のオプションは、タイムアウトパラメータです。 cronジョブがX時間ごとにバックアップをスケジュールしていることがわかっている場合は、-timeoutをresticに渡して、次のバックアップが開始する前に終了するようにすることができます。 他のことにも重宝します。 （これはすでに存在している可能性があります、私はresticに不慣れです）

Resticがすでに実行されていることを検出するのは難しいように思えますが、Restic自体の内部から正確かつクリーンに実行する方法はわかりません。 特に、異なるレスティックバックアップを同時に実行する可能性があるため、カウントされるべきではありません。

おそらく、他の多くのLinux起動スクリプトと同様の起動スクリプトで、起動時にresticのPIDを取得し、それをtmpファイルに保存し、resticが終了すると削除します。 スクリプトが実行されるたびに、ファイルがチェックされます。 スケジュールされた一意のバックアップごとに異なるtmpファイルが必要になります。

残念ながら、実行中のresticインスタンスを検出する手段は、ローカルのものを除くすべてのバックエンド（SFTP、REST、S3 ...）で失敗します。

@zcalusicロックファイルに保存されている情報を使用してhttps ：

マシンAでresticを実行し、バックアップサーバーmachine Bでロックを見つけて、a）マシンCで現在実行中のresticセッションとb）マシンCのresticがクラッシュした後に残った古いロックを区別する方法がまだわかりません。

それとも、ここでRPCメカニズムについて話し始めていますか？ またはさらに良い、分散ロックマネージャー？ 😄

@zcalusic私が話しているのは＃711：同じマシン上の同じディレクトリで2番目のバックアップが開始されたことを検出することです。 それは可能であるはずです。

@bwmarrinあなたが何を提案しているのかわかりません：

cronジョブがX時間ごとにバックアップをスケジュールしていることがわかっている場合は、-timeoutをresticに渡して、次のバックアップが開始する前に終了するようにすることができます。

バックアップが最後まで実行されるか、キャンセル/終了されます。 架空の--timeoutパラメータで指定された期間に関係なく、バックアップの時間をどうにかして取得することは不可能だと思います。 それはどのように機能しますか？

そのようなパラメータのセマンティクスについて説明していただけますか？ ありがとう！

@ fd0バックアップが--timeout値内で終了しない場合、バックアップは終了します。 これは、バックアップが不完全または未完成であることを意味します。 ただし、resticのインクリメンタル設計なので、それほど大きな問題ではありません。 次回バックアップが呼び出されると、中断したところから開始されます。

これは、1時間ごとに実行するようにスケジュールされたcronジョブがあり、-timeout50mパラメーターをresticに渡す場合を意味します。 50分以上かかる場合は、バックアップを中止/終了します。 その場合、10分後にcronジョブが再開し、中断したところから再開します。 これにより、同じバックアップの複数のインスタンスが同時に実行されるのを防ぐことができます。

説明ありがとう。 これは良い考えではないと思います。 バックアップの場所が気付かないうちに遅い場合（ネットワーク内の誰かがビットトレントクライアントを忘れてアップストリーム帯域幅を最大化する）、バックアップが終了せず、中止され、再起動され、再度中止されるなどの場合はどうなりますか？ 。 そうすれば、完全に機能するバックアップになってしまうことはありません。

または、データが絶えず追加されるディレクトリツリーを検討してください。 Resticの1回の実行は最終的に終了しますが（そのように設計されています）、実行間に追加された新しいデータが多すぎると、resticの再起動が終了しない場合があります。

さらに、 timeout 40m restic backup [...]実行することにより、（coreutilsからの）標準ユーティリティtimeoutを使用して、この動作を簡単に実装できます。 したがって、このオプションをresticに追加することは良い考えではないと思います。

パーティーに遅れていることに気づきましたが、2番目のインスタンスが最初のインスタンスが終了するのを待ってから開始するロックファイルがありませんでしたか？

@ Karl-Gustav、少しのスクリプトでそれを達成できるかもしれません。 https://stackoverflow.com/a/1985512/244009

それは私のロックよりも少し進んでいました:-)私はif file {wait 5sec and check again}使うだけです

議論に少し遅れるかもしれませんが、ここで見つけることができるいくつかのsystemdユニットを作成しまし
これらは私のrestic設定ファイルです、それらは誰かのために役立つかもしれません。

こんにちは。resticを使用してバックアップをスケジュールする方法について読んでいます。 今のところ私の考えは、anacronを使用して、たとえば、Backblazeへの週2日のバックアップをスケジュールすることです。 重要なのは、バックアップがanacronでスケジュールされている場合（火曜日と金曜日の午後12時など）、ラップトップの電源が火曜日にオフになっていて、金曜日の午前11時59分までバックアップを再開しない場合はどうなるでしょうか。 AFAIK（そして私が間違っていなければ）anacronは火曜日の逃した仕事を始めるはずです。 そして1分後（最初のresticインスタンスの実行中）、2番目のバックアップを実行し、同じディレクトリに対して2つの同時バックアップを生成しますか？

または、2番目のインスタンスの実行を防ぐための/ tmpロックファイルの種類ですか？
バックアップを正しくスケジュールするには、どのように管理すればよいですか？ THX ：）

@gerardboschこんにちは！ この質問はフォーラムにより適しています。次回はそれを考慮してください:)

これを処理する1つの方法は、resticの実行を実行するスクリプトを作成し、その一部としてrunfile（たとえば、resticプロセスのPIDを含む/var/run/restic.pid ）を作成することです。 resticがすでに機能しているかどうかを確認してください。

2つの同時バックアップを実行する場合は、決してharmはなりませんが、それらが多かれ少なかれ同じファイルと特定の時点をカバーしている場合は、もちろん無意味です。

anacronがバックアップの実行の失敗に追いつくかどうかはわかりませんが、ドキュメントに記載されているはずです。 macOSを使用していて、スケジュールにlaunchdを使用している場合は、そうするかどうかを選択できます。それはあなた次第です。

Google検索からここに上陸するより多くの人々のための参考までに：

cronジョブの代わりに、systemdのサービスと時刻を使用してスケジュールに従ってバックアップを行う方法は次のとおりです。 バックアップが失敗したときの電子メール通知も備えています。

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

@erikw素晴らしいスケジュールスクリプト、おめでとうございます！
いくつかの質問：

• cronやanacronよりもsystemdタイマーを使用する主な利点は何ですか？
• systemdスクリプト/セットアップを/ etcではなくhomedirにインストールできますか？
• anacronタブは$ HOMEのどこかにありますか？

ラップトップのホームディレクトリをバックアップすることを計画しているので、災害復旧の場合に同じスケジューラスクリプトをバックアップすると、すぐに使用できるスケジュールバックアップシステムが提供されます（つまり、災害後にバックアップ全体を復元すると、同じ以前のスケジュールでバックアップを実行するようにすでに構成されている新しいユーザーアカウント）。

@gerardbosch

• systemdシステムを使用している場合は、デフォルトのツールを使用できるのは非常に便利です。cronデーモンをインストールする必要はありません。 失敗したジョブのステータスを細かく制御でき、たとえば、次回ジョブがいつ実行されるかを確認できます。 短いイントロについては、 archwikiを参照してください。 自分で遊んでみるのが、私が言う最も楽しい学習方法です。

• はい、ローカルユーザー用にいくつかの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が続くのが通常のワークフローであり、これでクリーンアップされます。 とにかく別の問題を追加して、このアイデアを追跡できるようにします。

可能な並列ジョブを予期せずに毎日スケジュールされたタスク/ cronジョブを設定している場合でも、スクリプトはrestic backup -> restic forget -> restic pruneますか？ 一度に1つのインスタンスのみを実行している場合は、オーバーヘッドが増えるようです。

これをドキュメントタスクとして再開できますか？ このトピックを明確にするために、マニュアルに「スケジュール」セクションを追加する必要があると思います。 私たちは次のように言うことができます：

スケジューリングはResticの範囲外です。 ただし、この目的で使用できる外部ツールがあります。

• BackupninjaとResticサポートブランチ
• systemdサービスとタイマーを使用した自動resticバックアップ
• Resticバックアップ構成

考え？

再開するための別の提案。 Resticがバックアップのスケジューリング/監視をサポートしていない場合、バックアップツールが使用される主な方法であるため、ドキュメントはこれを説明し、サポートしているものにリンクすることができます。

@SigmaXのスケジュール方法は、自由に使用できるOSとソフトウェアによって異なります。 そのような提案は、問題を解決するためのドキュメントの範囲外だと思いますが、実際には、誰かのブログやフォーラムのレシピセクションで役立つ記事になる可能性があります。 また、 https： //restic.readthedocs.io/en/latest/080​​_examples.htmlのrestic doc Webサイトの例セクションの候補になる可能性もありますが、最低限必要な方法で作成する必要があります。いくつかの異なるプラットフォームでこれをスケジュールする方法についての一連の詳細な手順を維持したくないので（これはかなり複雑なトピックであるため）。 とは言うものの、ネット上には、これに関する記事や例がすでにいくつかあります（たとえば、cronやsystemdを使用）。 ドキュメントのウェブサイトにそれが必要かどうかは完全にはわかりません。

ドキュメントのウェブサイトにそれが必要かどうかは完全にはわかりません。

特にresticはクロスプラットフォームであるため、それがどのように意見の問題になるかがわかります。 私にとって、それは驚きでした。 スケジュール方法に関する著名なドキュメントのないバックアップツールがあると、車輪のない車を売るようなものに思えます。 何かが足りないと思って、ドキュメントの検索にかなりの時間を費やしました。 手動でバックアップを起動することは決してありませんが、ドキュメントで説明されているのはそれだけです。

少なくとも、ドキュメントセクションでは、ユーザーの時間を節約できます。つまり、他の場所を検索したり、resticを使用して定期的なバックアップを設定するための別のツールを見つけたりする必要があることを示します。

スケジュール方法に関する著名なドキュメントのないバックアップツールがあると、車輪のない車を販売するように思えます

あんまり。 私たちがあなたに「売る」のは、あなたが何をバックアップするかを指示するプログラムであり、それはそれをバックアップします。 どのくらいの頻度でそれをやりたいかは別の懸念です:)しかし私は余談です。

ドキュメントで特定のトピックが見つからない場合は、ほとんどのユーザーが単にDDG / Googleで検索し、1〜2分以内に回答を見つけることを期待しています。 しかし、それは、さまざまなスケジューリングソフトウェアの設定方法の詳細がなくても、ドキュメントに何らかのポインタを追加するべきではないという意味ではありません。

私たちがあなたに「売る」のは、あなたが何をバックアップするかを指示するプログラムであり、それはそれをバックアップします。 それをどのくらいの頻度でやりたいかは別の懸念事項です:)

そして、「これはDIYキットです---自分のホイールを見つけに行きましょう！」と言うのは完全に正当です。

ドキュメントで特定のトピックが見つからない場合は、ほとんどのユーザーが単にDDG / Googleで検索し、1〜2分以内に回答を見つけることを期待しています。

実際、「残りのバックアップスケジュール」を探し回ると、最初の試合がここにありました：smile：

2122は、いくつかのサンプルsystemdタイマーと、スケジューリングに関するその他の説明を提供するため、関連しています。

ここでの「最小限のメンテナンス」アプローチは理にかなっているように思われます...出力のログ記録と複数の実行の同時防止に関するヒントが含まれているのではないでしょうか。

出力をログに記録し、同時に複数の実行を防ぐためのヒントを含めることができますか？

私はその考えが好きです。 今週後半にドラフトを作成します。おそらく、ドキュメントのバックアップセクションの下に小さな「ポインタ」セクションを配置します。