Offsite NAS syncen

[Alternativende]

Hallo zusammen,
ich stehe derzeit vor folgender Aufgabenstellung und würde gerne eure Meinung dazu hören.

Zwei NAS-Systeme (beides OMV) die an zwei verschiedenen Standorten etwa 1KM voneinander entfernt stehen und per LWL mit 1GBit/s angebunden sind müssen miteinander synchronisiert werden. Es handelt sich um reine Backupsysteme die keine Services für User anbieten und nur fürs Backup laufen. Das entfernte NAS sicher die Daten in einen LUKS-Container, zwar ist der Standort an sich gesichert vor unbefugtem Zutritt, aber man weiß ja nie .

Zunächst würde ich gerne den Zugriff auf die beiden Systeme per IPTables auf ein paar wenige IP-Adressen einschränken, sicher ist sicher. Leider habe ich IPTables selbst auf der Kommandozeile noch nicht bearbeitet, wenn es da ein kleines Toturial gäbe was jemand kennt, wäre ich für nen Tipp dankbar.

Die größere Aufgabe ist sicherlich das Syncen der beiden Systeme. Die Sicherheit und Zuverlässigkeit der Synchronisation hat aller höchste Priorität.

Zunächst dachte ich an rsync über SSH. Ein kleines Script das alle paar Minuten von Cron angestoßen wird, läuft rsync bereits wird gewartet, andernfalls das sync gestartet. Der Vorteil hier ich könnte mich mittels dem Script auch auf dem Backupserver per SSH einloggen und schauen ob das Backup noch läuft, damit keine unvollständigen Files gesichert werden. Diese Lösung wäre eben selbst gebastelt und würde durchweg auf erprobte Software setzen.

Bei der weiteren Recherche bin ich auf Syncthing gestoßen das ich sogar per Addon auf OMV nach installieren könnte. Mit dieser Software habe ich bisher überhaupt keine Erfahrung und bin da auf euer Feedback angewiesen. Kann die Software alles was ich benötige? Ist sie stabil und sicher genug? Gibt es Möglichkeiten der Benachrichtigung per Mail bei Ausfall etc.?

Bin gespannt auf eure Meinungen.

Vielen Dank!

[schwedenmann]

Hallo


Und warum z.B. nicht unison nehmen ?

mfg
schwedenmann

[Alternativende]

Hi,
das war mir nicht bekannt das Programm. Liest sich ganz gut, klingt nach syncthing ohne schischi. Das ließe sich leicht auf der CLI einrichten und per Cron regelmäßig laufen lassen, in einem Skript verpackt kann ich mir bei Erfolg oder Misserfolg auch leicht Mails schicken lassen.

Das schaue ich mir mal näher an, Danke für den Tipp!

[Alternativende]

Hallo zusammen,
ich teste es derzeit mit unison, ein paar Parameter habe ich schon angepasst, läuft bisher ganz dankbar, aber der Teufel steckt ja immer im Detail.

Code: Alles auswählen

root = /srv/dev-disk-by-label-20TBext4/
root = ssh://nas02//srv/dev-disk-by-label-20TBext4Backup/Backup

batch = true
auto = true
fastcheck = true
times = true
prefer=newer
#logfile = /home/BENUTZER/.unison/logfile-PROFILNAME

[heisenberg]

Wenn es um Backup geht, dann bedeutet das meinem Verständnis nach sync in eine Richtung.

Dafür empfehle ich Dir lsyncd. Das ist ein kontiniuierlicher rsync. D. h. sobald sich Dateien ändern, werden die kopiert/gelöscht. Sehr effizient.

Hier auch mal eine Beispielkonfigurationsdatei(weil ich die selten so einfach im Internet rumstehen sehe):

Code: Alles auswählen

sync {
    default.rsync,
    source    = "/quell/verzeichnis/.",
    target    = "zielserver-ip-oder-hostname:/ziel/verzeichnis/",
    rsync     = {                                                                                                                                                                                   
        _extra  = { "-v", "-H", "--numeric-ids", "--exclude=/will/ich/nicht**" },         
        archive = true                                                                                                                                                                              
    }                                                                                                                                                                                               
}    

Vorher muß man noch die Anzahl der inotify-watches erhöhen, damit die Anzahl der zu überwachenden Dateien mindestens so groß ist, wie die Anzahl der zu übertragenden Dateien:

Code: Alles auswählen

#setze den Wert permanent
echo  "fs.inotify.max_user_watches = 10000000" >/etc/sysctl.d/10-lsyncdinotify.conf

#lade alle Werte neu
sysctl --system

Eine Unit-Datei für systemd sähe z. B. so aus:

Code: Alles auswählen

[Unit]
Description=Synchronsation statischer Dateien zum Server meinserver
After=network.target 

[Service]
ExecStart=/usr/bin/lsyncd -nodaemon /etc/lsyncd/meine-lsyncd.conf
KillMode=process
Restart=on-failure
Type=simple

[Install]
WantedBy=multi-user.target

lsyncd ist grundsätzlich nur für den Sync in eine Richtung geeignet. Unison ist für einen sync in beide Richtungen gedacht. Sync in beide Richtungen ist wegen der Konfliktauflösung aber kritisch(natürlich nur wenn auch auf beiden Seiten Änderungen stattfinden). Deswegen bevorzuge ich selbst grundsätzlich eher eine rsync-basierte-Lösung, weil einfach zu benutzen, sehr flexibel und ausgereift.

[mludwig]

Synchronisieren von 2 NAS, zumindest in eine Richtung, würde ich als eher unvollständiges Backup ansehen. Das hängt vielleicht auch davon ab wovor man sich schützen möchte. Insbesondere bei der Live-Synchronisation (lsync) hätte ich aber Bedenken. Das geht in Richtung Raid 1 und ist räumlich verteilt, aber nicht für Backups? Nutzer löscht ausversehen eine Datei? Backup auch weg ... Verschlüsselungstrojaner? Backup auch verschlüsselt. Beim Speichern verkehrte Datei überschrieben ... und sie ist weg ...

Sync hilft hier eher gegen Ausfall eines Standortes, also Defekt/Stromausfall/Diebstahl/Feuer etc. Backup sollte aber auch die anderen Szenarien mit berücksichtigen.

Ich würde eher so etwas wie rsnapshot verwenden. Basiert auch auf rsync, aber man hat einstellbar viele Generationen seiner Dateien / Verzeichnisse, ohne das es sehr viel Platz kostet.

[heisenberg]

Nutzer löscht ausversehen eine Datei? Backup auch weg ... Verschlüsselungstrojaner?

Ja. Dem stimme ich vollkommen zu.

Mein Gedanke war, dass das Quellsystem bereits ein Backupsystem ist(das z. B. rotiert wird) und auf das zweite gesynct wird. Nur einen Livesync als backup zu haben taugt nicht.

Das Backup sollte immer passiv(Aus Sicht des zu sichernden Servers) von außen geholt werden und nicht aktiv irgendwo hingeschrieben werden. Die Möglichkeit des schreibenden Zugriffs auf das Backup sollten vermieden werden.

[Alternativende]

Mein Gedanke war, dass das Quellsystem bereits ein Backupsystem ist(das z. B. rotiert wird) und auf das zweite gesynct wird. Nur einen Livesync als backup zu haben taugt nicht.

Das Backup sollte immer passiv(Aus Sicht des zu sichernden Servers) von außen geholt werden und nicht aktiv irgendwo hingeschrieben werden. Die Möglichkeit des schreibenden Zugriffs auf das Backup sollten vermieden werden.

So sieht es auch aus. Sowohl das Backupsystem als auch das entfernt stehende System mit dem gesynct werden soll bieten keinerlei Dienste im Netzwerk an und sind für normale User nicht schreibberechtigt. Lediglich die Backupsoftware (Bareos) hat Zugriff auf die Shares. Dieser Zugriff erfolgt ebenfalls ausschließlich über SSH, sodass auch keine Daten im Klartext über die Leitung gehen. Ich möchte mit diesem System auch überhaupt kein weiteres Backup schaffen, mir geht es nur darum bei Brand etc. ein System zu haben auf dem sämtliche Backupdaten ebenfalls vorhanden sind.

Derzeit stellt es sich für mich etwas schwierig dar die regelmäßige Synchronisation während eines laufenden Backups zu konfigurieren. Ich glaube mit dem Parameter prefer=newer könnte ich da Erfolg haben. Grundsätzlich soll das syncen ja nicht das evtl. noch laufende Backup verlangsamen, es sollte aber auch nicht erst morgens laufen wenn die Leute zur Arbeit kommen. Die Richtigkeit der Daten ist aber enorm wichtig, sodass ich im Moment eher mit dem Gedanken spiele den Syncvorgang doch erst morgens zu einer bestimmten Uhrzeit per Cron starten zu lassen.

Erkennt lsyncd ob eine Datei noch im Zugriff ist? Falls ja wäre das ja vielleicht sogar noch idealer.