Verwenden Sie den Nur-Anhängen-Modus, wenn ein Backup-Client weniger vertrauenswürdig ist als das Repository und ein separater vertrauenswürdiger Wartungszugang vorhanden ist. Andernfalls ist der normale Zugriff einfacher und transparenter.
Bei einem Heimserver, der Backups auf einen anderen Rechner überträgt, lautet die eigentliche Frage nicht, ob Nur-Anhängen sicherer klingt. Entscheidend ist, ob ein kompromittierter Client daran gehindert werden muss, ältere Repository-Daten zurückzufordern, wer die Aufbewahrungswartung durchführen darf und wie die Wiederherstellung funktioniert, wenn Archive verborgen oder zur Löschung markiert sind. Beginnen Sie mit den Zugangsdaten und der Zuständigkeit für die Wartung und testen Sie anschließend sowohl Backup- als auch Wiederherstellungsverhalten, bevor Sie das Repository dauerhaft auf einen der beiden Modi festlegen.
Legen Sie fest, welcher Rechner und welche Zugangsdaten nicht vertrauenswürdig sind
Listen Sie die Quellrechner, den Repository-Host, SSH-Schlüssel, Dienstkonten und Administratoridentitäten auf. Kennzeichnen Sie, welche Identität normale Backups durchführt, welche die Aufbewahrungswartung übernimmt und welche sich am Repository-Host anmelden kann. Nur-Anhängen hilft ausschließlich dann, wenn der weniger vertrauenswürdige Client tatsächlich an der Repository-Grenze eingeschränkt wird.
Ein entfernter Backup-Server im Nur-Anhängen-Modus ist am sichersten, wenn der Clientschlüssel auf einen eingeschränkten Borg-Befehl festgelegt ist und weder eine allgemeine Shell noch Zugangsdaten für Wartungsaufgaben erhalten kann.
Wenn derselbe Client den Administratorschlüssel speichert, die Komprimierung plant und die Repository-Konfiguration bearbeiten kann, ist die behauptete Grenze größtenteils nur organisatorischer Natur. Wenn der Repository-Host selbst kompromittiert werden könnte, ist der Nur-Anhängen-Modus auf diesem Host keine unabhängige Kopie. Wählen Sie den Modus erst, nachdem die Bedrohungsanalyse gezeigt hat, wer von wem getrennt ist.
Überprüfen Sie, was der Nur-Anhängen-Modus in Ihrem Borg-Ablauf verändert
Erstellen Sie ein kleines, entbehrliches Repository und führen Sie genau die Befehle aus, die Ihre Automatisierung verwenden wird. Fügen Sie zwei Archive hinzu, listen Sie sie auf, wenden Sie den geplanten Aufbewahrungsbefehl an, versuchen Sie mit der Clientidentität eine Komprimierung und wechseln Sie anschließend zur vertrauenswürdigen Wartungsidentität. Dokumentieren Sie, welche Daten weiterhin wiederherstellbar sind und welche Vorgänge lediglich in der aktuellen Ansicht des Clients widergespiegelt werden.
In einem Repository im Nur-Anhängen-Modus werden Archive nach einer Löschung oder dem Auslösen eines Prune-Vorgangs möglicherweise nicht mehr für den Client angezeigt, obwohl der Speicher erst freigegeben wird, wenn die vertrauenswürdige Wartung dies zulässt. Dieser Unterschied muss vor einem Vorfall verstanden sein.
Der Test ist nur dann erfolgreich, wenn der eingeschränkte Client Backups erstellen, den dauerhaften Entzug geschützter Historie jedoch nicht durchführen kann und der vertrauenswürdige Administrator den Transaktionsstatus prüfen sowie das benötigte Archiv wiederherstellen kann. Wenn der Betreiber nicht erklären kann, wie ein verborgenes Archiv wiederhergestellt wird, ist der Nur-Anhängen-Modus unabhängig vom erfolgreichen Erstellen von Backups noch nicht produktionsreif.
Wählen Sie den Modus passend zur Zuständigkeit für die Wartung
Wählen Sie den Nur-Anhängen-Modus, wenn entfernte oder exponierte Clients Backups übertragen müssen, eine separate geschützte Identität die Wartung durchführen kann, der Speicher die Verzögerung bis zur Komprimierung verkraftet und die Wiederherstellung geübt wurde. Halten Sie diese Wartungszugangsdaten von den normalen Backup-Clients fern und verwenden Sie sie ausschließlich über einen gehärteten Administrationszugang.
Wählen Sie den normalen Zugriff, wenn Repository und Client derselben vertrauenswürdigen Administrationsgrenze angehören, die routinemäßige Aufbewahrung und Speicherfreigabe direkt erfolgen müssen und die betriebliche Einfachheit wichtiger ist als die Einschränkung eines kompromittierten Clientschlüssels. Eine Warnung zur automatischen Komprimierung im Nur-Anhängen-Modus ist wichtig: Ein automatisierter vertrauenswürdiger Komprimierungsprozess kann eine von einem kompromittierten Client ausgelöste destruktive Aktion abschließen, wenn er ohne Prüfung ausgeführt wird.
Verwenden Sie separate Repositorys, wenn eine Clientgruppe vertrauenswürdig und eine andere exponiert ist oder wenn ihre Wartungspläne miteinander kollidieren. Schwächen Sie nicht aus Gründen der Deduplizierung alle Clients auf das unsicherste gemeinsame Modell ab. Die richtige Wahl hängt von den Umständen ab: Der Nur-Anhängen-Modus schützt eine bestimmte Grenze zwischen Zugangsdaten, während der normale Zugriff die Wartung direkt hält.
Validieren Sie Backup, Wiederherstellung und Wartung als einen gemeinsamen Ablauf
Führen Sie den vollständigen Betriebsablauf durch, bevor Sie sich auf das Repository verlassen. Erstellen Sie vom Client aus zwei Backups, wenden Sie die vorgesehene Aufbewahrungsrichtlinie an, prüfen Sie den resultierenden Status mit der vertrauenswürdigen Identität, stellen Sie ein Beispielverzeichnis an einem separaten Ort wieder her und führen Sie den geplanten Wartungsschritt aus. Messen Sie den Speicherverbrauch davor und danach, damit verzögerte Freigaben sichtbar werden.
Der Zugriffsmodus des Repositorys macht Prüfungen von Identität und Einhängepfad nicht überflüssig. Wenn Borg ein verschobenes Repository nicht finden kann, halten Sie diese Diagnose des Repository-Pfads getrennt vom Verhalten des Nur-Anhängen-Modus.
Der Modus ist erfolgreich validiert, wenn geplante Backups funktionieren, ein früheres Archiv wiederhergestellt werden kann, die Wartungsidentität den Speicher gezielt prüfen und freigeben kann und dieselben Ergebnisse nach einem Neustart des Clients bestehen bleiben. Kehren Sie zum Test-Repository zurück, wenn die Sichtbarkeit von Archiven unklar ist, der Speicher ohne ein sicheres Wartungsfenster wächst oder die Administratorzugangsdaten nicht wirklich getrennt sind.
Support & Tipps
Mehr zum Lesen

So planen Sie Restic-Aufgaben für Backup, Forget und Prune ohne Sperrkonflikte
Ein vollständiger Restic-Zeitplan für mehrere Hosts, der häufige Backups, eine gezielte Aufbewahrung, physisches Pruning, Prüfungen, Wiederholungsversuche und die Validierung von Wiederherstellungen voneinander trennt.

So verhindern Sie, dass Restic-Prune-Aufträge geplante Backups blockieren
Ein Präventionsplan für gemeinsam genutzte Restic-Repositories, der Sicherungsfenster von Prune trennt und Sperren, Wiederholungsversuche sowie Warnmeldungen beibehält.

So entfernst du eine veraltete Restic-Sperre, ohne eine aktive Sicherung zu unterbrechen
Ein möglichst wenig invasiver Restic-Entsperr-Workflow, der aktive Backups schützt, nur veraltete Zustände entfernt und die Wiederherstellung im Rahmen des normalen Zeitplans bestätigt.

