Läuft Ihre Sicherung, aber wurde die Wiederherstellung nie geprüft? WZ-IT richtet Sicherungen ein, testet die Wiederherstellung regelmäßig und dokumentiert sie als Teil von Managed Operations. Sicherungskonzept gemeinsam prüfen
Vergleiche zwischen restic, Borg und Kopia gibt es reichlich, und fast alle stammen aus der Heimserver-Ecke. Dort zählen andere Dinge: Wie schnell läuft der erste Durchlauf, wie viel Platz spart die Deduplizierung, welches Werkzeug hat die schönere Oberfläche.
Im Unternehmensbetrieb verschiebt sich das. Eine Sicherung, die täglich läuft, ist wertlos, solange niemand geprüft hat, ob daraus ein arbeitsfähiges System zurückkommt. Und die Frage, welches Werkzeug 15 Prozent schneller sichert, ist nachrangig gegenüber der Frage, wer im Ernstfall die Wiederherstellung durchführt.
Dieser Beitrag ordnet die drei Werkzeuge anhand überprüfbarer Merkmale ein und benennt danach die Punkte, an denen Sicherungskonzepte tatsächlich scheitern. Alle Angaben aus den Repositories, Stand Juli 2026.
Inhaltsverzeichnis
- Die drei Werkzeuge im Überblick
- Was alle drei gleich machen
- Wo sie sich unterscheiden
- Der Versionsstand als Entscheidungsfaktor
- restic
- Borg
- Kopia
- Abgrenzung: Dateisicherung ist nicht Systemsicherung
- Welches Werkzeug wofür
- Woran Sicherungskonzepte tatsächlich scheitern
- Unser Vorgehen bei WZ-IT
- Weiterführende Guides
Die drei Werkzeuge im Überblick
Angaben aus den öffentlichen Repositories, Stand Juli 2026.
| Werkzeug | GitHub-Sterne | Lizenz | Aktuelle Version | Veröffentlicht | Oberfläche |
|---|---|---|---|---|---|
| restic | 35.691 | BSD-2-Clause | v0.19.1 | 05.07.2026 | Kommandozeile |
| Kopia | 13.951 | Apache-2.0 | v0.23.1 | 16.06.2026 | Kommandozeile und grafisch |
| Borg | 13.649 | BSD-3-Clause | 1.4.5 | 18.07.2026 | Kommandozeile |
Alle drei sind uneingeschränkt quelloffen. Keines trennt Funktionen in einen proprietären Teil ab, wie es in anderen Bereichen üblich geworden ist. Für ein Werkzeug, das im Ernstfall zwischen Ihnen und dem Datenverlust steht, ist das ein nicht unerheblicher Punkt.
Was alle drei gleich machen
Die Gemeinsamkeiten sind größer als die Unterschiede, und das wird in Vergleichen selten deutlich gesagt:
- Verschlüsselung vor der Übertragung, mit Schlüsseln, die beim Betreiber bleiben
- Deduplizierung auf Blockebene, sodass gleiche Inhalte nur einmal liegen
- Versionierte Sicherungspunkte, aus denen sich ein beliebiger früherer Stand herstellen lässt
- Aufbewahrungsregeln, etwa täglich sieben, wöchentlich vier, monatlich zwölf
- Prüfbarkeit der abgelegten Daten gegen stille Verfälschung
Wer eines der drei sauber betreibt, hat kein schlechteres Ergebnis als mit einem der anderen. Die Auswahl entscheidet über Aufwand und Passung, nicht über Sicherheit.
Wo sie sich unterscheiden
| Merkmal | restic | Borg | Kopia |
|---|---|---|---|
| S3-kompatible Ziele direkt | ja | nein, Umweg nötig | ja |
| Grafische Anwendung | nein | nein | ja |
| Gegenstelle | einfacher Speicher | Programm auf der Gegenseite | einfacher Speicher |
| Formale Version | vor 1.0 | 1.x | vor 1.0 |
Der wichtigste Unterschied im Betrieb ist die Gegenstelle. Borg erwartet auf der Zielseite ein laufendes Borg, was Geschwindigkeit bringt und einen Server voraussetzt. restic und Kopia behandeln das Ziel als dummen Speicher, was Objektspeicher unmittelbar nutzbar macht und Rechenlast auf die Quelle verlagert.
Daraus folgt eine praktische Regel: Wer nach Objektspeicher sichern will, ohne dafür einen weiteren Server zu betreiben, kommt mit restic oder Kopia schneller ans Ziel. Wer ohnehin einen Sicherungsserver betreibt, kann Borgs Modell nutzen.
Der Versionsstand als Entscheidungsfaktor
Ein Punkt, der in Heimserver-Vergleichen nicht vorkommt, im Unternehmen aber gefragt wird: restic und Kopia stehen formal vor Version 1.0.
Das ist kein Ausschlusskriterium. Beide werden seit Jahren produktiv eingesetzt, restic hat mit über 35.000 Sternen die größte Verbreitung der drei. Aber eine Vorversion behält sich üblicherweise Änderungen an Verhalten und Formaten vor, und bei einem Sicherungswerkzeug betrifft das im Zweifel die Lesbarkeit älterer Sicherungspunkte.
Praktische Folge, unabhängig von der Wahl: Aktualisierungen des Sicherungswerkzeugs gehören getestet wie jede andere Änderung, und zwar mit einer Wiederherstellung aus einem vor der Aktualisierung erstellten Sicherungspunkt.
restic
Das verbreitetste der drei, unter BSD-2-Clause, geschrieben in Go und als einzelne ausführbare Datei verteilbar. Spricht S3, Backblaze B2, Azure, Google Cloud Storage sowie SFTP direkt an und lässt sich über rclone an praktisch jedes weitere Ziel anbinden.
Die Stärke ist die Breite der Ziele und die Einfachheit der Einrichtung. Die aktuelle Version v0.19.1 stammt vom 5. Juli 2026.
Borg
Das älteste der drei und das einzige mit einer 1.x-Version, aktuell 1.4.5 vom 18. Juli 2026, unter BSD-3-Clause. Ausgelegt auf ein Repository, das entweder lokal liegt oder über SSH erreichbar ist, mit Borg auf der Gegenseite.
Diese Bauart bringt Geschwindigkeitsvorteile bei großen Beständen und setzt einen Sicherungsserver voraus. Für Objektspeicher als Ziel ist Borg der umständlichste Weg der drei.
Kopia
Das jüngste der drei, unter Apache-2.0, und das einzige mit einer grafischen Anwendung neben der Kommandozeile. Spricht ebenfalls S3-kompatible Ziele direkt an. Aktuell v0.23.1 vom 16. Juni 2026.
Die grafische Oberfläche ist der klarste Unterschied. Für Server im automatisierten Betrieb spielt sie keine Rolle, für Arbeitsplatzsicherungen durch wechselnde Personen schon.
Abgrenzung: Dateisicherung ist nicht Systemsicherung
Ein Punkt, an dem Konzepte regelmäßig auseinanderfallen: Diese drei Werkzeuge sichern Dateien und Verzeichnisse innerhalb eines laufenden Systems. Sie sichern keine virtuellen Maschinen als Ganzes.
Wer Proxmox betreibt, braucht für Maschinen und Container eine Sicherung, die die Virtualisierung kennt. Dafür gibt es den Proxmox Backup Server, der auf Blockebene arbeitet und Änderungen zwischen Sicherungsläufen verfolgt. Wie sich der mit Objektspeicher verbindet, haben wir gesondert beschrieben.
In der Praxis laufen beide Ebenen nebeneinander: die Maschinensicherung für den vollständigen Wiederanlauf, die Dateisicherung für einzelne Datenbestände, längere Aufbewahrung oder Systeme außerhalb der Virtualisierung.
Welches Werkzeug wofür
| Ausgangslage | Naheliegende Wahl | Begründung |
|---|---|---|
| Ziel ist ein Objektspeicher, kein eigener Sicherungsserver | restic | größte Zielauswahl, einfachste Einrichtung |
| Sicherungsserver vorhanden, große Bestände über LAN oder SSH | Borg | Gegenstelle rechnet mit, einzige 1.x-Version |
| Arbeitsplätze mit wechselnden Nutzern, Oberfläche gewünscht | Kopia | grafische Anwendung, S3-Ziele direkt |
| Virtuelle Maschinen unter Proxmox | Proxmox Backup Server | arbeitet auf Blockebene mit Kenntnis der Virtualisierung |
| Mehrere der obigen Fälle | Kombination | eine Ebene je Aufgabe, keine Universallösung erzwingen |
Woran Sicherungskonzepte tatsächlich scheitern
Nach unserer Erfahrung entscheidet keiner der Punkte oben über den Ausgang eines Ernstfalls. Diese vier tun es:
Die Wiederherstellung wurde nie geprüft. Der häufigste Befund. Sicherungen laufen seit Jahren, niemand hat je zurückgespielt. Ob das Ergebnis ein arbeitsfähiges System ist, weiß man erst, wenn man es braucht, und dann ist es zu spät für Überraschungen.
Es gibt nur einen Ablageort. Verschlüsselungsangriffe zielen inzwischen ausdrücklich auf erreichbare Sicherungen. Eine Kopie, die vom gesicherten System aus gelöscht werden kann, ist im Angriffsfall keine.
Die Wiederherstellungsdauer ist unbekannt. Aus drei Terabyte über eine 100-Mbit-Leitung zurückzuspielen dauert Tage. Wenn die Erwartung bei vier Stunden liegt, ist das Konzept falsch dimensioniert, unabhängig vom Werkzeug.
Datenbanken werden dateiweise gesichert. Eine laufende Datenbank im Dateisystem mitzunehmen ergibt im Zweifel einen unbrauchbaren Stand. Datenbanken brauchen einen eigenen Auszug oder eine Momentaufnahme mit Kenntnis der Anwendung.
Noch unklar, welches Werkzeug passt? Der Orientierungsworkshop ordnet Ihre Anforderungen und liefert eine priorisierte Themenliste mit Empfehlung je Thema. Ab 1.490 € netto, remote.
Unser Vorgehen bei WZ-IT
Wir setzen alle drei Werkzeuge ein, je nach Umgebung, und haben keine Hausmarke. Die Auswahl fällt nach dem Ablageort und danach, wer die Sicherung bedienen können muss.
Was wir nicht verhandeln, ist der Wiederherstellungstest. Er gehört in den Betrieb, nicht in die Absicht, und er wird dokumentiert. Aus demselben Grund gehört zu jedem Konzept eine benannte Wiederherstellungsdauer, gemessen statt geschätzt.
Bei virtualisierten Umgebungen kombinieren wir Maschinensicherung und Dateisicherung, statt eine Ebene beides erledigen zu lassen. Das kostet etwas mehr Speicher und spart im Ernstfall Stunden.
Weiterführende Guides
- Proxmox Backup Server vs. Veeam - Maschinensicherung für Proxmox im Vergleich
- Proxmox Backup Server 4.2 mit S3-Storage - Maschinensicherung in den Objektspeicher
- Proxmox Backup Server - die Ebene unterhalb der Dateisicherung
- Managed Operations - Sicherung, Überwachung und Wiederherstellung im Vertrag
- Proxmox-Wartung - laufender Betrieb einschließlich Sicherungsprüfung
Wissen Sie, wie lange eine vollständige Wiederherstellung dauert? Wir messen es, statt zu schätzen, und bringen Sicherung und Erwartung in Übereinstimmung. Termin vereinbaren
