Wir hier auch der MBR sowie die kompletten Partitionsinformationen mitkopiert?
Wir hier auch der MBR sowie die kompletten
Partitionsinformationen mitkopiert?
Nin.
HTH,
Sebastian
Wir hier auch der MBR sowie die kompletten
Partitionsinformationen mitkopiert?
hier WTF? Beziehst Du Dich zufaellig auf [1]? Dann ja.
Nin.
Ist das zufaellig ein Nein?
HTH,
Me too,
Gruss vom Zentrum.
===footnotes===
[1]
http://www.wer-weiss-was.de/cgi-bin/forum/showarchiv…
Wir hier auch der MBR sowie die kompletten
Partitionsinformationen mitkopiert?
Ist da zufällig ein verständlicher Satz?
Nin.
Ist das zufaellig ein Nein?
Das war die Antwort auf die Frage. Nicht sehr definierbar, in der Tendenz eben ein „nein“ (weil hier neben mir eben keine Partitionsinformationen kopiert werden und ich gerade nicht wußte, wo sonst…
Nimm es nicht persönlich, aber so mein Backup zu machen halte ich aus einer ganzen Reihe von Gründen suboptimal.
-
Ob man jedes Mal ein Vollbackup will…?
-
Leere Bereiche der Platte werden mitgespeichert. Vorher mit Nullen beschrieben wurde nicht…
-
Wenn die Platte abgeraucht ist und man kauft eine größere (das geht oft kaum anders…) ist der zusätzliche Platz nicht nutzbar.
-
Ich will keine komprimierten Backups: ein ranzliges Bit und das Backup ist weg. Besser ist es ggfs, die Einzeldateien vor dem Backup zu komprimieren. Naja, das geht bei der Methode schon garnicht.
-
Wie war das mit der maximalen Dateigröße…?
Sebastian
Wir hier auch der MBR sowie die kompletten
Partitionsinformationen mitkopiert?Ist da zufällig ein verständlicher Satz?
ROTFL, j Du habn rech.
Nin.
Ist das zufaellig ein Nein?
Nicht sehr definierbar, in der Tendenz eben ein „nein“ (weil hier
neben mir eben keine Partitionsinformationen kopiert werden und ich
gerade nicht wußte, wo sonst…w
Mit ‚dd if=/dev/hda‘ werden AFAIK auch die Partionsinformationen und der MBR gesichert.
http://www.wer-weiss-was.de/cgi-bin/forum/showarchiv…
Nimm es nicht persönlich,
Nein, so empfindlich bin ich dann doch nicht. 
aber so mein Backup zu machen halte ich aus einer ganzen Reihe von
Gründen suboptimal.
Ich auch, aber es ist IHMO die allgemeinste Loesung. Und eine andere Moeglichkeit, die Partitionen und den MBR mitzusichern faellt mir gar nicht ein.
- Ob man jedes Mal ein Vollbackup will…?
Full ACK, aber was kuemmert mich der Platzenplatz anderer Leute.
- Leere Bereiche der Platte werden mitgespeichert. Vorher mit
Nullen beschrieben wurde nicht…
dd if=/dev/zero of=/tmp/hugefile; rm /tmp/hugefile
tut das nicht?
- Wenn die Platte abgeraucht ist und man kauft eine größere
(das geht oft kaum anders…) ist der zusätzliche Platz nicht
nutzbar.
Den freien Platz nachtraeglich partitionieren und ins Dateisystem einhaengen? Oder mit so neumodischem Kram wie gpart(?) die Partionen vergroessern?
- Ich will keine komprimierten Backups: ein ranzliges Bit und
das Backup ist weg. Besser ist es ggfs, die Einzeldateien vor
dem Backup zu komprimieren.
Deshalb ja kein gzip, sonder bzip2. Du weisst, dass das ‚b‘ fuer ‚block‘ steht und daher bei einem Bitkipper maximal ein Block weg ist?
- Wie war das mit der maximalen Dateigröße…?
Nu’ hoer aber auf, aktuellen Filesysteme koennen soviel TB, dass ich mir die Zahl wegen Unwichtigkeit nicht mal merken kann. (reiserfs 3.6 theoretisch 260Byte)
Sebastian
Gruss vom Zentrum.
- Leere Bereiche der Platte werden mitgespeichert. Vorher mit
Nullen beschrieben wurde nicht…dd if=/dev/zero of=/tmp/hugefile; rm /tmp/hugefile
tut das nicht?
Vielleicht sollte ich Deine Beiträge zur Abwechslung mal wieder vollständig lesen…
- Wenn die Platte abgeraucht ist und man kauft eine größere
(das geht oft kaum anders…) ist der zusätzliche Platz nicht
nutzbar.
Den freien Platz nachtraeglich partitionieren und ins
Dateisystem einhaengen? Oder mit so neumodischem Kram wie
gpart(?) die Partionen vergroessern?
Pah! Ich bin für sowas imer zu feige…
- Ich will keine komprimierten Backups: ein ranzliges Bit und
das Backup ist weg. Besser ist es ggfs, die Einzeldateien vor
dem Backup zu komprimieren.Deshalb ja kein gzip, sonder bzip2. Du weisst, dass das ‚b‘
fuer ‚block‘ steht und daher bei einem Bitkipper maximal ein
Block weg ist?
Stimmt. Ja. Ich frage mich, was das an Rechenzeit frisst. Auf meiner lahmen Kiste habe ich 'mal wav-Dateien kompromiert… auauaua…
- Wie war das mit der maximalen Dateigröße…?
Nu’ hoer aber auf, aktuellen Filesysteme koennen soviel TB,
dass ich mir die Zahl wegen Unwichtigkeit nicht mal merken
kann. (reiserfs 3.6 theoretisch 260Byte)
Ich habe immer so die Idee, daß die maximale Größe einer Datei nicht wirklich utopisch groß ist.
Und ReiserFS? Ich mache da eher einen Bogen drum…
Sebastian
Vielleicht sollte ich Deine Beiträge zur Abwechslung mal
wieder vollständig lesen…
Nun, es gehoert zur Grundvoraussetzung einer guten Diskussion, dass man einander zuhoert.
Den freien Platz nachtraeglich partitionieren und ins
Dateisystem einhaengen? Oder mit so neumodischem Kram wie
gpart(?) die Partionen vergroessern?Pah! Ich bin für sowas imer zu feige…
Ja, so Kram wie gpart steh ich auch skeptisch gegenueber, aber neue Partionen anlegen…
Deshalb ja kein gzip, sonder bzip2. Du weisst, dass das ‚b‘
fuer ‚block‘ steht und daher bei einem Bitkipper maximal ein
Block weg ist?Stimmt. Ja.
Wobei ich mich gerade frage, was ein fehlender Block in einem Filesystem wie das vom Reiser, welches eher eine Datenbank ist, bewirkt.
Nu’ hoer aber auf, aktuellen Filesysteme koennen soviel TB,
dass ich mir die Zahl wegen Unwichtigkeit nicht mal merken
kann. (reiserfs 3.6 theoretisch 260Byte)Ich habe immer so die Idee, daß die maximale Größe einer Datei
nicht wirklich utopisch groß ist.
Willkommen im heute.
Und ReiserFS?
Du kannst natuerlich auch ext2/3 nehmen, da hab ich gerade irgendwas von 4TB aufgeschnappt. So what?
Ich mache da eher einen Bogen drum…
Was hat alle Welt eigentlich gegen reiserfs? Klar, vor zwei Jahren war das noch maechtig buggy, aber ich nutz das seit einem Jahr und hab keinerlei (kaum) Probleme damit. Mir ist einmal ein FS verlorengegangen, als mittendrin ein paar defekte Sektoren lagen. Das kann ich Hans und seinem FS schlecht vorwerfen.
Das Problem ist wohl, dass die Leute reiserfs immer noch am Stand von vor drei Jahren messen und jetzt zu feige sind, ihm eine zweite Chance zu geben. Wie oft hat es wohl im letzten Jahr ein reiserfs geschreddert? Irgendwelche Meldungen? Relativiert sich das evtl. gegen die $MANY SuSE-Nutzer, die default reiserfs untergeschoben kriegen, ohne es wahrscheinlich ueberhaupt zu wissen?
So viel Fragen,
Gruss vom Zentrum.
Vielleicht sollte ich Deine Beiträge zur Abwechslung mal
wieder vollständig lesen…Nun, es gehoert zur Grundvoraussetzung einer guten Diskussion,
dass man einander zuhoert.
Jaja…
Wobei ich mich gerade frage, was ein fehlender Block in einem
Filesystem wie das vom Reiser, welches eher eine Datenbank
ist, bewirkt.
Die Frage habe ich auch gehabt, aber ich hoffe, daß ein Dateisystem da leidlich fehlertolerant ist. „In wirklich“ habe ich aber keine Ahnung…
Ich mache da eher einen Bogen drum…
Was hat alle Welt eigentlich gegen reiserfs? Klar, vor zwei
Jahren war das noch maechtig buggy, aber ich nutz das seit
einem Jahr und hab keinerlei (kaum) Probleme damit.
Ich habe hier auf dem Laptop auch ReiserFS, allerdings mit mäßig gutem Gefühl. Naja, das war halt die Default-Installation, die ich nicht überbügeln wollte, die liebe Faulheit…
Die andere freie Partition ist auf ext3. Abgesehen davon, daß die Bugs bei ReiserFS gerne kleingejubelt wurden: spätestens die Recovery-Tools sind bei ext-Dateisystemen einfach ausgereifter…
Relativiert sich das evtl. gegen die $MANY SuSE-Nutzer, die
default reiserfs untergeschoben kriegen, ohne es
wahrscheinlich ueberhaupt zu wissen?
Ich weiß es immerhin
Gruß,
Sebastian
Wobei ich mich gerade frage, was ein fehlender Block in einem
Filesystem wie das vom Reiser, welches eher eine Datenbank
ist, bewirkt.
Ich auch nicht wirklich, habe aber ein kleines Beispiel:
Hab mal ein ReiserFS von zwei Kernel gemountet (wollte das physische Windows auf meiner Platte im VmWare booten, Linux war aber default). Hab VmWare dann sofort gekillt, damit keine FS Änderungen beim umount geschrieben werden, das FS war trotzdem im A…
fsck konnte zwar noch was richten, ich finde aber immer noch ab und zu Probleme (sowas wie „xkbsel funzte nicht, weil in den keymaps verkrüppelte manpages drin standen“). Ich habe zu dem Zeitpunkt aber weder manpages aufgerufen, noch meine keymaps geändert. Und das einzige was der zweite Kernel geändert haben dürfte waren Dateien im /tmp und /var. Sehr suspekt jedenfalls.
ciao,
krafftian