Warm-Standby Disaster Recovery über mehrere Clouds mit RcloneView (S3, Wasabi, R2, OneDrive)

Halten Sie eine Live-Kopie Ihrer Produktionsdaten in einer anderen Region oder Cloud vor und wechseln Sie im Störungsfall innerhalb von Minuten.

Warm-Standby-DR kombiniert einen primären Standort (z. B. AWS S3 oder OneDrive) mit einem kontinuierlich aktualisierten Standby (z. B. Cloudflare R2 oder Wasabi). RcloneView legt eine GUI über rclone, sodass Sie regelmäßige Synchronisationen planen, Abweichungen mit Compare validieren und den Standby für ein schnelles Failover einbinden (mount) können – ganz ohne Shell-Skripte.

Relevante Dokumentation

• Sync-Jobs erstellen: https://rcloneview.com/support/howto/rcloneview-basic/create-sync-jobs
• Job-Planung & Ausführung (Plus): https://rcloneview.com/support/howto/rcloneview-advanced/job-scheduling-and-execution
• Als lokales Laufwerk einbinden: https://rcloneview.com/support/howto/rcloneview-basic/mount-cloud-storage-as-a-local-drive
• Ordner vergleichen: https://rcloneview.com/support/howto/rcloneview-basic/compare-folder-contents

Alle Clouds an einem Ort verwalten & synchronisieren

RcloneView ist eine plattformübergreifende GUI für rclone. Vergleichen Sie Ordner, übertragen oder synchronisieren Sie Dateien und automatisieren Sie Multi-Cloud-Workflows mit einer klaren, visuellen Oberfläche.

• Ein-Klick-Jobs: Kopieren · Synchronisieren · Vergleichen
• Zeitpläne & Verlauf für zuverlässige Automatisierung
• Funktioniert mit Google Drive, OneDrive, Dropbox, S3, WebDAV, SFTP und mehr

WindowsmacOSLinux

Kostenlos loslegen →

Kernfunktionen kostenlos. Plus-Automatisierungen verfügbar.

Warum Warm-Standby mit RcloneView

• Schnellere Wiederherstellung: Standby-Kopien liegen innerhalb von Minuten/Stunden hinter dem Primärsystem, nicht Tagen.
• Cloud-Wahl: Kombinieren Sie S3, Wasabi, R2, B2, Google Drive, Dropbox oder OneDrive.
• Keine Skripte: Erstellen Sie Jobs per Assistent statt mit YAML/Cron.
• Sichtbare Abweichungen: Compare zeigt Diskrepanzen an, bevor ein Failover nötig wird.
• Sicherere Wiederherstellungen: Binden Sie den Standby ein und kopieren Sie zurück, ohne die Produktion zu berühren.

Strategie und Architektur

[Primary cloud/local/NAS] --(RcloneView scheduled Sync)--> [Standby cloud/region]
                                                \
                                                 --(Weekly Compare)--> [Drift report]

• Primär: wo Anwendungen schreiben (S3-Bucket, OneDrive-Site, GDrive-Workspace, NAS).
• Standby: eine andere Region/Anbieter mit Versionierung (R2/Wasabi/S3/B2).
• Steuerung: RcloneView führt die Synchronisation in Intervallen aus; Compare prüft die Integrität; Mount ermöglicht schnellen Zugriff während des Failovers.

Voraussetzungen

• Zwei in RcloneView konfigurierte Remotes (z. B. s3:prod-bucket und r2:standby-bucket).
• Versionierung auf dem Standby aktiviert, zur Absicherung von Rollbacks.
• IAM-/API-Berechtigungen für List/Read/Write auf beiden Seiten.
• Bandbreitenfenster für die geplante Replikation (nächtlich oder stündlich).

Schritt 1: Den Basis-Sync-Job erstellen

1. Erstellen Sie einen Sync-Job: Quelle = Primärsystem, Ziel = Standby.
2. Verwenden Sie eine einseitige Synchronisation, um neue/aktualisierte Dateien zu spiegeln; behalten Sie Löschungen bei, wenn Sie eine strikte Parität wünschen.
3. Fügen Sie im Schritt „Filtering“ Filter für störende Pfade hinzu (z. B. Cache/Temp).
4. Passen Sie unter Advanced Settings die Übertragungsanzahl an und aktivieren Sie den Checksummenvergleich, falls beide Seiten Hashes unterstützen.
5. Speichern Sie den Job, damit dieselben Einstellungen bei jedem Lauf gelten (Job Manager).

Schritt 2: Kontinuierliche Aktualisierungen planen

1. Aktivieren Sie im Job-Assistenten (Schritt 4: Scheduling, Plus-Lizenz) die Planung für den DR-Job.
2. Wählen Sie den Rhythmus: stündlich für Anwendungsdaten, nächtlich für Archive, und nutzen Sie Simulate, um kommende Läufe vorab zu prüfen.
3. Legen Sie unter Advanced Settings Wiederholungsversuche für instabile Verbindungen fest.
4. Führen Sie zusätzlich einen manuellen wöchentlichen Compare durch, um Abweichungen frühzeitig zu erkennen.

Schritt 3: Überprüfen und überwachen

• Nutzen Sie Compare, um sicherzustellen, dass die Objektanzahl übereinstimmt, bevor Sie den Standby für bereit erklären.
• Prüfen Sie die Job History auf Fehler oder Wiederholungen und starten Sie den Job erneut, falls ein Zeitfenster verpasst wurde.
• Behalten Sie die Versionierung auf dem Standby bei, damit versehentliche Löschungen wiederhergestellt werden können.

Schritt 4: Failover-Playbook

1. Standby einbinden: Verwenden Sie den Mount Manager, um das Ziel-Remote auf einen festen Pfad/Laufwerksbuchstaben einzubinden.
2. Richten Sie Workloads auf den eingebundenen Pfad oder den Standby-Bucket-Endpunkt aus.
3. Halten Sie das Primärsystem schreibgeschützt oder offline, bis die Störungsanalyse abgeschlossen ist.

Tuning-Tipps

• Latenzsensible Anwendungen: Reduzieren Sie die Übertragungsanzahl in den Advanced Settings und planen Sie die Ausführung in verkehrsarmen Zeiten.
• Compliance: Behalten Sie die Versionierung auf dem Standby bei und exportieren Sie die Job History für Audits.
• Kostenkontrolle: Schließen Sie Staging-/Temp-Ordner über Filter aus und wenden Sie Lifecycle-Richtlinien auf der Standby-Cloud an.
• Multi-Cloud: Führen Sie separate Jobs aus, wenn Sie zwei Standbys (z. B. R2 + Wasabi) aus demselben Primärsystem benötigen.

Checkliste zur Fehlerbehebung

• Abweichende Anzahl: Führen Sie Compare erneut aus und prüfen Sie die Job History auf übersprungene Elemente; stellen Sie sicher, dass die Versionierung aktiviert ist.
• Berechtigungsfehler: Stellen Sie sicher, dass die API-Schlüssel List/Read/Write auf beiden Clouds erlauben.
• Wiederherstellung löscht Daten: Verwenden Sie Copy (nicht Sync), wenn Sie Daten zurück in die Produktion bringen.

Halten Sie Ihren Standby warm, getestet und einsatzbereit, damit Failover ein Schalter ist – kein Wettlauf gegen die Zeit.

Unterstützte Cloud-Anbieter

Alle Anbieter ansehen →

Clouds verbinden →