Nach dieser können Sie die Umgebungsvariable RESTIC_PASSWORD verwenden Sie das Kennwort angeben.

Wie @pvgoran bereits sagte, können Sie die Umgebungsvariable RESTIC_PASSWORD . Dies ist im Handbuch hier http://restic.readthedocs.io/en/latest/Manual/#initialize -a-repository dokumentiert. Wenn Sie eine Idee haben, wie Sie dies besser dokumentieren können, erstellen Sie bitte eine Pull-Anfrage.

Es gibt auch das Problem Nr. 278, bei dem es darum geht, das Kennwort aus einer Datei zu lesen.

Ich werde dieses Problem schließen, da wir im Moment nichts tun müssen. Wenn Sie nicht einverstanden sind, hinterlassen Sie bitte einen Kommentar.

Autsch, und ich dachte, ich hätte diesen Abschnitt durchgelesen ...

Vielleicht geben Sie diesem Absatz eine eigene Überschrift oder Unterüberschrift? Die ersten vier Absätze in diesem Abschnitt behandeln alles über die Initialisierung eines Repositorys. Die Automatisierung von Backups passt nicht wirklich darunter.

Danke @pvgoran für die schnelle Antwort, übrigens. :Lächeln:

Nur eine kurze Folgefrage dazu. Was passiert, wenn ein Backup nicht abgeschlossen ist, wenn cron restic erneut ausführt?

In diesem Fall startet restic eine zweite (parallele) Sicherung, bei der Daten verwendet werden, die bereits von der ersten (noch laufenden) Sicherung hochgeladen wurden. Ich denke, dass beide Backups fast gleichzeitig beendet werden. Es wird einige Daten duplizieren, die bereinigt werden, wenn der Befehl prune das nächste Mal ausgeführt wird. Es wird jedoch keine Datenbeschädigung oder Datenverlust verursachen. Das Repository-Format ist so konzipiert, dass Daten parallel hochgeladen werden können.

Dies ist ein interessanter Fall, über den ich noch nicht nachgedacht habe. Denken Sie, wir benötigen Code, um zu überprüfen, ob dieselbe Sicherung bereits auf demselben Host ausgeführt wird, und um in diesem Fall zu beenden?

@ fd0 Möglicherweise ja. Nur für das gleiche Backup. Oder eine saubere Methode zum Skripten automatisierter Sicherungen: Einige Anweisungen reichen aus, z. B. "Restic Backup", dann "Restic Unlock", dann "Restic Prune". Aber sich nicht um diese zusätzlichen Befehle kümmern zu müssen, wäre schön.

restic backup gefolgt von restic forget und restic prune ist der übliche Workflow, und das bereinigt ihn. Ich werde trotzdem ein weiteres Problem hinzufügen, damit wir diese Idee verfolgen können.

Cool Danke! Im Moment werde ich diesen Fluss verwenden.

Eine weitere Option, die hier helfen könnte, ist ein Timeout-Parameter. Wenn Sie wissen, dass Ihr Cron-Job alle X Stunden ein Backup plant, können Sie ein --timeout an restic übergeben, damit es vor dem nächsten Start endet. Es wäre auch für andere Dinge nützlich. (Dies kann bereits existieren, ich bin neu in Restic)

Zu erkennen, dass Restic bereits ausgeführt wird, klingt schwierig und ich bin nicht der Meinung, wie dies innerhalb von Restic selbst genau und sauber gemacht werden würde. Zumal möglicherweise verschiedene Restic-Backups gleichzeitig ausgeführt werden, was nicht zählen sollte.

Möglicherweise ein Startskript, das vielen anderen Linux-Startskripten ähnelt, das die PID von restic beim Start verwendet und in einer tmp-Datei speichert und sie dann löscht, wenn restic endet. Jedes Mal, wenn das Skript ausgeführt wird, wird nach der Datei gesucht. Sie benötigen für jede einzelne geplante Sicherung eine andere tmp-Datei.

Leider würde jedes Mittel zum Erkennen einer laufenden Restic-Instanz auf ALLEN Backends (SFTP, REST, S3 ...) außer dem lokalen fehlschlagen.

@zcalusic Wir könnten die in den Sperrdateien gespeicherten Informationen verwenden, um dies zu tun: https://github.com/restic/restic/blob/master/src/restic/lock.go#L27 -L33, vielleicht die Liste der Dateien hinzufügen zu sichern oder die genauen Befehlszeilenargumente oder ähnliches.

Ich sehe immer noch nicht, wie Restic auf Maschine A, wenn eine Sperre auf Backup Server Server B gefunden wird, zwischen a) einer derzeit laufenden Restic-Sitzung auf Maschine C und b) einer veralteten Sperre unterscheiden würde, die nach dem Absturz des Restic auf Maschine C verbleibt.

Oder sprechen wir hier über RPC-Mechanismen? Oder noch besser, verteilte Schlossmanager? 😄

@zcalusic Ich spreche von # 711: Erkennen, wann eine zweite Sicherung mit denselben Verzeichnissen auf demselben Computer gestartet wird. Das sollte möglich sein.

@bwmarrin Ich verstehe nicht, was Sie vorschlagen:

Wenn Sie wissen, dass Ihr Cron-Job alle X Stunden ein Backup plant, können Sie ein --timeout an restic übergeben, damit es vor dem nächsten Start endet.

Entweder wird eine Sicherung bis zum Ende ausgeführt oder sie wird abgebrochen / beendet. Ich glaube nicht, dass es möglich ist, ein Backup so zu planen, dass es höchstens die Dauer eines hypothetischen --timeout -Parameters benötigt. Wie könnte das funktionieren?

Könnten Sie bitte die Semantik eines solchen Parameters beschreiben? Vielen Dank!

@ fd0 Ich sage, wenn die Sicherung nicht innerhalb des Wertes --timeout abgeschlossen wird, wird sie beendet. Mir ist klar, dass dies bedeutet, dass es sich um eine unvollständige oder unvollendete Sicherung handelt. Da das inkrementelle Design von restic jedoch keine große Sache ist. Wenn das Backup das nächste Mal aufgerufen wird, beginnt es dort, wo es aufgehört hat.

Dies bedeutet, wenn Sie einen Cron-Job haben, der stündlich ausgeführt werden soll, und einen Parameter --timeout 50m an restic übergeben. Die Sicherung wird abgebrochen / beendet, wenn sie länger als 50 Minuten dauert. In diesem Fall startet der Cron-Job 10 Minuten später erneut und wird dort fortgesetzt, wo er aufgehört hat. Dies würde verhindern, dass mehrere Instanzen derselben Sicherung gleichzeitig ausgeführt werden.

Danke für die Erklärung. Ich denke, dass dies keine gute Idee ist. Was passiert, wenn der Sicherungsspeicherort langsam ist, ohne dass Sie es bemerken (jemand in Ihrem Netzwerk hat einen Bittorrent-Client vergessen, der Ihre Upstream-Bandbreite maximiert), sodass die Sicherung nicht abgeschlossen wird, abgebrochen wird, erneut gestartet wird, erneut abgebrochen wird und so weiter . Dann erhalten Sie nie ein voll funktionsfähiges Backup.

Oder betrachten Sie einen Verzeichnisbaum, für den ständig Daten hinzugefügt werden. Ein einzelner Restic-Lauf wird irgendwann beendet (es ist so konzipiert), aber ein Neustart von Restic wird möglicherweise nie beendet, wenn zwischen den Läufen zu viele neue Daten hinzugefügt werden.

Außerdem können Sie dieses Verhalten einfach implementieren, indem Sie das Standarddienstprogramm timeout (von coreutils) verwenden und timeout 40m restic backup [...] . Daher halte ich es nicht für eine gute Idee, diese Option zu Restic hinzuzufügen.

Mir ist klar, dass ich zu spät zur Party komme, aber könnte es keine Sperrdatei geben, die die zweite Instanz warten lässt, bis die erste beendet ist, bevor sie startet?

@ Karl-Gustav, vielleicht kannst du das mit ein bisschen Scripting erreichen. https://stackoverflow.com/a/1985512/244009

Das war etwas fortgeschrittener als meine Schlösser :-) Ich benutze nur if file {wait 5sec and check again}

Ich bin vielleicht etwas spät dran, aber ich habe einige systemd-Einheiten erstellt, die Sie hier finden.
Dies sind meine restischen Konfigurationsdateien, sie können für jemanden nützlich sein.

Hallo, ich lese gerade, wie ich mit restic meine Backups planen kann. Im Moment ist meine Idee, mit anacron beispielsweise ein Backup von 2 Tagen pro Woche für Backblaze zu planen. Der Punkt ist, was passiert, wenn mein Backup mit anacron geplant ist, z. B. Dienstag und Freitag um 12 Uhr, und mein Laptop am Dienstag ausgeschaltet ist und erst am Freitag um 11:59 Uhr erneut gestartet wird. AFAIK (und wenn ich mich nicht irre) anacron sollte den verpassten Job am Dienstag beginnen; und eine Minute später (während die erste restische Instanz ausgeführt wird) wird die zweite Sicherung ausgeführt, wobei zwei gleichzeitige Sicherungen für dasselbe Verzeichnis erstellt werden?

Oder ist es irgendeine Art von / tmp-Sperrdatei, um zu verhindern, dass die zweite Instanz ausgeführt wird?
Wie soll ich es verwalten, um mein Backup richtig zu planen? Danke :)

@gerardbosch Hallo! Diese Frage passt besser zum Forum , bitte bedenken Sie dies beim nächsten Mal :)

Eine Möglichkeit, damit umzugehen, besteht darin, ein Skript zu schreiben, das das Ausführen von Restic für Sie ausführt, und als Teil davon eine Run-Datei zu erstellen (z. B. /var/run/restic.pid die die PID des Restic-Prozesses enthält`), die es dann ausführen kann Überprüfen Sie, ob Restic bereits funktioniert.

Es wird in keiner Weise harm sein, wenn Sie zwei gleichzeitige Sicherungen ausführen, aber es ist natürlich ziemlich sinnlos, wenn sie mehr oder weniger dieselben Dateien und denselben Zeitpunkt abdecken.

Ob anacron versucht, verpasste Sicherungsläufe nachzuholen, weiß ich nicht, sollte es wohl in seiner Dokumentation stehen. Wenn Sie unter macOS arbeiten und launchd für die Planung verwenden, haben Sie die Möglichkeit, dies zu tun oder nicht, es liegt an Ihnen.

Zu Ihrer Information für mehr Leute, die hier über Google-Suchanfragen landen:

Hier erfahren Sie, wie ich nach einem Zeitplan Sicherungen mit systemd-Diensten und -Zeiten anstelle von Cron-Jobs durchführe. Auch mit E-Mail-Benachrichtigungen, wenn die Sicherung fehlschlägt.

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

@erikw Fantastisches Zeitplanskript, Glückwunsch!
Einige Fragen:

• Was ist der Hauptvorteil der Verwendung von Systemd-Timern gegenüber Cron oder Anacron?
• Können systemd scripts / setup in homedir anstelle von / etc installiert werden?
• Kann sich ein Anacron-Tab irgendwo in $ HOME befinden?

Ich plane, das Homedir meines Laptops zu sichern. Wenn Sie also dieselben Scheduler-Skripte sichern, erhalten Sie im Falle einer Notfallwiederherstellung ein sofort einsatzbereites geplantes Sicherungssystem (dh das Wiederherstellen der gesamten Sicherung nach der Katastrophe) neues Benutzerkonto, das bereits für die Sicherung nach demselben vorherigen Zeitplan konfiguriert ist).

@gerardbosch

• Wenn Sie ein systemd-System haben, ist es sehr schön, die Standardtools verwenden zu können, ohne einen Cron-Daemon installieren zu müssen. Sie haben eine gute Kontrolle über den Status fehlgeschlagener Jobs und können beispielsweise sehen, wann ein Job das nächste Mal ausgeführt wird. Im Arch-Wiki finden Sie eine kurze Einführung. Einfach selbst damit herumzuspielen ist der lustigste Weg zu lernen, würde ich allerdings sagen.

• Ja, ich führe mehrere System-Timer für meinen lokalen Benutzer aus. Überprüfen Sie meine Punktedateien auf die Timer und die entsprechenden Dienste, die ich derzeit verwende. Der Schlüssel besteht darin, --user zu verwenden, um die Timer des Benutzers anstelle der System-Timer zu steuern:

$ systemctl --user list-timers

• Es scheint, als wären sie normalerweise in /var/spool . Ob das auf ~/ verschoben werden kann, weiß ich nicht. https://askubuntu.com/questions/216692/where-is-the-user-crontab-stored

Da es hier noch nicht erwähnt wurde, ist Backupninja eine großartige Möglichkeit, die Planung zu verwalten. Restic Support wird in einer Zusammenführungsanforderung hinzugefügt. es wurde einfach noch nicht begangen. Alle grundlegenden Funktionen sollten jedoch vorhanden sein.

@colans Backupninja ist fantastisch, kann es kaum erwarten, es mit Restic verwenden zu können! Vielen Dank für diese Arbeit.

restic backup gefolgt von restic forget und restic prune ist der übliche Workflow, und das bereinigt ihn. Ich werde trotzdem ein weiteres Problem hinzufügen, damit wir diese Idee verfolgen können.

Wenn ich einen täglich geplanten Task- / Cron-Job ohne die Erwartung möglicher paralleler Jobs einrichte, sollte das Skript dann immer noch restic backup -> restic forget -> restic prune ausführen? Es scheint, als würde dies den Overhead erhöhen, wenn jeweils nur eine Instanz ausgeführt wird

Können wir dies als Dokumentationsaufgabe wieder öffnen? Ich denke, wir sollten dem Handbuch einen Abschnitt "Zeitplanung" hinzufügen, um die Klarheit in Bezug auf dieses Thema zu erhöhen. Wir können so etwas sagen wie:

Die Planung liegt außerhalb des Bereichs von Restic. Es gibt jedoch externe Tools, die für diesen Zweck verwendet werden können.

• Backupninja zusammen mit dem Restic Support-Zweig
• Automatische Restic Backups mit systemd Diensten und Timern
• Restic Backup-Konfigurationen

Gedanken?

Ein weiterer Vorschlag zur Wiedereröffnung. Wenn restic die Planung / Überwachung von Sicherungen nicht unterstützt, können die Dokumente dies erklären und auf etwas verweisen, das dies tut, da dies die primäre Art ist, wie Sicherungstools verwendet werden.

Die Zeitplanung von Dokumentation , aber es könnte tatsächlich ein hilfreicher Artikel in einem Blog oder sogar im Abschnitt "Rezepte" des Forums sein. Es könnte auch ein Kandidat für den Abschnitt "Beispiele" auf der Website "Restic Doc" unter https://restic.readthedocs.io/en/latest/080_examples.html sein , aber es müsste so geschrieben sein, dass ein Minimum erforderlich ist der Wartung, da wir keine detaillierten Anweisungen zum Planen auf mehreren verschiedenen Plattformen verwalten möchten (da dies ein ziemlich komplexes Thema ist). Trotzdem gibt es bereits einige Artikel und Beispiele dazu (z. B. mit cron und systemd) im Internet, wenn man danach sucht. Ich bin mir nicht ganz sicher, ob dies auf der Docs-Website erforderlich ist.

Ich bin mir nicht ganz sicher, ob dies auf der Docs-Website erforderlich ist.

Ich kann sehen, wie es eine Ansichtssache wäre, zumal Restic plattformübergreifend ist. Für mich war es überraschend. Ein Backup-Tool ohne prominente Dokumente zur Planung zu haben, scheint mir, als würde ich ein Auto ohne Räder verkaufen. Ich habe eine ganze Weile in den Dokumenten gesucht, vorausgesetzt, mir fehlt etwas. Ich würde niemals ein Backup manuell starten, aber das ist alles, was in den Dokumenten beschrieben wird.

Zumindest könnte ein Dokumentabschnitt Benutzern Zeit sparen: indem angegeben wird, dass sie an einem anderen Ort suchen / ein anderes Tool finden müssen, um Routine-Backups mit Restic einzurichten.

Ein Backup-Tool ohne prominente Dokumente zur Planung zu haben, scheint mir, als würde ich ein Auto ohne Räder verkaufen

Nicht wirklich. Was wir Ihnen "verkaufen", ist ein Programm, das Sie angeben, was gesichert werden soll, und das es sichert. Wie oft du das machen willst, ist ein separates Anliegen :) Aber ich schweife ab.

Ich würde erwarten, dass die meisten Benutzer, wenn sie ein bestimmtes Thema in den Dokumenten nicht finden, einfach DDG / Google dafür verwenden und dann die Antworten innerhalb von ein oder zwei Minuten finden. Dies bedeutet jedoch nicht, dass wir der Dokumentation keinen Zeiger hinzufügen sollten, auch wenn wir keine genauen Angaben zum Einrichten verschiedener Planungssoftware machen.

Was wir Ihnen "verkaufen", ist ein Programm, das Sie angeben, was gesichert werden soll, und das es sichert. Wie oft du das machen willst, ist ein separates Anliegen :)

Und es ist absolut legitim zu sagen: "Dies ist ein DIY-Kit - finden Sie Ihre eigenen Räder!"

Ich würde erwarten, dass die meisten Benutzer, wenn sie ein bestimmtes Thema in den Dokumenten nicht finden, einfach DDG / Google dafür verwenden und dann die Antworten innerhalb von ein oder zwei Minuten finden.

Eigentlich hat mich das Googeln nach "Restic Backup Schedule" hierher gebracht: Lächeln:

2122 ist verwandt, da es einige Beispiel-System-Timer und andere Diskussionen bezüglich der Zeitplanung enthält.

Ich denke, der Ansatz "geringste Wartung" scheint hier sinnvoll zu sein ... vielleicht Hinweise zur Protokollierung der Ausgabe und zur Verhinderung mehrerer Läufe gleichzeitig?

Vielleicht Hinweise zum Protokollieren der Ausgabe und zum Verhindern mehrerer Läufe gleichzeitig enthalten?

Ich mag diese Idee. Ich werde später in dieser Woche einen Entwurf erstellen, wahrscheinlich für einen kleinen "Zeiger" -Abschnitt, der unter dem Sicherungsabschnitt in der Dokumentation platziert wird.