Hallo Fabian!
Komprimieren frisst eigentlich nicht viel Übertragungskapazität (zumindest solange die CPU nicht sehr, sehr schnell und die HDs sehr, sehr langsam sind) - kann aber störend sein, wenn die laufenden VMs oft auf die HD zugreifen und die HD dann ständig seekt statt hohe Datenraten zu liefern.
Eigentlich ist Nachts alles im Leerlauf, solange keine Cronjobs dazwischenfunken sollten die Platten auschließlich mit dem Backup beschäftigt sein.
Hab ich schon erlebt. Platte in Rechner A fängt an zu sterben. Besitzer von A schaufelt all seine Daten auf die HD von Freund B. Einen Tag später hatten sie beide keine Daten mehr. Ist statistisch unwahrscheinlich, aber möglich.
Ja, soll vorkommen, zumal ja dann beide Platten ordentlich zu schuften haben. Ist gar nicht so selten, passiert öfter an RAID5: wenn die Hotspare einspringt, gibt manchmal auch noch eine zweite RAID-Platte während des Rebuild auf. Für ganz vorsichtige gibt's dann ja noch RAID6. ;-)
Vom Prozessor her sollten beide Kisten _locker_ 100 MBit schaffen. Sowas ist eigentlich ein Zeichen für minderwertige Ethernetchipsätze (oft onboard, habe selbst Realtek als PCI-Karte, frisst viel CPU, z.B. Intelkarten sind zwar teurer, hier auch spürbar besser). Frage ist natürlich, ob eine Verbesserung d. Ethernetspeeds ggf. neue Karten überhaupt wert wäre. (Noch ein Gedanke: Miss mal mit "schnellen Rechnern", ob die Route 100 MBit überhaupt hergibt - ist evtl. ein Router noch mit anderen Sachen beschäftigt und daher klemmt es dort?)
Hab's jetzt mal wissen wollen: Eine Seite: backup:~# nc -l -p 9000 | dd of=/dev/zero Andere Seite: root@xen:~ # dd if=/dev/zero bs=1M count=1024 | nc backup 9000 hat 91 Sekunden gedauert, was 11,25 MB/s "Rohdurchsatz" ergibt. Die Strippe ist also besser, als ich dachte. Auf der einen Seite (Host Xen) arbeitet ein e100 (onboard), auf der anderen (Host Backup) ein 8139cp (onboard). Allerdings habe ich auch schon die Erfahrung gemacht, dass Intel-Karten an schlechten Verkabelungen schwächeln (zyklische Meldung: "Netzwerkkabel wurde entfernt" unter Windoof und misester Durchsatz), ein schnöder nforce2-onboard Chip aber problemlos läuft. Die CPU-Belastung ist natürlich weit geringer mit Intel-Chipsatz, keine Frage. Werde mal bei Gelegenheit mit einem Intel-Chipsatz auf beiden Seiten probieren, aber der Aufwand ist immer doof: Rechner abbauen, hochtragen, anschließen, dann das ganze vice versa und vielleicht nochmal von vorn, weil was vergessen ;-). Das Ding läuft nämlich "Headless", da geht nur Strom und Ethernet rein.
Da mir das komprimieren zu lange dauert und ich ausreichend große HDs habe mache ich es mir einfach und komprimiere sie gar nicht. Das macht auch das Onlinebackup via rsync erst sinnvoll möglich. (Außer halbjährlich fürs DVD-Backup, aber auch da unternehme ich bisher nichts gegen das "Wachstum durch Gelöschtes" - deinen Tipp zum "Vollnullen" werde ich dafür übernehmen, auf die Idee bin ich noch nicht gekommen, besten Dank)
Wenn aber gerade in dem Moment, da dd die letzen Bytes belegt, von irgendeinem Prozess auch Speicherplatz angefordert wird, geht das in die Hose, daher gefällt mir das noch nicht so richtig. Ich probiere gerade, mein Backup-Script folgendermaßen umzuschreiben:
1. Ein neuer Container in der Größe des alten wird mittels dd aus /dev/zero neu angelegt 2. VM wird heruntergefahren 3. altes und neues FS werden gemountet 4. Daten werden mittels cpio von alt nach neu kopiert 5. altes und neues FS werden ausgehangen 6. VM wird wieder gestartet 7. Neues FS wird in tar.gz komprimiert
Allerdings finde ich das ziemlich mit heißer Nadel gestrickt, werde das mal vorsichtig antesten, eventuell für eine Übergangszeit alle Files mit md5sum prüfen, bzw. eine rekursives diff laufen lassen, mal sehen In dem Zusammenhang eine Script-Frage: wie bekomme ich die Größe der alten Container-Datei so raus, dass ich sie als "count="-Parameter an dd übergeben kann?
Danke schon im Voraus, jetzt aber erst mal:
Frohe Weihnachten!
MfG Thomas