Wie am besten hohes Datenaufkommen sichern?

N

NicoDeluxe

New Member
Hallo zusammen,

eine Frage; ich hab mehrere Server auf denen viele User Daten hosten.

Welche Möglichkeiten gibt es um hohes Volumen schnell zu sichern? Sind ca 60 mio Dateien mit tar.gz brauch ich da nicht anfangen, dauert ewig.

Danke und Gruß

Edit: Handelt sich um Debian-Systeme, die darauf befindlichen Datenbanken sollten auch gesichert werden.
Unter windows habe ich mal ein Script gehabt, dass nur veränderte Dateien gesichert hat. Aso beim ersten Durchlauf alle und dann nur noch geänderte/neue/gelöschte. Gibts sowas vielleicht schon fertig für Linux?
 
Last edited by a moderator:
Gern genommen wird auch ein Filesystem-Snapshot, den man dann in Ruhe auf einen ded. Backup-Server kopieren kann.

Für Datenbanken aber nicht so 100% geeignet (außer man weiß sehr genau, was man tut) - da bietet sich der schnöde SQL-Dump an.
 
Guter Einwand marce!

Klar ist: Datenbanken brauchen ne Extrawurst. Datenbankdateien sichern ist -normalerweise- nicht möglich!
 
mit rsync muss man auch aufpassen - da kommt's sehr auf die Änderungsfrequenz der Dateien und die Verteilung an. Je nach dem braucht rsync schon einiges an Ressourcen und ist dann auch nicht mehr so wirklich perfomant - vor allem, wenn man dann auch noch parallel nicht gerade das Netwerk dicht machen will.

Aber die Thematik Backup- und Restore-Konzept ist ja generell nicht trivial. Vor allem, wenn man das auf eine Infrastruktur "draufsetzen" will, auf der man beim Einrichten daran noch keinen einzigen Gedanken verschwendet hat.
 
ThomasChr said:
Datenbankdateien sichern ist -normalerweise- nicht möglich!
Click to expand...
Mit temporären Write-Locks schon, wobei ich das trotzdem nicht empfehlen würde, weil man dann sehr oft die exakt gleiche Version der Software braucht! :)

Diesen Hinweis kann man natürlich auch für viele andere Dienste übernehmen. Maildirs sind z.B. auch so ein Beispiel, die ich nicht direkt sichern würde, wenn dazwischen die Gefahr besteht, dass sie sich ändern.

marce said:
Je nach dem braucht rsync schon einiges an Ressourcen und ist dann auch nicht mehr so wirklich perfomant - vor allem, wenn man dann auch noch parallel nicht gerade das Netwerk dicht machen will.
Click to expand...
Genau dafür gibt es nice und ionice sowie natürlich die Bandbreitenbeschränkung von rsync selbst… ;)

So ganz allgemein würde ich schon sagen, dass rsync der Beste Kandidat für diese Aufgabe ist (außer für die Datenbanken!), wenn man nicht auf FS-Snapshots setzen kann oder möchte.


MfG Christian
 
natürlich kann man rsync entsprechend kastrieren / einschränken - aber dann fällt meist auch das Feature "schnell" weg. Und der hohe RAM-Bedarf für das Erstellen der Dateiliste bleibt AFAIK auch erhalten.

... und 60 Mio Dateien sind einfach eine Hausnummer. Je nach Datenstruktur macht das einfach kein Spaß - mit oder ohne rsync.
 
Was heißt "hoher" Rambedarf?
256MB? 5GB? 100GB?

IMO sind mir solche Aussagen immer viel zu schwammig, denn ob der Speicherbedarf (noch) akzeptabel ist oder nicht hängt davon ab, wovon man konkret spricht (wie viel Speicher hat das System, wie viel wird konkret verwendet, wie viel würde rsync verwenden).

Platzkomplexität KANN also ein Argument sein, muss es aber nicht.

Snapshots gehen ja auch nicht immer: ext4 ohne lvm (nicht unbedingt selten anzutreffen, gerade bei diversen Hosterimages).
Und ja, da könnte man auf btrfs konvertieren aber da ist dann wiederum wichtig, welche Version der Kernel hat.

Aber ja, ich persönlich würde auch snapshots bevorzugen. Ich will damit nur sagen, dass rsync sehr wohl seine Berechtigung hat und mir pauschale Aussagen wie "langsam, braucht viel Speicher" relativ nutzlos vorkommen.
 
klar, Pauschalaussagen helfen keinem - ich habe ja auch nie gesagt "rsync ist doof und taugt nichts" (warum auch, dafür nutze ich das Ding selbst viel zu gern und oft)

Aber konkret: Wir hatten hier ein kleines Serverchen, auf dem ca. 10Mio kleine Bilder mit in Summe ca. 4TB lagen - der rsync brauchte für den Aufbau der Dateiliste > 4GB Speicher und ca. 2h Zeit - erst dann begann die Übertragung der Deltas.

Was ich nur anregen möchte: Idealerweise macht man sich eben vorher Gedanken um ein Backupkonzept und richtet seine System darauf aus. Eben z.B. mit Filesystemen, die Snapshots erlauben. Oder Storage-Systemen, die das können. Oder man legt die Daten so ab, daß man nicht immer den kompletten Bestand abgleichen muss, ... oder ... oder ... oder ...
... und evtl. muss man halt dann auch ein bestehendes System mal umkrempeln...
 
marce said:
Und der hohe RAM-Bedarf für das Erstellen der Dateiliste bleibt AFAIK auch erhalten.
Click to expand...
Das stimmt natürlich. Wenn aber keine Hardlinks darin vorkommen, oder nur in spezieller Struktur, kann man es auch problemlos in kleinere Aufgaben unterteilen. Das mache ich bei einem Backuptask mit mehr als 12 Millionen Dateien z.B. so.


MfG Christian
 
wenn die Struktur es zulässt klar - leider geht das nicht immer (oder die Jobs weden dann so komplex zu erstellen wenn man es automatisch machen will) daß im Endeffekt auch nicht viel gewonnen ist :-)
 
Dann liefere bitte mal ein paar mehr Fakten bzw. relevante Infos:
* wie viele Server
* wohin und wie soll gesichert werden
* VServer oder ded. Hardware
* Wie viele Daten / Dateien pro Server
* Anbindung (ggf. auch sind mehr als eine Netwerkkarte verfügbar)
* Dateisystem der Server
...

oder probier es einfach mit rsync und lass Dich überraschen.
 
Hallo,
ich hol das nochmal hoch. Wie kann ich mit rsync nur geänderte Dateien updaten?

Derzeit mache ich mit
rsync -az / /backup
ein Backup (dabei backt sich der Ornder backup übrigens selber mit)


wie den Gesamten Server (/) mit rsync nach /backup sichern, dies möglichst per cron und nur geänderte datein update, hinzufügen
 
NicoDeluxe said:
Hallo,
ich hol das nochmal hoch. Wie kann ich mit rsync nur geänderte Dateien updaten?
Click to expand...

Wenn ich das richtig im Kopf habe ist es

Code: 
rsync -az --update / /backup

Ich steige hier mal mit ein. rsync ist schon nicht Schlecht.
Mich Interessiert noch wie das mit den Datenbanken und User gelöst wurde?

Viele Webspace Anbieter bieten ja Backups an zu xx Tage rückwirkend, die der Hoster ohne weiteres Einspielen kann.

Welche Technik steckt da hinter den auf Hosting Server wird ja nicht alle xx Stunden MySQL gestoppt um das Backup zu erstellen.
 
Werner S said:
Mich Interessiert noch wie das mit den Datenbanken und User gelöst wurde?

Viele Webspace Anbieter bieten ja Backups an zu xx Tage rückwirkend, die der Hoster ohne weiteres Einspielen kann.

Welche Technik steckt da hinter den auf Hosting Server wird ja nicht alle xx Stunden MySQL gestoppt um das Backup zu erstellen.
Click to expand...

Bezüglich der Sicherung von SQL-Datenbanken gibt es mehrere Ansätze (betrifft nicht nur MySQL). Zum einen kannst du einen Dump erstellen (also im Prinzip in SQL-Dateien exportieren) und diese Dateien dann sichern. Je nach verwendeter Backup-Lösung gibt es auch speziellen Sicherungs-Agents, über die die Datenbanken sich sichern lassen. Oder du replizierst die Datenbanken zwischen zwei Servern bzw. nutzt Cluster-Techniken, dann kannst du ggfl. einen von beiden Servern zum Sichern kurz offline nehmen. Außerdem gibt es noch Snapshot-Techniken, die von einigen Betriebssystemen oder Virtualisierungslösungen angeboten werden, mit denen sich ebenfalls brauchbare Backups erstellen lassen.
 
Ok soweit habe ich das Verstanden und für Private Lösungen auch ganz ok.
Wie sieht das ganze im Professionellen Bereich aus.

Als Beispiel: 20 Hostsysteme mit Plesk und I-MSCP, auf jedem laufen zwischen 20 und 150 Kunden.
Wie sichert man sowas damit der Hoster nach einem Rauchenden Server wieder alles einspielen kann.
 
je nach verwendeter Backend-Technologie - kann man da z.B. Snapshots direkt auf dem Filer erstellen lassen, Filesystem-Snaphots machen, VM-Snapshots, ...
 
You must log in or register to reply here.
Back
Top