Hallo, ich möchte gerne einige Vezeichnisse von meinem Ubuntu Server stündlich auf eine andere Maschine sichern. Mein naiver Ansatz wäre: - Bash Skrit erstellen, das - NFS-Share mounted - Per rsync die Verzeichnisse rüberkopiert - NFS SHare unmounted - Per Crontab das Skript stündlich aufrufen Allerdings wird das Skript dann doch recht länglich. Und eine Fehlerbahndlung (vorzugsweise eine E-Mail im Fehlerfall) müsste man auch noch dazubasteln. Bevor ich mir die Arbeit mache: geht das auch einfacher? Gibt es ggf. schon ein fertiges Paket, das sich leicht konfigurieren lässt und das alles out-of -the-box kann?
Bernd schrieb: > Hallo, Hallo. > - NFS-Share mounted > - Per rsync die Verzeichnisse rüberkopiert > - NFS SHare unmounted > Bevor ich mir die Arbeit mache: geht das auch einfacher? rsync kann direkt per ssh übertragen. (wenn die andere Büchse einen sshd laufen hat). Da braucht's dann auch keinen mount/unmount. Und mit einem SSH key geht's bequem auch ohne Interaktion.
Ich würde BorgBackup empfehlen. Nicht nur eine simple Kopie, sondern du bekommst gleich Versionierung, Kompression und Deduplikation dazu. NFS kannst du dir sparen und die Daten durch Borg per SSH übertragen lassen. Ist relativ schnell konfiguriert und nach meiner inzwischen jahrelagen Erfahrung ziemlich sorgenfrei.
Hallo, die rsync Lösung ist für Backup nur bedingt geeignet. Du überschreibst damit ja auch die Files im Ziel (und löschst dort auch, was auf der Quelle gelöscht wurde, sofern du --delete verwendest). Mit einem Backup willst du dich aber schützen, falls Inhalte versehentlich oder durch Fehlfunktionen/Viren/Trojaner verändert wurden. Du kannst natürlich auch mir rsync eine getrennte Kopie jede Stunden erstellen, aber das ist meist auch nicht was du willst. Schau dir z.B. mal die Tools borgbackup oder restic. Greets, Sebastian.
:
Bearbeitet durch User
Rsync kann über hardlinks versionieren, überschreibt dann nicht das Ziel. Es gibt diverse Tools, die auf rsync aufsetzen und das verwalten. Vorteil von rsync gegenüber Borg: Das Zielmedium benötigt kein Restore-Tool, sondern ist direkt ansprechbar.
Norbert schrieb: > rsync kann direkt per ssh übertragen. (wenn die andere Büchse einen sshd > laufen hat). Da braucht's dann auch keinen mount/unmount. > Und mit einem SSH key geht's bequem auch ohne Interaktion. Und wenn man das ganze auch noch in schnell haben will, läßt man das nicht im SSH-Modus laufen, sondern spricht den rsyncd auf dem NAS an. Denn SSH lastet mit seiner Encryption extrem die CPUs aus, so daß man je nach Leistungsfähigkeit von PC und NAS u.U. nur mit 10-20MB/s herumdümpelt. Der Zielpfad muß dabei mit rsync:// anfangen, und der allgemeine Zielpfad wird nicht direkt angesprochen, sondern über Modulnamen (Aliase für Zielpfade), die man in der /etc/rsync.conf auf dem NAS definiert. rsync -avh --progress --delete <source path> rsync://<user>@<host>/<modulname>/<SubDir>
(prx) A. K. schrieb: > Vorteil von rsync gegenüber Borg: Das Zielmedium benötigt kein > Restore-Tool, sondern ist direkt ansprechbar. Was bei mir schon wieder ein Ausschlußkriterium für Borg wäre ...
Ich mach mit rsync (genauer: dem darauf aufsetzenden rsnapshot) nicht nur inkrementelle Backups meiner Datenpartition sondern auch der Systempartitionen diverser Systeme (vom Desktop, über den Raspberry, zur VM). Das schöne ist, man kann in den Backups mit einem beliebigen File-Browser navigieren. Restore klappt auch entweder über rsync oder primitiv per cp.
Brax schrieb: > Ich werfe mal restic in den Raum - https://restic.net Ohh, dann liegen damit schon zwei restics im Raum ...
(prx) A. K. schrieb: > Rsync kann über hardlinks versionieren, überschreibt dann nicht das > Ziel. Es gibt diverse Tools, die auf rsync aufsetzen und das verwalten. > > Vorteil von rsync gegenüber Borg: Das Zielmedium benötigt kein > Restore-Tool, sondern ist direkt ansprechbar. Restic liefert ein Fuse-Modul dafür implementiert: https://restic.readthedocs.io/en/latest/050_restore.html
Brtfs oder zfs nutzen wäre auch eine Möglichkeit. Dann stündlich einen snapshot erstellen und den dann remote replizieren. Schau dir Mal truenas und proxmox an. Die bringen für die Datenhaltung eigentlich alles mit, haben eine web-gui und haben mit e-mail benachrichtigungen kein Problem. Dein Ubuntu ist in beiden fällen Recht easy als virtuelles System installiert. Ganz nebenbei:Backup von nicht Konsistenzgeprüftenndaten ist ein eigenes Problem. Lies dir Mal ein paar Artikel zu scrubbing bei zfs und brtfs durch. Übrigens habe ich mich für truenas entschieden un Stelle aktuell auf truenas scale um.73
G. K. schrieb: > Restic liefert ein Fuse-Modul dafür implementiert: Das ist doch ein restic-spezifisches Filesystem, an das man ohne Restic-spezifische Driver/Module wohl nicht rankommt - also nichts mit "direkt ansprechbar"
Jens G. schrieb: > (prx) A. K. schrieb: >> Vorteil von rsync gegenüber Borg: Das Zielmedium benötigt kein >> Restore-Tool, sondern ist direkt ansprechbar. > > Was bei mir schon wieder ein Ausschlußkriterium für Borg wäre ... Ach, BorgBackup ist in den Repos der üblichen Distributionen, das tut nicht weh. Die Backups lassen sich über FUSE mounten und können zudem verschlüsselt werden, was aus meiner Sicht ein großer Vorteil in nicht-vertrauenswürdigen Umgebungen ist. Und für Menschen, für die die Eingabe von Befehlen in eine Shell eine Zumutung darstellt, gibt es auch einen Desktop-Client mit GUI. Ansonsten gibt es natürlich noch restic und Duplicity, die Backups ebenfalls verschlüsseln können. Und wer komplexere Anforderungen hat, könnte sich aber auch einmal backupninja anschauen, das alle diese Programme unterstützt, mit einfachen Konfigurationsdateien in /etc/backup.d/ gesteuert wird und weitere Aktionen vor dem eigentlichen Backupwerkzeug ausführen kann, wie zum Beispiel Datenbankdumps anfertigen. HF, YMMV.
Hans W. schrieb: > Brtfs oder zfs nutzen wäre auch eine Möglichkeit. Dann stündlich einen > snapshot erstellen und den dann remote replizieren. > > Schau dir Mal truenas und proxmox an. Die bringen für die Datenhaltung > eigentlich alles mit, haben eine web-gui und haben mit e-mail > benachrichtigungen kein Problem. Über Truenas kann ich nichts sagen, aber von Proxmox rate ich mittlerweile ab. Das wurde vor meiner Zeit bei meinem aktuellen Arbeitgeber zum Betrieb und für Snapshot-Backups einer Infrastruktur mit ca. 60 VMs benutzt, und leider froren die VMs dabei in unregelmäßigen Abständen ein.
Du rätst mittlerweile von etwas ab, was vor Deiner Zeit genutzt wurde? Meinst Du, daß es bei Proxmox keinerlei Weiterentwicklung, Fehlerbereinigung etc. gibt?
Dann noch rdiff-backup. Das macht genau sowas. Ohne restore Tool und „langsam“ über ssh.
Ein T. schrieb: > Hans W. schrieb: >> Brtfs oder zfs nutzen wäre auch eine Möglichkeit. Dann stündlich einen >> snapshot erstellen und den dann remote replizieren. >> >> Schau dir Mal truenas und proxmox an. Die bringen für die Datenhaltung >> eigentlich alles mit, haben eine web-gui und haben mit e-mail >> benachrichtigungen kein Problem. > > Über Truenas kann ich nichts sagen, aber von Proxmox rate ich > mittlerweile ab. Das wurde vor meiner Zeit bei meinem aktuellen > Arbeitgeber zum Betrieb und für Snapshot-Backups einer Infrastruktur mit > ca. 60 VMs benutzt, und leider froren die VMs dabei in unregelmäßigen > Abständen ein. Das war evtl KVM libvirt geschuldet. Was es aber schon seit ein paar Jahren nicht mehr macht…
Nextcloud? Plattformübergreifend, mit praktischer Web-Oberfläche und Mobil-Apps, bidirektionale Synchronisation, ziemlich performant.
Niklas G. schrieb: > Nextcloud? Plattformübergreifend, mit praktischer Web-Oberfläche und > Mobil-Apps, bidirektionale Synchronisation, ziemlich performant. Was is daran Backup?
Jörg E. schrieb: > Was is daran Backup? Die Daten sind auf einem anderen System gesichert und versioniert, versehentlich gelöschtes landet im Papierkorb statt sofort für immer zu verschwinden.
Niklas G. schrieb: > Jörg E. schrieb: >> Was is daran Backup? > > Die Daten sind auf einem anderen System gesichert und versioniert, > versehentlich gelöschtes landet im Papierkorb statt sofort für immer zu > verschwinden. Ah ok 😊 Denke für seinen Fall zuviel „Overhead“
Ein T. schrieb: > Proxmox rate ich mittlerweile ab. Wenn Proxmox ernste Problem hat, werden wir davon in den nächsten Monaten sicherlich hören. Das ist immerhin einer der meistgenannten Kandidaten bei der Flucht aus VMware im Enterprise-Umfeld.
:
Bearbeitet durch User
Jörg E. schrieb: > Denke für seinen Fall zuviel „Overhead“ Möglich, aber weil es wirklich sehr praktisch ist trotzdem eine Überlegung wert.
Harald K. schrieb: > Du rätst mittlerweile von etwas ab, was vor Deiner Zeit genutzt > wurde? Es gehört keine besondere Geistesgröße zu dem Gedanken, daß ich das Dingsi weiland übernommen habe. Aber Mitdenken ist wohl nicht so Dein Ding.
Jörg E. schrieb: > Ein T. schrieb: >> leider froren die VMs dabei in unregelmäßigen >> Abständen ein. > > Das war evtl KVM libvirt geschuldet. Was es aber schon seit ein paar > Jahren nicht mehr macht… Möglich, das kann ich nicht beurteilen. Aktuell investiere ich unsere Zeit lieber in die Migration auf einen Docker Swarm Cluster.
(prx) A. K. schrieb: > Ein T. schrieb: >> Proxmox rate ich mittlerweile ab. > > Wenn Proxmox ernste Problem hat, werden wir davon in den nächsten > Monaten sicherlich hören. Das ist immerhin einer der meistgenannten > Kandidaten bei der Flucht aus VMware im Enterprise-Umfeld. Keine Ahnung, ob es an KVM/Qemu, libvirt, oder an der veralteten Version von Proxmox lag, die unser Hostingprovider zur Verfügung gestellt hat. Aber die Probleme, die ich weder mit libvirt, noch mit KVM/Qemu je auf der CLI erlebt habe, haben mein Vertrauen in Proxmox recht gründlich erschüttert. Insofern wünsche ich Dir bzw. Euch viel Glück! Davon abgesehen halte ich es aber auch für... schwierig, einfach komplette Images von VMs zu ziehen. Einerseits wegen der Konsistenz und andererseits, weil das recht viel Speicherplatz erfordert...
Ein T. schrieb: > Davon abgesehen halte ich es aber auch für... schwierig, einfach > komplette Images von VMs zu ziehen. Einerseits wegen der Konsistenz und > andererseits, weil das recht viel Speicherplatz erfordert... Das hängt davon ab, wie du das darunterliegende zfs einbindest. Anscheinend geht es aber um Dateien. Also sollte selbst ein Export des ZFS pools von truenas in die VM rein genügen... Aber man kann ja auch Zfs direkt unter Ubuntu nutzen... Ich wollte keinen Glaubenskrieg lostreten. Zfs hätte jedenfalls fertige Tools zur Replikation und wäre als Dateisystem für diese Anwendungsfälle gemacht. Es hat aber auch Nachteile ZFS zu nutzen... vergrößern eine volumes ist z B nicht immer zufriedenstellend möglich, wenn man Redundanz von Dateisystem fordert. Ich bin jedenfalls von allen "Backup Lösungen" weg... Datenbanken aufs FS syncen, snapshot erstellen, weg replizieren und gut ist's (für meine Bedürfnisse). 73
Ein T. schrieb: > Davon abgesehen halte ich es aber auch für... schwierig, einfach > komplette Images von VMs zu ziehen. Einerseits wegen der Konsistenz und > andererseits, weil das recht viel Speicherplatz erfordert... Es gibt ja Tools die deduplizieren und komprimieren können :-)
hallo, danke erst mal für die vielen guten Tipps. Da lese ich mich so nach und nach durch :-) Zum Hintergrund: Es geht um einen Ubuntu Server, auf dem ich Docker-Container betreiben möchte. Die Daten-Verzeichnisse der Container möchte ich dann regelmäßig auf eine andere Maschine sichern. Als Speichermedium kommt ein ZFS-Mirror zum Einsatz (zwei SSDs).
G. K. schrieb: > Es gibt ja Tools die deduplizieren und komprimieren können :-) Und das völlig transparent im Rahmen des Filesystems. Bei Snapshots ergibt sich eine erste Deduplizierung dann bereits im Copy-on-Write Verfahren und eine Replikation nur der Änderungen ergibt sich ebenfalls ziemlich zwanglos, ohne Suche oder Vergleich.
Bernd schrieb: > Zum Hintergrund: > Es geht um einen Ubuntu Server, auf dem ich Docker-Container betreiben > möchte. Da würde ich mir das aber wirklich 2x überlegen, ob ich dafür wirklich einen eigenen Server aufsetzen will: https://www.truenas.com/docs/scale/22.12/scaletutorials/apps/docker/ https://pve.proxmox.com/pve-docs/pve-admin-guide.html#chapter_pct Die komplette Datenhaltung in der "NAS-distribution" zu lassen, hat schon Vorteile (siehe logging, email benachrichtigung, regelmäßiges scrubbing,...). Bernd schrieb: > Als Speichermedium kommt ein > ZFS-Mirror zum Einsatz (zwei SSDs). Das würde ich mir auch gut überlegen. Ein RaidZ kannst du zumindest über ein Zwischenschritte erweitern (also platte tauschen und resilvern). Mit einem Mirror startest du von einem System, das zwar fehler erkennt, aber nicht korrigieren kann... Hängt halt von der Datenmenge ab... bei mir rennt ein RaidZ2 auf 4 SSDs weil ich vergleichsweise wenig daten habe und der preis (für mich) damit 2. rangig ist. Dafür ist die verfügbarkeit höher. Mir ist eine der NAS HDDs in einem anderen RaidZ2 kaputt gegangen... ja, es ist degeneriert, aber immer noch redundant und verfügbar. Ist halt wie immer eine Kosten-Nutzen-Rechnung die man für sich selber machen muss... 73
:
Bearbeitet durch User
Hans W. schrieb: > Die komplette Datenhaltung in der "NAS-distribution" zu lassen, hat > schon Vorteile (siehe logging, email benachrichtigung, regelmäßiges > scrubbing,...). Proxmox würde ich als Unterbau nutzen. Darauf dann eine VM mit Ubuntu Server, um die Docker Container auszuführen. Meine SSDs würde ich per Passthrough direkt der VM zur Verfügung stellen. TrueNAS habe ich mir als Alternative zu Ubuntu Server auch schon angesehen, aber da scheint die Docker-Integration eine Katastrophe zu sein. Hat mir wenig Spaß gemacht ;-) OpenMediaVault wäre ggf. auch noch eine Option... Hans W. schrieb: > Ein RaidZ kannst du zumindest über ein Zwischenschritte erweitern (also > platte tauschen und resilvern). Mit einem Mirror startest du von einem > System, das zwar fehler erkennt, aber nicht korrigieren kann... RaidZ sagt mir erst mal nichts. Mein Mini-PC hat leider nur zwei SATA-Ports, daher muss ich erst mal mit zwei Daten-SSDs auskommen. Da ist ein ZFS-Mirror vermutlich die einzige Option?
Bernd schrieb: > Proxmox würde ich als Unterbau nutzen. Darauf dann eine VM mit Ubuntu > Server, um die Docker Container auszuführen. Meine SSDs würde ich per > Passthrough direkt der VM zur Verfügung stellen. Bitte entschuldige, aber warum möchtest Du erst eine Abstraktionsschicht wie Proxmox einziehen und dann weitere Aufwände für einen Passthrough betreiben, der ohne diese Abstraktionsschicht gar nicht benötigt würde? Anders gefragt: welchen Nutzen versprichst Du Dir in Deinem Anwendungsfall von Proxmox?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.