Schon mal was von rsnapshot und ähnlichen Backup-Programmen gehört?
Die arbeiten alle mit Hardlinks damit du unzählige Snapshots grosser Datenmengen auf ein Storage bekommst und nicht veränderte Dateien einfach durch Hardlinks "dargestellt" werden
Je nach Anzahl der Snapshots und Einsatzzweck des Backup-Storage/Archivs kann das durhcaus interessant sein (Daily-Snapshots über einen sehr langen Zeitraum + wöchnetliche + monatliche + järhliche)
Ja ich fhare sowas weil solange am Backup-Server > 2 TB frei sind gibt es keinen Grund die Anzahl der Sicherungen zu reduzieren
Zumal es auch Backuplösungen gibt, welche nicht auf Hardlinks setzen, was meiner Meinung nach sogar die bessere Variante ist. (Wenn man die Backups z.B. verschieben will kann das Probleme geben, je nach Implementation.)
Grundsätzlich hast du natürlich recht. Nur hilft einem das bei einer FS-Migration nicht. Denn man bekommt die Daten nicht auf ein btrfs kopiert. Bzw wäre interessant, was bei einer Konvertierung passiert...
WIEVIELE rsync-Backups eines BTRFS-Snapthots kannst du denn auf dem Backup-Server so machen und wieviel Platz braucht eine Backup-Version? Denk mal nach? Kommst du nicht drauf? Den VOLLEN Platz verflucht nochmal!
Die Hardlinks sind am BACKUP-SERVER du Wahnsinniger und sorgen dafür dass du eben unzählige Versionsstände auf selbigem haben kannst. Kopierst du einen BTRFS-Snapshot per rsync braucht jede Version auf der gegenseite den vollen Platz
__________________________
Abgesehen davon wer hat dir eigentlich erzählt dass Hardlinks mit rsync nicht überragen werden können? Das ist doch einfach alles nur Bullshit was ihr heir von euch gebt weil wenn dem so wäre müsstest du bei mir vorbeikommen und meinem Homeserver und Office-Rechner erzählen dass das was sie seit langem machen nämlich die gegenseitigen rsnapshot-Backups per rsync geegnseitig abzugleichen um auf jedem Rechner den vollen Versionsstand des anderen zu haben gar nicht geht
rsync --help | grep link socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace, -l, --links copy symlinks as symlinks -L, --copy-links transform symlink into referent file/dir --copy-unsafe-links only "unsafe" symlinks are transformed --safe-links ignore symlinks that point outside the source tree -k, --copy-dirlinks transform symlink to a dir into referent dir -K, --keep-dirlinks treat symlinked dir on receiver as dir -H, --hard-links preserve hard links --link-dest=DIR hardlink to files in DIR when unchanged
Hardlinks funktionieren nicht über Dateisystemgrenzen hinweg. Wenn du sie auf den Sicherungsserver überträgst dann musst du die Ganze Datei übertragen. Sie kann dann auf dem Sicherungsserver wieder als Hardlink repräsentiert werden.
> Hardlinks funktionieren nicht über Dateisystemgrenzen hinweg. > Wenn du sie auf den Sicherungsserver überträgst dann musst du > die Ganze Datei übertragen.
Das ist doch Schwachsinn Informiere dich wie rsync arbeitet
Da läuft auf beiden Seiten ein rsync-Prozess und beide sprechen miteinander per SSH und da muss niemand eine ganze Datei übertragen weil eine Instanz zur anderen einfach sagt "Mach hardlink A nach B" genauso wie rsync so gut wie nie Dateien komplett überträgt wenn sie nicht komplett neu sind (Wie gesagt: Informiere dich wie es arbeitet, ich werde nicht dafür bezhalt Leuten hier Basics zu erklären)
Was wusstest du? Dass ich daheim und im Büro auch einen Rechner habe?
Ja und weiter? Ändert nichts daran dass ich auch für die restliche Tecnnik inkl. Backup und Security zuständig bin, in den letzten 15 Jahren keinen einzigen Datenverlust zu verantworten habe und wir reden hier von etwa 300.000 Euro Umsatz der über die Infarstruktur am Tag generiert wird
Rufe rsync mit --inplace auf und auf dem btrfs werden, dank COW, nur die veränderten Blöcke gespeichert, d.h. du sparst sogar noch Speicher gegenüber einem Hardlink und hast nicht das Problem der Hardlinks, das wenn aus irgendeinem Grund eine Datei verändert wird, alle im Eimer sind.
Wenn die Datei beim ersten Backup kaputt ist dann ist das eben so Die ist aber dann auch bei jeder anderen Sicherungsvarianten zu dem zeitpunkt kaputt, das hat aber nichts mit dem Thema zu tun
Natürlich ist rsnapshot ein Backup Jeder vernünftige Mensch macht das auf Remote-Rechnern
Hier helfen dir keine Dateisystemsnapshots und sonst was
Es geht einfach darum EINE Vollsucherung verschlüsselt und mit komprimierter Übertragung auf eine physisch getrennte Location zu machen und da mehrere Versionsstände zu haben ohne für unveränderte Dateien mehrfach Platz zu beansprucehn - Und ja es gibt kaum was affetiveres als rsync über SSH auf WAN-Strecken
Das da unten sind Traffic-Summarys eines Backupservers der täglich etwa 2 TB an Daten abgleicht, Abgleich über 100 Mbit etwa 15 Minuten und ranspshot dann am Backup-Server täglich etwa 20 Minuten
Von Sie haben vergessen, Ihren Nam am Fr, 8. Juni 2012 um 21:50 #
> Es geht einfach darum EINE Vollsucherung verschlüsselt und mit komprimierter > Übertragung auf eine physisch getrennte Location zu machen und da mehrere > Versionsstände zu haben ohne für unveränderte Dateien mehrfach Platz zu > beansprucehn - Und ja es gibt kaum was affetiveres als rsync über SSH auf > WAN-Strecken
Jedes ordentliche Backupprogramm kann inkrementelle bzw. differentielle Backups.
Auf ein rsync Backup kann ich mit jedem sftp-Client auf jeden Versiionsstand jeder einzelnen Datei binnen Sekunden zugreifen - Zeig mir das bei anderen Lösungen
Von Sie haben vergessen, Ihren Nam am Sa, 9. Juni 2012 um 11:13 #
Das ist nicht der Sinn eines Backups. Ein Backup brauche ich für größere Ausfälle (mehrere Platten defekt, defektes Dateisystem o.ä.). Um einzelne Dateien die der Benutzer versehentlich gelöscht oder überschrieben hat wiederherzustellen gibt es Dateisystemsnapshots. Die kann man auch mal stündlich machen.
Was für DICH Sinn eines Backups ist interessiert eigentlich niemanden wirklich Für den Rest der Welt ist Sinn eines Backups bei Datenverlust selbige MÖGLICHST SCHNELL wiederherstellen zu können womit dein band schon mal weg fäkkt - Oder wie lange brauchst du um darauf einen Ordner in der Version vom 07.12.2011 zu finden und gezielt wieder herzustellen?
Abgesehend avon solltest du langsam kapieren dass das Thema NICHT welche Arten von Backups es gibt und wie geil du welche findest ist sondern die Frage war schlicht und ergreifend wozu man mehr als 253 Hardlinks BRAUCHEN HÄNNTE (Nicht wofür DU sie braucehn könntest) und die habe ich beantwortet
Von Sie haben vergessen, Ihren Nam am Sa, 9. Juni 2012 um 13:01 #
Warum diskutierst du dann eigentlich mit, wenn's doch am Thema vorbei geht. Zumal das Thema nicht lautet "...Hardlinks...", sondern "Btrfs-Hauptentwickler verlässt Oracle"
> Eine Datei mit 253 Hardlinks versehen? Wozu braucht man das???
Die restliche Diskussion kommt von typen wie dir die nicht verstehen dass es ausser ihrer Welt auch noch was gibt und dass es keine Rolle sielt was DU gut findest - Das ist EIN Einsatzzwekcj von 253 Hardlinks, Frage beantwortet
> Dateisystemsnapshots. Die kann man auch mal stündlich machen
Dafür solltest du dir eigentlich einen anderen Job suchen
Du willst also in der Produktivumgebung auf einem sündteuren SAN das als Shared Storage für einen VMware Cluster dient stündlich FS-Snapshots machen anstatt diese Sicherungen isoliert von der Nutzlast und auf deutlich günstigerem Storage zu machen?
Probier das mal in einer Firma wo Leute noch einen Überblick haben was die Techniker so machen und du wirst die längste Zeit einen Job dein eigen genannt haben
Von Sie haben vergessen, Ihren Nam am Fr, 8. Juni 2012 um 21:54 #
Weitere Nachteile der Hardlink-Methode: - Setzt auf Zielseite ein Unixdateisystem voraus. - Änderungen der Zugriffsrechte etc. können nicht nachvollzogen werden, es sei denn man speichert sie separat. - Keine Komprimierte Speicherung möglich.
Von Sie haben vergessen, Ihren Nam am Sa, 9. Juni 2012 um 11:18 #
Im Wort "Unixdateisystem" steckt nicht nur "Unix" sondern auch "Dateisystem". Schon mal ein rsync-"Backup" auf Band gemacht? Und ja, Bänder sind fern vom Heimanwender immernoch das Mittel der Wahl. Dass dich das mit deinem 2-TB-Spielzeugserver nicht interessiert mag sein.
> Dass dich das mit deinem 2-TB-Spielzeugserver nicht interessiert mag sein
Du bist doch wirklich lächerlich
Also für dich ist alles was keine zig TB Daten hat ein Spielzeugserver? Was machen denn deine vielen TB den ganzen Tag?
Eine kleine VM mit 10 GB erwirtschaftet hier für einen Kunden etwa 60.000 Euro am Vormittag - Soviel zum Thema Spielzeug, nur weil ihr hirntot Datenmengen produziert ist nicht alles andere was effektiv arbeitet Spielzeug
Auf ein TB bekomme ich alle Server mit Ausnahme des Fileservers locker unter und hier sind Bandsicherungen völlig irrelevant weil wenn sie gebraucht werden muss selektiver und schneller Zugriff darauf bestehen
Aber was erzähle ich das jemanden der nur seine Datenhalde kennt und noch nie Dienste betrieben hat wo tausende Kunden zeitgleich Daten aktuell lesen und schreiben und du nicht erst im Fehlerfall einen halben >Tag suchen oder gleuich die ganze Bude umbringen kannst weil du in geistuger Umnachtung ein Vollbackup zurückspielst das auch alle andern zurückbombt
Wird das nun ein Schwanzvergleich? Wer in der größten Firma arbeitet, wer am meisten erwirtschaftet? Sind unsere Egos wirklich so klein?
Es ist das Internetz hier. Niemand gibt etwas darauf was der andere vorgibt zu sein. Aber was weiß ich schon. Schließlich bin ich erst 12 und besuche die Abendschule in einer geschlossenen Anstalt. Ich bin ja wahnsinnig.
Frag das doch die Pfeife der was von "2-TB-Spielzeugserver" hinausrülpst und meint alle die nicht genauso hirnlos wie seine Firma mit Storage agieren betreiben nur Spielzeug
Von Sie haben vergessen, Ihren Nam am Sa, 9. Juni 2012 um 13:23 #
Entscheide dich: Sündteures SAN-Storage oder ein paar TB Daten?
Und wo liegen die Daten?
A) In der VM? -> du sicherst täglich GB-große VM-Images mit rsync? No-go B) Auf dem Fileserver? -> Dann ist es egal ob VM oder nicht. Aber hauptsache VM wird erwähnt. Das wirkt immer professionell. Ich drifte schon wieder(?) ab.
> Entscheide dich: Sündteures SAN-Storage oder ein paar TB Daten?
Ach beides gibts bei euch nicht?
Schon mal was davon gehört dass ein SAN-Storage mehrere LUN hab kann wo dahinter unterschielidliche RAID-Level mit unterschieldlicen Disks arbeiten?
> Und wo liegen die Daten?
> A) In der VM? -> du sicherst täglich GB-große > VM-Images mit rsync? No-go
Wozu sollte ich die Images mit rsync sichern Für die VMs selbst gibt es VMware Data Recovery
rsnapshot-Backups sichern Daten aus den VMs raus
> B) Auf dem Fileserver? -> Dann ist es egal ob VM oder nicht. > Aber hauptsache VM wird erwähnt. Das wirkt immer professionell
Hier hast du was zu lesen http://www.vmware.com/de/products/datacenter-virtualization/data-recovery/overview
Damit du kapierst dass es etwas mehr als deine kleine Welt gibt und vielleicht verstehst du irgendwann auch dass profesionell arbeitende Techniker MEHERER Backup-Strategien gleichzeitig fahren weil du auch je nach Art der Beschädigung ein völlig anderes Recovery-Szenario brauchst
Aber du würdest vermutlich wenn jemand einen Ordner killt die kompeltte VM aus dem Backup zurückblasen und bezüglich der andern damit verlorenen daten nur mit der Schulter zucken
Von Sie haben vergessen, Ihren Nam am Sa, 9. Juni 2012 um 18:43 #
> Damit du kapierst dass es etwas mehr als deine kleine Welt gibt und > vielleicht verstehst du irgendwann auch dass profesionell arbeitende > Techniker MEHERER Backup-Strategien gleichzeitig fahren weil du auch > je nach Art der Beschädigung ein völlig anderes Recovery-Szenario > brauchst
Habe ich das bestritten? -->
> Aber du würdest vermutlich wenn jemand einen Ordner killt die > kompeltte VM aus dem Backup zurückblasen und bezüglich der > andern damit verlorenen daten nur mit der Schulter zucken
Wenn jemand einen Ordner killt, kann dieser jemand ihn per FS-Snapshot zurückspielen, ohne dass der Admin davon was mitbekommt. So muss das "normale" Backup praktisch nur noch bei defektem RAID, FS, o.ä. einspringen, oder wenn die gewünschte Version nicht mehr vom FS-Snapshot abgedeckt ist.
Dieser jemand hat aber üblicherweise keinen Zugriff auf Backups weil nur Idioten in einem Snapshot oder einer lokalen Kopie oder gar in einem RAID ein Backup sehen
Was bringt mir ein Snapshot auf einem komprommitierten Server? Das Backup hat in jedem Fall auf einer eigenen und isolierten Maschine zu liegen
Von Sie haben vergessen, Ihren Nam am Sa, 9. Juni 2012 um 23:05 #
Willst du es nicht verstehen?
Wenn - mehr Platten kaputt gehen als das RAID verkraftet - das Dateisystem beschädigt wird - der Server kompromittiert wird - die Bude abbrennt etc. - ... dann spielt der Admin das (ggf. Offsite-)Backup zurück.
Wenn - ein Benutzer eine Datei löscht/überschreibt/... dann holt sich dieser Benutzer einen Snapshot.
Wenn du zum Abschluss noch einen konstruktiven Beitrag machen willst, schreibst du jetzt noch die ungefähren Häufigkeiten der obigen Ereignisse hinzu, sowie den Aufwand fürs Wiederherstellen. Wenn du dann den Sinn von Snapshots nicht siehst (und verstehst dass es sich lohnt dafür auch Kapazität bereitzustellen), solltest _du_ dir einen anderen Job suchen.
> mehr Platten kaputt gehen als das RAID verkraftet
Hast du im Normalfall grob was falsch gemacht
> das Dateisystem beschädigt wird
Vom SAn-Storage Eher unwahrscheinlich Aber genau dafür gibt es Backups
> der Server kompromittiert wird
Hilft dir auch kein Snapshot
> die Bude abbrennt etc.
Genau dafür gibt es Backups
> dann spielt der Admin das (ggf. Offsite-)Backup zurück.
Eben - Einmal alle 20 Jahre
> - ein Benutzer eine Datei löscht/überschreibt/...
Ist er ein Idiot
> dann holt sich dieser Benutzer einen Snapshot.
Nö, dann geht er einen Raum weiter und ICH hole das Backup zurück Wenn ich Urkaub habe sitzt der Kollege da
> Wenn du dann den Sinn von Snapshots nicht siehst (und > verstehst dass es sich lohnt dafür auch Kapazität bereitzustellen), > solltest _du_ dir einen anderen Job suchen
Kein normaler Mensch lässt in einer komplett virtualisierten Umgebung in den Gästen Snapshots permanent laufen. Auf Snapshots im SAN hat kein user Zugriff und die sind auch nur ganz ganz selten sinnvoll für ein Recovery weil du damit auch sämtliche VM's zurückbombst
Nochaml: Wer heute noch Server Bare-Metal installiert ist ein Dummkopf
>> mehr Platten kaputt gehen als das RAID verkraftet > Hast du im Normalfall grob was falsch gemacht
Leider liegen manche Crashs nichtmal an den Platten selbst, dann nimmt irgend eine andere Komponente wegen einem elektrischen Defekt einige Platten mit. Oder die USVs springen nicht rechtzeitig an, die klima streikt, ... . Leider kann man sich nicht gegen alles so absichern, dass es wirtschaftlich bleibt.
>> das Dateisystem beschädigt wird
>Vom SAn-Storage >Eher unwahrscheinlich >Aber genau dafür gibt es Backups
Eine SAN ist auch nur eine Blackbox, der man nicht allzu sehr vertrauen schenken sollte. Auch eine Branchengrößen wie Strato hatte da mal Ärger mit.
> Nochaml: Wer heute noch Server Bare-Metal installiert ist ein Dummkopf
Ich würde mal die Handlungsweisen von anderen nicht als dumm bezeichnen, nur weil diese eine andere Vorgehensweise haben. Nicht alles, was für den einen Sinnvoll ist, ist bei dema anderen auch Praxistauglich.
Die eigentliche Frage ist doch, fern von irgendwelchen Szenarios und Papierdaten. Wie brauchbar ist btrfs bereits für die Praxis, oder welche Showstopper gibt es, die einem früher oder Später gewaltig auf die Füße fallen können. ext3/4+LVM ist Praxiserprobt und funktioniert. btrfs kann da noch so manche böse Überraschung beinhalten, manches liest man auch schon in einzelnen Foren.
Eine Datei mit 253 Hardlinks versehen? Wozu braucht man das???
Schon mal was von rsnapshot und ähnlichen Backup-Programmen gehört?
Die arbeiten alle mit Hardlinks damit du unzählige Snapshots grosser Datenmengen auf ein Storage bekommst und nicht veränderte Dateien einfach durch Hardlinks "dargestellt" werden
Je nach Anzahl der Snapshots und Einsatzzweck des Backup-Storage/Archivs kann das durhcaus interessant sein (Daily-Snapshots über einen sehr langen Zeitraum + wöchnetliche + monatliche + järhliche)
Ja ich fhare sowas weil solange am Backup-Server > 2 TB frei sind gibt es keinen Grund die Anzahl der Sicherungen zu reduzieren
Da Btrfs selbst Schnappschüsse in seiner Funktionsliste hat braucht es für den Zweck einer Datensicherung wohl keine Hardlinks.
Zumal es auch Backuplösungen gibt, welche nicht auf Hardlinks setzen, was meiner Meinung nach sogar die bessere Variante ist. (Wenn man die Backups z.B. verschieben will kann das Probleme geben, je nach Implementation.)
Und bei Hunderttausenden oder gar Millionen von Dateien sind Hardlinks auch nicht besonders effizient, v.a. wenn das Ziel auf NFS liegt.
Warum zur Hölle sollte bei sowas das Zeil auf NFS liegen?
Das Ziel mag von wo anders per NFS erreichbar sein aber rsnapshot lässt man üblicherweise am Zielserver laufen wenn man nicht völlig bekloppt ist
Grundsätzlich hast du natürlich recht. Nur hilft einem das bei einer FS-Migration nicht. Denn man bekommt die Daten nicht auf ein btrfs kopiert. Bzw wäre interessant, was bei einer Konvertierung passiert...
Was hat ein Dateisystemsnapshot mit einem versionisierten rsnapshot-Backup auf einem REMOTE-Rechner zu tun? Thema verfehlt!
Man nehme statt Hardlinks einfach den Snapshotmechanimus des Dateisystems, also
rsync quelle ziel && mache_snapshot_auf ziel
Ob btrfs zuverlässig genug für "ziel" ist muss jeder selbst entscheiden.
Mein Gott wie dämlich kann man sich anstellen?
WIEVIELE rsync-Backups eines BTRFS-Snapthots kannst du denn auf dem Backup-Server so machen und wieviel Platz braucht eine Backup-Version? Denk mal nach? Kommst du nicht drauf? Den VOLLEN Platz verflucht nochmal!
Es soll ja auch nicht der Schnappschuss gespiegelt werden, sondern von der Spiegelung ein Schnappschuss gemacht werden. Nochmal in Einzellschritten:
1. Spiegele Daten mit rsync auf den Sicherungsserver
2. Mache Schnappschuss mit Dateisystemfunktion auf dem Sicherungsserver
Warum sollte der Speicherbedarf auf dem Sicherungsserver denn dann steigen?
Was der Vorposter sagt.
Deine Hardlinks funktionieren auch nicht zwischen dem ENTFERNTEN- und dem LOKALEN-Rechner.
Die Hardlinks sind am BACKUP-SERVER du Wahnsinniger und sorgen dafür dass du eben unzählige Versionsstände auf selbigem haben kannst. Kopierst du einen BTRFS-Snapshot per rsync braucht jede Version auf der gegenseite den vollen Platz
__________________________
Abgesehen davon wer hat dir eigentlich erzählt dass Hardlinks mit rsync nicht überragen werden können? Das ist doch einfach alles nur Bullshit was ihr heir von euch gebt weil wenn dem so wäre müsstest du bei mir vorbeikommen und meinem Homeserver und Office-Rechner erzählen dass das was sie seit langem machen nämlich die gegenseitigen rsnapshot-Backups per rsync geegnseitig abzugleichen um auf jedem Rechner den vollen Versionsstand des anderen zu haben gar nicht geht
rsync --help | grep link
socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
-l, --links copy symlinks as symlinks
-L, --copy-links transform symlink into referent file/dir
--copy-unsafe-links only "unsafe" symlinks are transformed
--safe-links ignore symlinks that point outside the source tree
-k, --copy-dirlinks transform symlink to a dir into referent dir
-K, --keep-dirlinks treat symlinked dir on receiver as dir
-H, --hard-links preserve hard links
--link-dest=DIR hardlink to files in DIR when unchanged
Hardlinks funktionieren nicht über Dateisystemgrenzen hinweg. Wenn du sie auf den Sicherungsserver überträgst dann musst du die Ganze Datei übertragen. Sie kann dann auf dem Sicherungsserver wieder als Hardlink repräsentiert werden.
> Hardlinks funktionieren nicht über Dateisystemgrenzen hinweg.
> Wenn du sie auf den Sicherungsserver überträgst dann musst du
> die Ganze Datei übertragen.
Das ist doch Schwachsinn
Informiere dich wie rsync arbeitet
Da läuft auf beiden Seiten ein rsync-Prozess und beide sprechen miteinander per SSH und da muss niemand eine ganze Datei übertragen weil eine Instanz zur anderen einfach sagt "Mach hardlink A nach B" genauso wie rsync so gut wie nie Dateien komplett überträgt wenn sie nicht komplett neu sind (Wie gesagt: Informiere dich wie es arbeitet, ich werde nicht dafür bezhalt Leuten hier Basics zu erklären)
> [...] meinem Homeserver und Office-Rechner [...]
Wusste ich es doch.
Was wusstest du?
Dass ich daheim und im Büro auch einen Rechner habe?
Ja und weiter?
Ändert nichts daran dass ich auch für die restliche Tecnnik inkl. Backup und Security zuständig bin, in den letzten 15 Jahren keinen einzigen Datenverlust zu verantworten habe und wir reden hier von etwa 300.000 Euro Umsatz der über die Infarstruktur am Tag generiert wird
Dann ist dein Unverständnis um so trauriger.
Rufe rsync mit --inplace auf und auf dem btrfs werden, dank COW, nur die veränderten Blöcke gespeichert, d.h. du sparst sogar noch Speicher gegenüber einem Hardlink und hast nicht das Problem der Hardlinks, das wenn aus irgendeinem Grund eine Datei verändert wird, alle im Eimer sind.
Das ist dann wohl eher eine Versionierungs-, als ein Backupprogramm. Wenn dann die Datei kaputt ist, viel Spaß beim zurückspielen der "Links"
Was willst du mir erzählen?
Wenn die Datei beim ersten Backup kaputt ist dann ist das eben so
Die ist aber dann auch bei jeder anderen Sicherungsvarianten zu dem zeitpunkt kaputt, das hat aber nichts mit dem Thema zu tun
Natürlich ist rsnapshot ein Backup
Jeder vernünftige Mensch macht das auf Remote-Rechnern
Hier helfen dir keine Dateisystemsnapshots und sonst was
Es geht einfach darum EINE Vollsucherung verschlüsselt und mit komprimierter Übertragung auf eine physisch getrennte Location zu machen und da mehrere Versionsstände zu haben ohne für unveränderte Dateien mehrfach Platz zu beansprucehn - Und ja es gibt kaum was affetiveres als rsync über SSH auf WAN-Strecken
Das da unten sind Traffic-Summarys eines Backupservers der täglich etwa 2 TB an Daten abgleicht, Abgleich über 100 Mbit etwa 15 Minuten und ranspshot dann am Backup-Server täglich etwa 20 Minuten
Dec '11 160.08 GiB | 3.69 GiB | 163.77 GiB | 512.92 kbit/s
Jan '12 84.68 GiB | 2.55 GiB | 87.23 GiB | 273.19 kbit/s
Feb '12 146.01 GiB | 3.27 GiB | 149.28 GiB | 499.78 kbit/s
Mar '12 115.57 GiB | 2.67 GiB | 118.24 GiB | 370.31 kbit/s
Apr '12 200.35 GiB | 4.90 GiB | 205.25 GiB | 664.26 kbit/s
May '12 168.85 GiB | 4.30 GiB | 173.15 GiB | 542.30 kbit/s
> Es geht einfach darum EINE Vollsucherung verschlüsselt und mit komprimierter
> Übertragung auf eine physisch getrennte Location zu machen und da mehrere
> Versionsstände zu haben ohne für unveränderte Dateien mehrfach Platz zu
> beansprucehn - Und ja es gibt kaum was affetiveres als rsync über SSH auf
> WAN-Strecken
Jedes ordentliche Backupprogramm kann inkrementelle bzw. differentielle Backups.
Und weiter?
Auf ein rsync Backup kann ich mit jedem sftp-Client auf jeden Versiionsstand jeder einzelnen Datei binnen Sekunden zugreifen - Zeig mir das bei anderen Lösungen
Das ist nicht der Sinn eines Backups. Ein Backup brauche ich für größere Ausfälle (mehrere Platten defekt, defektes Dateisystem o.ä.). Um einzelne Dateien die der Benutzer versehentlich gelöscht oder überschrieben hat wiederherzustellen gibt es Dateisystemsnapshots. Die kann man auch mal stündlich machen.
Und nicht weiter.
Was für DICH Sinn eines Backups ist interessiert eigentlich niemanden wirklich
Für den Rest der Welt ist Sinn eines Backups bei Datenverlust selbige MÖGLICHST SCHNELL wiederherstellen zu können womit dein band schon mal weg fäkkt - Oder wie lange brauchst du um darauf einen Ordner in der Version vom 07.12.2011 zu finden und gezielt wieder herzustellen?
Abgesehend avon solltest du langsam kapieren dass das Thema NICHT welche Arten von Backups es gibt und wie geil du welche findest ist sondern die Frage war schlicht und ergreifend wozu man mehr als 253 Hardlinks BRAUCHEN HÄNNTE (Nicht wofür DU sie braucehn könntest) und die habe ich beantwortet
Warum diskutierst du dann eigentlich mit, wenn's doch am Thema vorbei geht. Zumal das Thema nicht lautet "...Hardlinks...", sondern "Btrfs-Hauptentwickler verlässt Oracle"
Ich habe genau EINE FRAGE beantwortet
> Eine Datei mit 253 Hardlinks versehen? Wozu braucht man das???
Die restliche Diskussion kommt von typen wie dir die nicht verstehen dass es ausser ihrer Welt auch noch was gibt und dass es keine Rolle sielt was DU gut findest - Das ist EIN Einsatzzwekcj von 253 Hardlinks, Frage beantwortet
Und jetzt nerv wen anderen
> Dateisystemsnapshots. Die kann man auch mal stündlich machen
Dafür solltest du dir eigentlich einen anderen Job suchen
Du willst also in der Produktivumgebung auf einem sündteuren SAN das als Shared Storage für einen VMware Cluster dient stündlich FS-Snapshots machen anstatt diese Sicherungen isoliert von der Nutzlast und auf deutlich günstigerem Storage zu machen?
Probier das mal in einer Firma wo Leute noch einen Überblick haben was die Techniker so machen und du wirst die längste Zeit einen Job dein eigen genannt haben
Weitere Nachteile der Hardlink-Methode:
- Setzt auf Zielseite ein Unixdateisystem voraus.
- Änderungen der Zugriffsrechte etc. können nicht nachvollzogen werden, es sei denn man speichert sie separat.
- Keine Komprimierte Speicherung möglich.
Vorteil: Jederzeit Zugriff auf den Verzeichnisbaum des Backups (ohne entpacken, ohne spezielle Software).
Hat halt alles Vor- und Nachteile.
> Setzt auf Zielseite ein Unixdateisystem voraus
Und weiter?
Was interessieren mich andere Daetisysteme im Konext von Servern?
Was interessieren mich nicht-unixoide Systeme im Allgemeinen?
Im Wort "Unixdateisystem" steckt nicht nur "Unix" sondern auch "Dateisystem". Schon mal ein rsync-"Backup" auf Band gemacht? Und ja, Bänder sind fern vom Heimanwender immernoch das Mittel der Wahl. Dass dich das mit deinem 2-TB-Spielzeugserver nicht interessiert mag sein.
Und nicht weiter!
> Dass dich das mit deinem 2-TB-Spielzeugserver nicht interessiert mag sein
Du bist doch wirklich lächerlich
Also für dich ist alles was keine zig TB Daten hat ein Spielzeugserver?
Was machen denn deine vielen TB den ganzen Tag?
Eine kleine VM mit 10 GB erwirtschaftet hier für einen Kunden etwa 60.000 Euro am Vormittag - Soviel zum Thema Spielzeug, nur weil ihr hirntot Datenmengen produziert ist nicht alles andere was effektiv arbeitet Spielzeug
Auf ein TB bekomme ich alle Server mit Ausnahme des Fileservers locker unter und hier sind Bandsicherungen völlig irrelevant weil wenn sie gebraucht werden muss selektiver und schneller Zugriff darauf bestehen
Aber was erzähle ich das jemanden der nur seine Datenhalde kennt und noch nie Dienste betrieben hat wo tausende Kunden zeitgleich Daten aktuell lesen und schreiben und du nicht erst im Fehlerfall einen halben >Tag suchen oder gleuich die ganze Bude umbringen kannst weil du in geistuger Umnachtung ein Vollbackup zurückspielst das auch alle andern zurückbombt
Wird das nun ein Schwanzvergleich? Wer in der größten Firma arbeitet, wer am meisten erwirtschaftet? Sind unsere Egos wirklich so klein?
Es ist das Internetz hier. Niemand gibt etwas darauf was der andere vorgibt zu sein. Aber was weiß ich schon. Schließlich bin ich erst 12 und besuche die Abendschule in einer geschlossenen Anstalt. Ich bin ja wahnsinnig.
Frag das doch die Pfeife der was von "2-TB-Spielzeugserver" hinausrülpst und meint alle die nicht genauso hirnlos wie seine Firma mit Storage agieren betreiben nur Spielzeug
Entscheide dich: Sündteures SAN-Storage oder ein paar TB Daten?
Und wo liegen die Daten?
A) In der VM? -> du sicherst täglich GB-große VM-Images mit rsync? No-go
B) Auf dem Fileserver? -> Dann ist es egal ob VM oder nicht. Aber hauptsache VM wird erwähnt. Das wirkt immer professionell. Ich drifte schon wieder(?) ab.
> Entscheide dich: Sündteures SAN-Storage oder ein paar TB Daten?
Ach beides gibts bei euch nicht?
Schon mal was davon gehört dass ein SAN-Storage mehrere LUN
hab kann wo dahinter unterschielidliche RAID-Level mit
unterschieldlicen Disks arbeiten?
> Und wo liegen die Daten?
> A) In der VM? -> du sicherst täglich GB-große
> VM-Images mit rsync? No-go
Wozu sollte ich die Images mit rsync sichern
Für die VMs selbst gibt es VMware Data Recovery
rsnapshot-Backups sichern Daten aus den VMs raus
> B) Auf dem Fileserver? -> Dann ist es egal ob VM oder nicht.
> Aber hauptsache VM wird erwähnt. Das wirkt immer professionell
Hier hast du was zu lesen
http://www.vmware.com/de/products/datacenter-virtualization/data-recovery/overview
Damit du kapierst dass es etwas mehr als deine kleine Welt gibt und
vielleicht verstehst du irgendwann auch dass profesionell arbeitende
Techniker MEHERER Backup-Strategien gleichzeitig fahren weil du auch
je nach Art der Beschädigung ein völlig anderes Recovery-Szenario
brauchst
Aber du würdest vermutlich wenn jemand einen Ordner killt die
kompeltte VM aus dem Backup zurückblasen und bezüglich der
andern damit verlorenen daten nur mit der Schulter zucken
> Damit du kapierst dass es etwas mehr als deine kleine Welt gibt und
> vielleicht verstehst du irgendwann auch dass profesionell arbeitende
> Techniker MEHERER Backup-Strategien gleichzeitig fahren weil du auch
> je nach Art der Beschädigung ein völlig anderes Recovery-Szenario
> brauchst
Habe ich das bestritten? -->
> Aber du würdest vermutlich wenn jemand einen Ordner killt die
> kompeltte VM aus dem Backup zurückblasen und bezüglich der
> andern damit verlorenen daten nur mit der Schulter zucken
Wenn jemand einen Ordner killt, kann dieser jemand ihn per FS-Snapshot zurückspielen, ohne dass der Admin davon was mitbekommt. So muss das "normale" Backup praktisch nur noch bei defektem RAID, FS, o.ä. einspringen, oder wenn die gewünschte Version nicht mehr vom FS-Snapshot abgedeckt ist.
Dieser jemand hat aber üblicherweise keinen Zugriff auf Backups weil nur Idioten in einem Snapshot oder einer lokalen Kopie oder gar in einem RAID ein Backup sehen
Was bringt mir ein Snapshot auf einem komprommitierten Server? Das Backup hat in jedem Fall auf einer eigenen und isolierten Maschine zu liegen
Willst du es nicht verstehen?
Wenn
- mehr Platten kaputt gehen als das RAID verkraftet
- das Dateisystem beschädigt wird
- der Server kompromittiert wird
- die Bude abbrennt etc.
- ...
dann spielt der Admin das (ggf. Offsite-)Backup zurück.
Wenn
- ein Benutzer eine Datei löscht/überschreibt/...
dann holt sich dieser Benutzer einen Snapshot.
Wenn du zum Abschluss noch einen konstruktiven Beitrag machen willst, schreibst du jetzt noch die ungefähren Häufigkeiten der obigen Ereignisse hinzu, sowie den Aufwand fürs Wiederherstellen. Wenn du dann den Sinn von Snapshots nicht siehst (und verstehst dass es sich lohnt dafür auch Kapazität bereitzustellen), solltest _du_ dir einen anderen Job suchen.
> mehr Platten kaputt gehen als das RAID verkraftet
Hast du im Normalfall grob was falsch gemacht
> das Dateisystem beschädigt wird
Vom SAn-Storage
Eher unwahrscheinlich
Aber genau dafür gibt es Backups
> der Server kompromittiert wird
Hilft dir auch kein Snapshot
> die Bude abbrennt etc.
Genau dafür gibt es Backups
> dann spielt der Admin das (ggf. Offsite-)Backup zurück.
Eben - Einmal alle 20 Jahre
> - ein Benutzer eine Datei löscht/überschreibt/...
Ist er ein Idiot
> dann holt sich dieser Benutzer einen Snapshot.
Nö, dann geht er einen Raum weiter und ICH hole das Backup zurück
Wenn ich Urkaub habe sitzt der Kollege da
> Wenn du dann den Sinn von Snapshots nicht siehst (und
> verstehst dass es sich lohnt dafür auch Kapazität bereitzustellen),
> solltest _du_ dir einen anderen Job suchen
Kein normaler Mensch lässt in einer komplett virtualisierten Umgebung
in den Gästen Snapshots permanent laufen. Auf Snapshots im SAN
hat kein user Zugriff und die sind auch nur ganz ganz selten
sinnvoll für ein Recovery weil du damit auch sämtliche VM's
zurückbombst
Nochaml: Wer heute noch Server Bare-Metal installiert ist ein Dummkopf
>> mehr Platten kaputt gehen als das RAID verkraftet
> Hast du im Normalfall grob was falsch gemacht
Leider liegen manche Crashs nichtmal an den Platten selbst,
dann nimmt irgend eine andere Komponente wegen einem elektrischen Defekt einige Platten mit.
Oder die USVs springen nicht rechtzeitig an, die klima streikt, ... . Leider kann man sich nicht gegen alles so absichern, dass es wirtschaftlich bleibt.
>> das Dateisystem beschädigt wird
>Vom SAn-Storage
>Eher unwahrscheinlich
>Aber genau dafür gibt es Backups
Eine SAN ist auch nur eine Blackbox, der man nicht allzu sehr vertrauen schenken sollte.
Auch eine Branchengrößen wie Strato hatte da mal Ärger mit.
> Nochaml: Wer heute noch Server Bare-Metal installiert ist ein Dummkopf
Ich würde mal die Handlungsweisen von anderen nicht als dumm bezeichnen, nur weil diese eine andere Vorgehensweise haben. Nicht alles, was für den einen Sinnvoll ist, ist bei dema anderen auch Praxistauglich.
Die eigentliche Frage ist doch, fern von irgendwelchen Szenarios und Papierdaten. Wie brauchbar ist btrfs bereits für die Praxis, oder welche Showstopper gibt es, die einem früher oder Später gewaltig auf die Füße fallen können. ext3/4+LVM ist Praxiserprobt und funktioniert. btrfs kann da noch so manche böse Überraschung beinhalten, manches liest man auch schon in einzelnen Foren.