Frage Nutzt jemand Syncthing?

HerrRossi

Urgestein
Mitglied seit
Jul 25, 2018
Beiträge
6.778
Bewertungspunkte
2.243
Punkte
113
Ich bin gerade dabei, mein Backup zu automatisieren und frage mich, womit ich das am besten automatisieren kann.

Auf dem Server könnte man rsync nehmen, das ginge auch auf den Clients mit Linux und Win10 (Deltacopy oder robocopy).

Jetzt bin ich aber auf Syncthing gestoßen und das scheint mir sehr interessant zu sein, weil es zusätzlich auch unter Android läuft, man könnte also auch die Smartphones damit sichern.

Nutzt jemand die Software? Funzt sie reibungslos?
 
Ich benutze privat borg Backup und habe es auch in der Firma im Einsatz. Borg funktioniert ganz gut. Eine Alternative ist auch restic. Zu beiden Lösungen gibt es keine GUI. Seit ein paar Monaten nutze ich parallel Duplicati.

Ein Bekannter nutzt Syncthing, aber primär als Dropbox-Ersatz. Bis jetzt hatte er noch keine Probleme. Ich weiß nur nicht, ob das für ein Backup taugt. So viel ich weiß hat Syncthing keine Versionierung der Dateien, d.h. wenn man löscht dann löscht man sie ggf. auch im Backup.
 
Klingt eher wie ein Dropbox, NextCloud, ... Filesync/-share Programm. Nicht so sehr nach einem (vernuenftigen) Backuptool.

Ich hab an zwei Windows Desktops Duplicati am laufen (noch ne alte Version). Das geht wohl auch unter Linux. Und beherrscht viele Targets (ftp, cloud storage, ssh, ....). Wenn es nichts natives fuers jeweilige OS sein soll.
 
Ich nutze/teste die neue Version von Duplicati mit einem S3 Backend. Das S3 Backend habe ich mit minio realisiert. Ich habe alles unter Linux laufen, Windows sollte kein Problem sein. Minio finde ich recht praktisch, da man heute öfter eine S3 Schnittstelle benötigt. Ich kann bei Bedarf mein Setup auch einmal genauer vorstellen.

Wenn man viel und ganz viele Clients sichern möchte, dann kann man sich auch BackupPC und Bareos/Bacula ansehen. Wobei Bareos sehr komplex ist. Diese Lösungen können alle Windows sichern.
 
Danke schonmal für die Antworten.

Delete habe ich bei rsync abgeschaltet (ich habe das diese Nacht laufen lassen), duplicati könnte ich auch noch ausprobieren, was sind denn dabei die Unterschiede? Versionierung brauche ich eigentlich nicht.

Kurze Hintergrundinfo: ich nutze Openmediavault für den Heimserver, rsync und duplicati laufen als plugins, syncthing würde über docker laufen.
 
Ich hole einmal etwas mehr aus. Ein Backup ist eine unveränderliche Datensicherung, welche vor Hardwareausfällen, dicke Finger und sonstige Missgeschicke schützt. Da ein einzelnes Backup unveränderlich sein sollte, muss man immer ein neues Backup anlegen. Alles andere ist nur eine Kopie von Daten.

rsync normal laufen lassen
rsync -av original/ backup/ Der gesamte Inhalt vom Verzeichnis original/ wird in das Verzeichnis backup/ kopiert. Wenn sich eine Datei im Verzeichnis original/ ändert, dann wird sie im Verzeichnis backup/ überschrieben. Das kann sehr ungeschickt sein, wenn eine Datei ausversehen ändert oder wenn man sich einen Cryprotrojaner einfängt. Wenn eine Datei im Original gelöscht wird, dann bleibt sie im Backup bestehen. Man hat also nur eine Kopie der Daten. Wenn man einen Fehler erst nach einem "Backup" bemerkt hat, dann ist es zu spät.

rsync als Backup missbrauchen
rsync -av rsync -av --backup-dir=backup/$(date +%F_%H-%M) original/ backup/ Das funktioniert im Grunde genommen wie oben, aber sämtlich Dateien werden vor dem überschreiben ein ein separates Verzeichnis kopiert, z.B. backup/2019-09-24_13-30. Dieses wird bei Bedarf automatisch angelegt. So ist sicher gestellt, dass man keine alten Daten überschreibt. Man muss ggf. ab und zu die alten Backupverzeichnisse löschen.

duplicati
Das ist von Haus aus eine Backup-Lösung. Man kann sagen wie viele Backups man aufheben möchte. Weiterhin kann man sich recht bequem die vorhandenen Backupsätze ansehen und wiederherstellen. Der Clou von Duplicati ist, dass die Dateien in Chunks (Blöcke) zerlegt werden. Es werden nur die dynamisch berechneten Chunks gespeichert und nicht die eigentliche Datei. Wenn sich eine Datei nur etwas ändert, dann ändern sich nicht alle Chunks. Es müssen nur die Chunks gepeichert werden, welche neu sind. Dadurch kann man mit relativ wenig Platz sehr viele Backups aufheben. Wenn man eine Datei 3 mal rum liegen hat, dann nimmt sie nur einmal Platz im Backup weg. Da die selben Chunks verwendet werden.
1862

Das heißt, dass ich 6,25 GB Daten liegen habe und 12 Backups. Die 12 Backups benötigen nur 5,42GB. Das kommt durch die Komprimierung.

syncthing
Das ist im Grunde genommen wie rsync mit --delete. Es kann sein, dass man das löschen auch abstellen kann. Man hat nur eine Kopie der Daten. Wenn man den Dienst die ganze Zeit laufen lässt, dann macht man die Daten auch noch synchron auf allen Kopien kaputt - Analog zu RAID ist kein Backup. Ich würde syncthing ehr mit einem RAID 1 (Mirror) vergleichen, statt eines Backups.

Man kann syncthing auch so konfigurieren, dass es Versionen anlegt. Wie gut das funktioniert weiß ich nicht. Wenn ich die Woche Zeit habe, dann kann ich es bei Bedarf testen.
 
Danke für die Erklärung, dann werde ich es mal mit Duplicati versuchen. Das mit der Größe verwirrt mich aber jetzt etwas. Sagen wir mal, ich möchte 5TB sichern, dann müssen diese Dateien doch einmalig komplett auf dem Backupdatenträger vorhanden sein!? Und beim Differenzbackup werden dann nur noch die geänderten Chunks geschrieben!? Oder wie oder was? ;)
 
Ich probiere es dann mal aus, auf dem Server liegen alle möglichen Arten von Dateien.
 
Hier ist Video zu Restic. Ab Minute 28 wird erklärt wie der Chunk-Algorithmus funktioniert. Das Verfahren funktioniert bei Duplicati ähnlich.

Beim ersten Backup werden neben der Kompression auch Chunks berechnet. Je nachdem was man für Daten hat, können da auch schon Chunks doppelt vorkommen.

Das Beispiel folgende ist an den Haaren herbei gezogen: Du hast viele Briefe mit den gleichen Briefkopf, welcher ein Bild enthält. Mit etwas Glück findet der Chunk-Algorithmus das heraus und von Deinen 1000 Briefen wird das große Bild im Briefkopf nur einmal gespeichert.
 
Tjo, oder man nimmt gleich was gescheites wie Solarish mit ZFS. Das bietet sichere (unveränderliche), sofortige und maximal platzsparende Snaps auch auf Blockbasis (machen manche alle 5 Minuten bei 24h keep-alive), übrigens für die ganz Platzbewussten auch Kompression und Deduplication auf Filesystem-Ebene, copy on Write, Scrubs, Self-healing (parity oder mirror vorausgesetzt) und diverse weitere Details für Feinschmecker, mit napp-it als GUI sogar in komfortabel inkl. Autojobs. Da gehen dir deine Daten nur noch beim physischen Defekt oder Diebstahl verloren. Ach und dafür gibt’s ja - auch wieder schon auf Filesystemebene - Replikation auf ein zweites ZFS-System, was dann auch wieder die gleichen Schmankerl bietet...

Jo, man darf mich als Fanboi bezeichnen. Dagegen ist alles andere einfach Spielzeug.

sorry, dass ich mich da wiederhole, ihr könnt’s bestimmt nicht mehr hören. :D
 
ZFS ist mir zu kostenintensiv und unflexibel, weil man immer direkt drei Festplatten kaufen muss, wenn man mehr Speicher braucht.
 
Jeder sollte sich wirklich etwas um seine Daten kümmern. Ein ganz guter Tipp von mir, auf jeden Fall mal ein Restore der Daten probieren. Ein Backup, welches man nicht wiederherstellen kann, ist nichts wert.

Jo, man darf mich als Fanboi bezeichnen. Dagegen ist alles andere einfach Spielzeug.

zfs gibt es auch für Linux. Dort funktioniert es besser als btrfs bzw. btrfs ist eine Krankheit, wenn man zfs kennt.

Etwas OT: Ich habe leidenschaftlich gerne als Solaris Admin gearbeitet. Und weil Solaris so cool war, habe ich es auch auf den Laptop gehabt. Seit einigen Jahren arbeite ich nur noch in Linux-Umgebungen. Im übrigen, alle die Docker cool und innovativ finden, das hatte Solaris mit Zonen schon 2005 - in funktionierend :cool:
 
Ach ja, noch zur Ergänzung: neben dem angestrebten Backup läuft bei mir ja auch noch Snapraid nebenher, ein eventueller Datenverlust hält sich so hoffentlich in Grenzen.
 
ZFS ist mir zu kostenintensiv und unflexibel, weil man immer direkt drei Festplatten kaufen muss, wenn man mehr Speicher braucht.

Das stimmt nicht ganz. RAIDZ bzw. RAIDZ2 funktioniert anders. Wenn ein zpool voll wird, dann kann man theoretisch eine weitere Platte rein stecken und den Pool neu balancieren bzw. man lebt mit dem Ungleichgewicht. Zum Balancieren gibt es aber Automatismus. Man kann auch verschieden große Platten nehmen und die Platten nach und nach durchtauschen. Also 4 alte Platten durch Neue ersetzen.
 
Oben Unten