apache 1.3.27 und mod_gzip 1.3.26.1a?

[Andreas Korthaus]

Hallo!

apache 1.3.27 und mod_gzip 1.3.26.1a - ist das kompatibel? Oder sollt eman das lassen? Die Versions-Nummern sind wohl kaum zufällig oder?
Heißt das wenn ich mod_gzip verwenden will muß ich auf apache 1.3.26 "downgraden"?

Grüße
Andreas

[Bio]

Sup!

http://www.schroepl.net/projekte/mod_gzip/versions.htm

Da steht nicht, daß das an die Apache-Versionen angelehnt ist... obwohl es so SCHEINT. Aber da es keine Versionen 1.3.20/21/22/23/24/25 gab, denke ich, es kommt nicht auf diese Nummer an.

Gruesse,

Bio

[Alexander Foken]

Moin Moin !

Und ganz genau wird man's wohl in der Doku[1] nachlesen können.

Alexander

[1] Doku ? Was ist das ? Kann man das essen ?

[Andreas Korthaus]

Hi!

[1] Doku ? Was ist das ? Kann man das essen ?

Jajaja, es sah nur so eindeutig aus. Was nehmen die denn dann solche Versionsnummern? Habe den Aufwand einen schönen Server aufzusetzen doch etwas unterschätzt, naja, so langsam werde ich dafür war mit ./configure, make, make install ;-)

Mal so allgemein gefragt, ich bin jetzt bestimmt kein Linux/Apache-Fachmann, würdet Ihr es einem wie mir eher epfehlen, auf "alt bewährte" RPMs zu setzen, oder das Risiko einzugehen Fehler bei der eigenen Konfiguration zu machen, dafür aktuelle und individuell zugeschnittene Versionen zu haben? Kann dieses Risiko so überhaupt nicht einschätzen, es läuft zwar, aber ich weiß ja nicht ob das bei irgendeiner Kleinigkeit alles abstürzt ;-)

Grüße
Andreas

[Bio]

Sup!

Eigentlich ist es egal, wie Du es hinbekommst, daß es läuft, aber:

NEVER CHANGE A RUNNING SYSTEM!!!

Eigentlich sollte man zwei identische Systeme haben, damit man immer eines schrotten kann.

Gruesse,

Bio

[Alexander Foken]

Moin Moin !

Eigentlich sollte man zwei identische Systeme haben, damit man immer eines schrotten kann.

Naja, nur wenn man an der Hardware dreht. Bei Software reicht auch ein gutes (sprich: aktuelles und verifiziertes) Backup.

Aber prinzipiell hast Du recht. Und in der professionellen Praxis hat man ohnehin ein Produktivsystem, mind. ein Entwicklungssystem und mind. ein Testsystem zum Zerschießen.

Alexander

[Bio]

Sup!

Aber prinzipiell hast Du recht. Und in der professionellen Praxis hat man ohnehin ein Produktivsystem, mind. ein Entwicklungssystem und mind. ein Testsystem zum Zerschießen.

Ehm... wenn Du das sagst... komisch eigentlich, wo ich arbeite, habe ich ca. genau ein System; darum sind da allerdings jede Menge chroots drauf, das geht auch...

Gruesse,

Bio

[Alexander Foken]

Moin Moin !

Ehm... wenn Du das sagst... komisch eigentlich, wo ich arbeite, habe ich ca. genau ein System; darum sind da allerdings jede Menge chroots drauf, das geht auch...

Jau, meistens. Hilft Dir aber nicht, wenn gerade ein Prozess meint, allen Speicher und alle CPU-Resourcen an sich reißen zu müssen, und Du nicht mal mehr den kill eintippen kannst. Ok, das ist selten. Ist mir in den letzten paar Jahren auch nur einmal passiert, dann aber gründlich und zu allem Überfluß auf einer Windows-Kiste, auf die ich nur per Remote Desktop zugreifen konnte. Und natürlich beim Kunden auf der Produktivmaschine.

Alexander

[Andreas Korthaus]

Hi!

Naja, nur wenn man an der Hardware dreht. Bei Software reicht auch ein gutes (sprich: aktuelles und verifiziertes) Backup.

Was ist ein "verifiziertes" Backup? ich suche gerade noch nach guten Möglichkeiten für ein Backup. Normalerweise sichere ich auch nur die wichtigen Daten wie Conf-Dateien, home..., nur wenn ich jetzt mein komplettes System sichern will, wie mache ich das sinnvollerweise? Wo bekomme ich mal ein paar gut verständliche Infos dazu? man dd bringt mir hier nicht wirklich viel ;-)

Ich kann also mit einem dd-Aufruf images aller meiner Linux-Partitionen erstellen, und die auf CD, Wechselfestplatte oder was weiß ich brennen? Und kann ich die dann auch einfach einspielen, also wen ich tatsächlich mal was zerschossen haben sollte, womit spiele ich die Images dann ein? Und nach dem einspielen ist wieder alles so wie vorher?

Was gibt es für verschiedene Verfahren, ich kenne jetzt nur die manuelle Speicherung, die ich zwar mit crons automatisieren könnte, aber das ist auch nicht das wahre.

Wie ist das mit Spiegeln von Festplatten? Ist das auch geeignet für ein Backup? Womit macht man sowas?
Und gibt es Mechanismen, sowas in "realtime" zu machen, oder hat das keinen Sinn?

Und wie ist das mit Hardware?

• über CDRW
• über Wechelfestplatte
• über das Netzwerk
• über Firewire/USB2

Was haben die Verfahren für Vor/-Nachteile, was eigenet sich für welche Software-Lösung?

Ich weiß, sind viel zu viele Fragen, und das ganze läßt sich nicht "mal eben so" beantworten, bin aber dankbar für jeden kleinen Tipp oder weiterführenden Link.

Viele Grüeß
Andreas

[Michael Schröpl]

Hi Andreas,

Naja, nur wenn man an der Hardware dreht. Bei Software reicht auch ein gutes (sprich: aktuelles und verifiziertes) Backup.
Was ist ein "verifiziertes" Backup?

eines, bei dem Du nicht erst im Ernstfall ausprobierst, ob der Datenträger das Schreiben überlebt hat?

Viele Grüße
      Michael

[Andreas Korthaus]

Hallo!

Naja, nur wenn man an der Hardware dreht. Bei Software reicht auch ein gutes (sprich: aktuelles und verifiziertes) Backup.
Was ist ein "verifiziertes" Backup?

eines, bei dem Du nicht erst im Ernstfall ausprobierst, ob der Datenträger das Schreiben überlebt hat?

Wie macht man das? Einfach manuell mit ls nachgucken?

Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

Wie macht man das? Einfach manuell mit ls nachgucken?

hm ... kommt wahrscheinlich auf das Medium an.

Gebrannte CD-ROMs lese ich jedenfalls erst mal wieder komplett ein, bevor ich die entsprechenden Daten von der Festplatte lösche. Die zwei Minuten ist mir die Sache wert.

Viele Grüße
      Michael

[Alexander Foken]

Moin Moin !

eines, bei dem Du nicht erst im Ernstfall ausprobierst, ob der Datenträger das Schreiben überlebt hat?
Wie macht man das? Einfach manuell mit ls nachgucken?

Nee, damit prüfst Du nur, ob Du die Verzeichnisse lesen kannst.

fsck wäre schon nicht schlecht, anschließend ein rekursives diff zwischen Original und Backup.

Alexander

[Alexander Foken]

Moin Moin !

Was ist ein "verifiziertes" Backup?

Eines, von dem Du sicher weißt, daß man es auch wieder einspielen kann. D.h. minimal hast Du das gesamte Backup nochmal eingelesen und mit den Originaldaten verglichen. Extremisten haben eine identische Maschine, auf der das Backup jedes mal wieder eingespielt wird, bevor es als "verifiziert" abgestempelt wird.

ich suche gerade noch nach guten Möglichkeiten für ein Backup. Normalerweise sichere ich auch nur die wichtigen Daten wie Conf-Dateien, home..., nur wenn ich jetzt mein komplettes System sichern will, wie mache ich das sinnvollerweise? Wo bekomme ich mal ein paar gut verständliche Infos dazu? man dd bringt mir hier nicht wirklich viel ;-)

<freshmeat.net> hat eine Menge Linux-Backup-Scripte in allen Varianten, die auf alle möglichen Medien (CD-R/-RW, DVD-/+R/RW, Tape, Netzlaufwerk, Platte) sichern.

Aber trotzdem suche auch ich noch nach einem vernünftigen Backup. Mein System ist in System- und Datenplatte aufgetrennt, die Systemplatte ist 3G groß und nutzt 1,3G für eine fast unveränderte Slackware, die Datenplatte ist ein Software-Raid-1 mit 100G, davon z.Zt. 64G belegt. Allein für das Backup der Daten bräuchte ich an die 100 CDs oder 13 DVDs. Ich wechsle garantiert keine 100 CDs für's Backup, von den Brennzeiten will ich gar nicht reden. Also muß was anderes her. Tapes sind schweineteuer, weil neben dem Laufwerk auch noch ein passender Controller und Medien her müssen. Also werde ich wohl "bald irgendwann in ferner Zukunft" einen Wechselrahmen in die Kiste einbauen und mit zwei 100 GByte-Festplatten im Wechsel ein Backup auf andere Platten machen.

Ich kann also mit einem dd-Aufruf images aller meiner Linux-Partitionen erstellen, und die auf CD, Wechselfestplatte oder was weiß ich brennen? Und kann ich die dann auch einfach einspielen, also wen ich tatsächlich mal was zerschossen haben sollte, womit spiele ich die Images dann ein? Und nach dem einspielen ist wieder alles so wie vorher?

Naja, so lange Du die Originalplatte hast ...

Ich würde zum Backup keine Images machen, immer Kopien vom Dateisystem. Das spart zum einen den leeren Platz ein (ein Image von einer 100 GByte-Platte ist 100 GByte groß, auch wenn nur eine Datei mit diesem Posting drauf gespeichert ist), zum anderen kann man im Notfall auch auf das Wiederherstellen einzelner Dateien verzichten. Gut, das ginge auch mit einem Loop-Mount.

Was gibt es für verschiedene Verfahren, ich kenne jetzt nur die manuelle Speicherung, die ich zwar mit crons automatisieren könnte, aber das ist auch nicht das wahre.

Wenn Du (wie z.B. in Behörden) den Computer nur von Morgens bis Abends brauchst, und der Computer in der Nachtschicht nichts zu tun hat, ist ein Cron-Job optimal. Wenn Du kreativ arbeitest (also auch mal morgens um 03:00), stört ein Cron-Job. Er könnte dich allenfalls per Mail daran erinnern, daß mal wieder ein Backup fällig ist.

Wie ist das mit Spiegeln von Festplatten? Ist das auch geeignet für ein Backup? Womit macht man sowas?

RAID1 in Software unter Linux. Zum Backup nur bedingt geeignet, Du mußt dem RAID-System erklären, daß die Backup-Platte doch bitte mit dem aktuellen Stand überschrieben werden soll. Das geht dann aber wesentlich schneller als eine Kopie über das Dateisystem. Als ich mein RAID aufgesetzt habe, mußte ich einmal alle Daten (ca. 60 G) kopieren, das hat über das Dateisystem über eine Stunde gedauert. Als ich dann die "neue" Platte ins RAID aufgenommen habe, hat das SW-RAID die Platte innerhalb von etwa 30 Minuten auf den Stand der Datenplatte gebracht.

Kurz: Es geht, ist aber üble Trickserei.

Und gibt es Mechanismen, sowas in "realtime" zu machen, oder hat das keinen Sinn?

z.B. rsync auf eine zweite Maschine, http://rsync.samba.org/

Und wie ist das mit Hardware?

• über CDRW

bis ca. 1 GByte geht das, mit DVDs bis 10 GByte (je zwei Medien).
Wenn Du einen Roboter hast, sind auch unbeaufsichtigte Backups möglich.

• über Wechelfestplatte

sehr schnell, bis 160 GByte pro Medium

• über das Netzwerk

Denken wir mal drüber nach, wenn Du Gigabit-Ethernet als veraltet betrachtest. ;-) Im Ernst: Ist zwar relativ langsam, aber mit einem richtig großem File-/Tape-Server im Hintergrund kannst Du unglaubliche Datenmengen (TByte) sichern. Das Backup müßte dann quasi ständig im Hintergrund laufen, z.B. eine Lösung aus Cron-Jobs und rsync.

Bleibt das Problem des Backups des großen Servers. Aber dafür heuert man ohnehin eine professionelle Firma an.

• über Firewire/USB2

Etwa so schnell wie eine Wechselplatte. (Gut, daß Du hinter USB eine 2 geschrieben hast. ;-) )

Und noch ein Tip, weil es schon gelegentlich im Thread vorkam:

Weder IDE- noch SCSI-Platten sind hot-plug-fähig (Einstecken und Abziehen im Betrieb), solche Aktionen werden spätestens nach einigen Versuchen mit dem Tod von Festplatte und/oder Controller und/oder Computer bestraft. Für hot-plug muß erstmal Infrastruktur her. Das fängt mit Steckverbindern an, die zuerst Masse, dann Versorgung, dann Daten verbinden und in umgekehrter Reihenfolge trennen. Dann ein Controller, dermit den unweigerlich auftretenden Störungen am Bus klarkommt und den Wechsel auch erkennt. Und dann muß das Betriebssystem auch noch mit dem Wechsel klarkommen. Das können weder Linux noch Windows. Man hilft sich normalerweise damit, daß das System über SCSI an einen RAID-Controller (einen eigenen Computer) angeschlossen ist, dessen Betriebssystem (Firmware) mit dem Wechsel von Platten (auch Herstellerwechsel, Typwechsel, Größenänderung) im Betrieb klarkommt und zum Server hin wie eine SCSI-Platte aussieht. Die Platten in solchen RAID-Controllern sitzen in Rahmen mit hot-plug-fähigen Steckverbindern.

Basteleien mit mechanischen Schaltern, Relais etc. würde ich mir wirklich verkneifen, das funktioniert bestenfalls zufällig. Auch eine elektronische Umschaltung kann problematisch sein, wenn das Betriebssystem vom Wechsel nichts mitbekommt.

Firewire- und USB-Festplatten sind ein gutes Beispiel für eine halbwegs hot-plug-fähige Lösung: Wenn man dem Betriebssystem früh genug mitteilt, daß man die Platte abziehen möchte, und auf das OK vom Betriebssystem wartet, dann kann man die Platte bei eingeschaltetem PC abziehen, da USB und Firewire hot-plug-fähig sind. Zieht man die Platte ab, während gerade auf die Platte geschrieben wird, merkt man sehr schnell, daß auch das keine wirkliche hot-plug-Lösung ist: Normalerweise gerät dabei das Betriebssystem in Panik und das Dateisystem auf der Platte ist auch hinüber. Bei einem RAID-Controller (mit redundantem RAID, also nicht mit RAID-0) kann man im Betrieb eine beliebige Platte rausreißen, ohne das irgendetwas kaputtgeht. Am Produktivsystem würde ich das trotzdem nicht probieren.

Alexander

[Andreas Korthaus]

Hallo!

Danke für die ausführliche und interessante Antwort!

Aber trotzdem suche auch ich noch nach einem vernünftigen Backup. Mein System ist in System- und Datenplatte aufgetrennt, die Systemplatte ist 3G groß und nutzt 1,3G für eine fast unveränderte Slackware, die Datenplatte ist ein Software-Raid-1 mit 100G, davon z.Zt. 64G belegt. Allein für das Backup der Daten bräuchte ich an die 100 CDs oder 13 DVDs. Ich wechsle garantiert keine 100 CDs für's Backup, von den Brennzeiten will ich gar nicht reden.

Genau das ist es. Daher suche ich auch nach einer anderen Lösung. Un dwir haben noch ein nettes Problem, wir haben hier ein teures Bandlaufwerk, welches aber nur unter Win98 läuft, wender 2000, und auch kein Linux. Und bevor wie wieder so eines anschaffen, dann schon  lieber eine Weschelfestplatte - das ist _erheblich_ schneller, erheblich mehr Kapazität(80 GB IDE bekommt man ja inzwischen unter 100 EUR!). Die Frage ist halt ob  man alles sichert oder nicht. Wenn ich nur bestimmte Daten(DB, Conf-Daten, home-dirs) sichere, dann komme ich vielleicht sogar mit einer CD aus, je nachdem wie ich die zu sichernden Daten einschränke. Aber ich hab auch _sehr_ viele Fotos auf der Maschine, wenn die Weg sind - gute Nacht. Die Fotos sind alle original von digi-cam, daher recht groß.
btw., hat es sinn hier regelmäßig mal mit einem Script dranzugehen, also auf eine definierte Größe und Qualität zu verkleinern, mit image-magick oder so? Würde sicher 70% des Platzes für die Bilder sparen.
Jedenfalls läge man  mit den Fotos ganz schnell über der Kapazität auch einer DVD.
Mit einer IDE-Wechelferstplatte sähe das dann so aus: Wenn ich ein Backup machen will, muß ich den Server runterfahren, Platte rein, Server hichfahren, Backup laufen lassen(dauert sicher ne Stunde), dann verifizieren und dann wieder runterfahren, Platte aus und in den Tresor, oder wie sieht das in der Praxis aus? Auch nicht wirklich gut, oder?
Die Alternative wäre ein Wechelrahmen der hot-plug unterstützt, wie http://www.promise.com/marketing/datasheet/file/SSwap1000DS.pdf, denkst Du damit bekämst Du Probleme?

Also muß was anderes her. Tapes sind schweineteuer, weil neben dem Laufwerk auch noch ein passender Controller und Medien her müssen. Also werde ich wohl "bald irgendwann in ferner Zukunft" einen Wechselrahmen in die Kiste einbauen und mit zwei 100 GByte-Festplatten im Wechsel ein Backup auf andere Platten machen.

Hm. Dann hast Du maximal ein 24-48 Stunden altes Backup. Ist das nicht zu wenig? Was würest Du jetzt genau da drauf scheiben? Einfach komplette Kopien aller Linux Partitionen? D.h. Du hast eien 1:1 Kopie von der Original-Platte? Und kann man das im Fehlerfall dann einfach über die normale Platte drüberkopieren? Oder kann man sogar von der Wechselplatte booten?

Naja, so lange Du die Originalplatte hast ...

Wenn die kaputt geht, ist es vorbei? Kann ich da nihct auf eien andere Platte spielen, oder von der wechelplatte booten?

Ich würde zum Backup keine Images machen, immer Kopien vom Dateisystem. Das spart zum einen den leeren Platz ein (ein Image von einer 100 GByte-Platte ist 100 GByte groß, auch wenn nur eine Datei mit diesem Posting drauf gespeichert ist), zum anderen kann man im Notfall auch auf das Wiederherstellen einzelner Dateien verzichten. Gut, das ginge auch mit einem Loop-Mount.

Wenn man das schon macht könnte man das ja direkt wie Tom, gesagt hat mit tar machen, dann würde da erheblich mehr draufpassen, und man könnte auf eine Platte vielleicht 10 Tage sichern, oder? D.h. immer abwechelnd auf beide Platten schreiben, dann habe ich 10 Tage gut verteilt, und ich kan mit einem Script immer das älteste tar-Archiv löschen und das neue anlegen. ODer meinst Du tar verlangsamt das ganze? Dafür muß erheblich weniger auf die Platte gesdhreiben werden, die Frage ist nur wasLinux dann zu einer vielleicht 5 GB großen tar-Datei sagt ;-)

Wenn Du (wie z.B. in Behörden) den Computer nur von Morgens bis Abends brauchst, und der Computer in der Nachtschicht nichts zu tun hat, ist ein Cron-Job optimal.

Ja, ein Cron ist schön, aber dann bleibt die Platte im Rechner und wenn was passiert ist die Platte hin - wobei - dann habe ich ja noch di andere. Könnte klappen.

Wenn Du kreativ arbeitest (also auch mal morgens um 03:00), stört ein Cron-Job.

an der Maschine würde ich nicht "kreativ" arbeiten, ist ein Intranet-Server + Fileserver...

RAID1 in Software unter Linux. Zum Backup nur bedingt geeignet, Du mußt dem RAID-System erklären, daß die Backup-Platte doch bitte mit dem aktuellen Stand überschrieben werden soll. Das geht dann aber wesentlich schneller als eine Kopie über das Dateisystem. Als ich mein RAID aufgesetzt habe, mußte ich einmal alle Daten (ca. 60 G) kopieren, das hat über das Dateisystem über eine Stunde gedauert. Als ich dann die "neue" Platte ins RAID aufgenommen habe, hat das SW-RAID die Platte innerhalb von etwa 30 Minuten auf den Stand der Datenplatte gebracht.
Kurz: Es geht, ist aber üble Trickserei.

Wieso? Wennich einen RAID 1 habe mit dem Wechellaufwerk, am besten noch hot-plug, und dann abends eben die Platte im laufenden Betrieb austausche, wäre doch optimal! Die Frage ist nur was beim Ausfall passsiert. Könnte ich dann mit der einen Raid1 Sichderungsplatte, die im Trsor liegt die Daten vom letzten Tag komplett wieder herstellen, d.h. platte rein, neue Festplatte installien, udn alles geht wieder wie am Tag zuvor?

Und gibt es Mechanismen, sowas in "realtime" zu machen, oder hat das keinen Sinn?

• über das Netzwerk

Denken wir mal drüber nach, wenn Du Gigabit-Ethernet als veraltet betrachtest. ;-) Im Ernst: Ist zwar relativ langsam, aber mit einem richtig großem File-/Tape-Server im Hintergrund kannst Du unglaubliche Datenmengen (TByte) sichern. Das Backup müßte dann quasi ständig im Hintergrund laufen, z.B. eine Lösung aus Cron-Jobs und rsync.

Und? Nachts sichere ich so 100GB in 2 Stunden, ist doch OK!

Bleibt das Problem des Backups des großen Servers. Aber dafür heuert man ohnehin eine professionelle Firma an.

Ne, ich meien einen ausgemustereten Rechner mit Linux und großer Platte. Das reicht doch! Die Frage ist nur wie man dann bei einem Datenausfall die Daten auf dem Produktinsserver wiederherstellt.
Wäre IMHO das biligste da man nur eine Große Platte besorgen muß, am besten dann einen RAID 1, das wäre doch sicher, oder? Wenn der Rechner dann in einem andeen Raum steht?

• über Firewire/USB2

Etwa so schnell wie eine Wechselplatte. (Gut, daß Du hinter USB eine 2 geschrieben hast. ;-) )

Ja? Firewire waren ca 50 M/sec, USB2 glaueb ich noch weniger, Festoatten haben 100M/sec, oder?
Fast-Ethernet läge bei gut 10 M/sec.

Weder IDE- noch SCSI-Platten sind hot-plug-fähig (Einstecken und Abziehen im Betrieb), solche Aktionen werden spätestens nach einigen Versuchen mit dem Tod von Festplatte und/oder Controller und/oder Computer bestraft. Für hot-plug muß erstmal Infrastruktur her. Das fängt mit Steckverbindern an, die zuerst Masse, dann Versorgung, dann Daten verbinden und in umgekehrter Reihenfolge trennen. Dann ein Controller, dermit den unweigerlich auftretenden Störungen am Bus klarkommt und den Wechsel auch erkennt. Und dann muß das Betriebssystem auch noch mit dem Wechsel klarkommen. Das können weder Linux noch Windows. Man hilft sich normalerweise damit, daß das System über SCSI an einen RAID-Controller (einen eigenen Computer) angeschlossen ist, dessen Betriebssystem (Firmware) mit dem Wechsel von Platten (auch Herstellerwechsel, Typwechsel, Größenänderung) im Betrieb klarkommt und zum Server hin wie eine SCSI-Platte aussieht. Die Platten in solchen RAID-Controllern sitzen in Rahmen mit hot-plug-fähigen Steckverbindern.

Wie ich das verstanden habe macht doch der oben verlinkte Primise-Wechelrahmen irgendwie sowas, oder? Ist ja auch doppelt so teuer wie normale Wechelrahmen.

Firewire- und USB-Festplatten sind ein gutes Beispiel für eine halbwegs hot-plug-fähige Lösung: Wenn man dem Betriebssystem früh genug mitteilt, daß man die Platte abziehen möchte, und auf das OK vom Betriebssystem wartet, dann kann man die Platte bei eingeschaltetem PC abziehen, da USB und Firewire hot-plug-fähig sind.

Gut, die kosten zwar etwas mehr als wechelrahmen und "normale" platte, aber wenn es denn sicherer ist - wie würde das dann aussehen? Der einzige Vorteil wäre das ich das Sxetem zum wechel der Platte laufen lassen kann, oder?

und Du bist sicher das das mit obigem Wechelrahmen nicht geht?

Nochmal allgemein, wenn ich kein Image speichere, sondern eine Kopie, ob jetzt als tar-Archiv oder nicht, kann ich dann ohen Probleme das alte System wieder herstellen? Mit Windows ginge das sicher nicht. Sagen wir mal die feste Platte gibt den geist auf. Dann bootet der Rechner nicht mehr. Dann schiebe ich die WEchelplatte ein, kaufe eine neue Platte und setze die ein, wie bekomme ich jetzt das Filesystem auf der Sicherungs-Platte auf die neue Platte(mit allen Partitionen...)? Macht es jetzt einen Unterschied ob ich ein Image, eine Kopie oder ein tar-Archiv des Filesystems habe?

Viele Grüße
Andreas

[Alexander Foken]

Moin Moin !

btw., hat es sinn hier regelmäßig mal mit einem Script dranzugehen, also auf eine definierte Größe und Qualität zu verkleinern, mit image-magick oder so? Würde sicher 70% des Platzes für die Bilder sparen.

Ja, aber dann kommen Sachen wie Kompressionsartefakte rein. Auch nicht gut.

Mit einer IDE-Wechelferstplatte sähe das dann so aus: Wenn ich ein Backup machen will, muß ich den Server runterfahren, Platte rein, Server hichfahren, Backup laufen lassen(dauert sicher ne Stunde), dann verifizieren und dann wieder runterfahren, Platte aus und in den Tresor, oder wie sieht das in der Praxis aus? Auch nicht wirklich gut, oder?

Wenn der Server ständig laufen soll sicher nicht. Mein "Server" läuft nur, wenn ich ihn wirklich brauche, da wäre ein Backup mit Wechselrahmen kein Problem.

Die Alternative wäre ein Wechelrahmen der hot-plug unterstützt, wie http://www.promise.com/marketing/datasheet/file/SSwap1000DS.pdf, denkst Du damit bekämst Du Probleme?

Promise sagt: Es geht. Ich sage: Soweit ich weiß, ist Hotplug vor Serial ATA nicht vorgesehen. Promise hat sich anscheinend viel Mühe gegeben, um es dranzuflicken. Auf jeden Fall muß das Betriebssystem mit der plötzlich verschwundenen und wieder auftauchenden Platte zurechtkommen. Und genau das dürfte bei "normalen" IDE-Anschlüssen ohne Spezialtreiber wirklich schwer werden.

Eine Firewire- oder USB-Platte dürfte auch mit Linux funktionieren, und da spielt (wenn Du im richtigen Moment den Stecker rein- und raussteckst) auch das Betriebssystem mit. Das ist auf jeden Fall sauberer als die "drangepfuschte" Lösung von Promise.

[mit] Festplatten im Wechsel ein Backup auf andere Platten machen.
Hm. Dann hast Du maximal ein 24-48 Stunden altes Backup. Ist das nicht zu wenig? Was würest Du jetzt genau da drauf scheiben? Einfach komplette Kopien aller Linux Partitionen? D.h. Du hast eien 1:1 Kopie von der Original-Platte? Und kann man das im Fehlerfall dann einfach über die normale Platte drüberkopieren? Oder kann man sogar von der Wechselplatte booten?

Wer sagt, daß ich täglich ein Backup mache ? ;-)

Ich dachte eher an ein wöchentliches Backup. Ich habe bisher geplant, als root den kompletten Dateibaum der Datenplatte(n) auf die Backup-Platte zu kopieren (cp -a /aux /backup). Booten ist kein Problem, dafür habe ich die Systemplatte. ;-) Ernsthaft: Die Konfigurationsdateien und die Liste aller installierten Pakete müßte beim Backup mit auf die Backup-Platte. Wenn dann alles zu Bruch geht, kann ich das System von der Original-CD neu Installieren und anschließend die Konfigurationsdateien wieder zurückkopieren.

dd (also ein Image) halte ich (für mich) nicht für besonders sinnvoll, denn ich will mich "nur" gegen versehentlich gelöschte Dateien absichern. Und die bekomme ich aus einem anderen Dateibaum leichter raus als aus einem Image oder einer riesigen TAR-Datei.

Naja, so lange Du die Originalplatte hast ...
Wenn die kaputt geht, ist es vorbei? Kann ich da nihct auf eien andere Platte spielen, oder von der wechelplatte booten?

Wie schreibst Du ein Image mit 1,234,567 Sektoren auf eine Platte, die nur 1,234,521 Sektoren hat ? Booten kannst Du ohnehin oft vergessen, weil die Geometrie-Informationen im Image nicht mit der neuen Platte übereinstimmen. Das funktioniert bestenfalls zufällig.

Wenn man das schon macht könnte man das ja direkt wie Tom, gesagt hat mit tar machen, dann würde da erheblich mehr draufpassen, und man könnte auf eine Platte vielleicht 10 Tage sichern, oder? D.h. immer abwechelnd auf beide Platten schreiben, dann habe ich 10 Tage gut verteilt, und ich kan mit einem Script immer das älteste tar-Archiv löschen und das neue anlegen. ODer meinst Du tar verlangsamt das ganze? Dafür muß erheblich weniger auf die Platte gesdhreiben werden, die Frage ist nur wasLinux dann zu einer vielleicht 5 GB großen tar-Datei sagt ;-)

tar arbeitet mit streams, liest also nicht die ganze Datei ein, sondern brav häppchenweise. Da Du tar aus Sicherheitsgründen aber beim Backup nicht komprimieren lassen solltest, brauchst Du bei Tar annähernd genausoviel Platz wie für ein Unterverzeichnis. Es spart nur bei vielen kleinen Dateien etwas Platz. 10 Tage abwechselnd geht problemlos, wenn Du das hot-swap-problem gelöst hast.

RAID1 in Software unter Linux. [...] Es geht, ist aber üble Trickserei.
Wieso? Wennich einen RAID 1 habe mit dem Wechellaufwerk, am besten noch hot-plug, und dann abends eben die Platte im laufenden Betrieb austausche, wäre doch optimal!

Dank SW-RAID kannst Du einen Teil des RAID1 natürlich auf einer externen Firewire-Platte haben.

Die Frage ist nur was beim Ausfall passsiert. Könnte ich dann mit der einen Raid1 Sichderungsplatte, die im Trsor liegt die Daten vom letzten Tag komplett wieder herstellen, d.h. platte rein, neue Festplatte installien, udn alles geht wieder wie am Tag zuvor?

Dazu mußt Du dem SW-RAID "nur" sagen, daß die eingebaute Platte defekt ist, aber nicht die externe. Den Rest macht dann das RAID. Das Backup funktioniert genau andersrum: Die externe wird als "defekt" markiert und das SW-RAID kopiert die Daten von der internen auf die externe Platte.

Hinweis: Das RAID-1 kann nur so groß sein wie die kleinste Platte im RAID (d.h. die externe Platte sollte identisch oder ein paar MB größer sein).

• über das Netzwerk
  Und? Nachts sichere ich so 100GB in 2 Stunden, ist doch OK!

Wenn dir das reicht, wo ist dann das Problem ? ;-)

Bleibt das Problem des Backups des großen Servers. Aber dafür heuert man ohnehin eine professionelle Firma an.
Ne, ich meien einen ausgemustereten Rechner mit Linux und großer Platte. Das reicht doch! Die Frage ist nur wie man dann bei einem Datenausfall die Daten auf dem Produktinsserver wiederherstellt.

Das ist garantiert kein "großer" Server im n*10TByte-Bereich

Wäre IMHO das biligste da man nur eine Große Platte besorgen muß, am besten dann einen RAID 1, das wäre doch sicher, oder? Wenn der Rechner dann in einem andeen Raum steht?

Transfer-Platte mit Firewire oder USB ? Netzwerk ?

Wie wären zwei gemirrorte RAID5-Systeme mit je ein oder zwei Hot Spare Platten ? Dann hast Du eine recht gute Ausfallsicherheit. Gut, kostet etwas. Wie viele Neuner nach dem Komma sollen's denn sein ?

• über Firewire/USB2

Etwa so schnell wie eine Wechselplatte. (Gut, daß Du hinter USB eine 2 geschrieben hast. ;-) )
Ja? Firewire waren ca 50 M/sec, USB2 glaueb ich noch weniger, Festoatten haben 100M/sec, oder?

100MByte/s ist die Kapazität von ATA-100. Das schafft aber noch kein Schreib-Lese-Kopf.

Fast-Ethernet läge bei gut 10 M/sec.

Je nach Protokoll-Overhead, natürlich.

Weder IDE- noch SCSI-Platten sind hot-plug-fähig (Einstecken und Abziehen im Betrieb), [...]

Wie ich das verstanden habe macht doch der oben verlinkte Primise-Wechelrahmen irgendwie sowas, oder? Ist ja auch doppelt so teuer wie normale Wechelrahmen.

Ja, so ungefähr. Aber wie gesagt, die Norm sieht das nicht vor. Es mag gut funktionieren, aber eben "nur zufällig". Problem ist -- bei sauberem Aufbau des Rahmens -- das Betriebssystem.

Gut, die kosten zwar etwas mehr als wechelrahmen und "normale" platte, aber wenn es denn sicherer ist - wie würde das dann aussehen? Der einzige Vorteil wäre das ich das Sxetem zum wechel der Platte laufen lassen kann, oder?

Genau das.

und Du bist sicher das das mit obigem Wechelrahmen nicht geht?

Mag gehen, mag sogar garantiert sein. Ich würde es nicht machen.

Nochmal allgemein, wenn ich kein Image speichere, sondern eine Kopie, ob jetzt als tar-Archiv oder nicht, kann ich dann ohen Probleme das alte System wieder herstellen? Mit Windows ginge das sicher nicht. Sagen wir mal die feste Platte gibt den geist auf. Dann bootet der Rechner nicht mehr. Dann schiebe ich die WEchelplatte ein, kaufe eine neue Platte und setze die ein, wie bekomme ich jetzt das Filesystem auf der Sicherungs-Platte auf die neue Platte(mit allen Partitionen...)? Macht es jetzt einen Unterschied ob ich ein Image, eine Kopie oder ein tar-Archiv des Filesystems habe?

Die ganze Image-Geschichte ist sogar hauptsächlich wegen Windows gebastelt worden. Siehe z.B. Norton Ghost von Symantec -- das kann (dank viel, viel Code) auch Images auf "zu kleine" Platten wiederherstellen, biegt Boot-Einstellungen gerade, und und und.

Ein Image 1:1 kopieren geht nur bei identischer Plattengröße. Das gefummel macht zB Ghost, ansonsten ist ein Tar oder ein Dateisystem leichter wiederherzustellen. Dafür brauchst Du natürlich ein Minimal-Linux, mit den Du auch auf das Tar-File zugreifen kannst. Und Du mußt die Partitionen neu anlegen.

Alexander

[Andreas Korthaus]

Hallo!

Wenn der Server ständig laufen soll sicher nicht. Mein "Server" läuft nur, wenn ich ihn wirklich brauche, da wäre ein Backup mit Wechselrahmen kein Problem.

Die Alternative wäre ein Wechelrahmen der hot-plug unterstützt, wie http://www.promise.com/marketing/datasheet/file/SSwap1000DS.pdf, denkst Du damit bekämst Du Probleme?

Promise sagt: Es geht. Ich sage: Soweit ich weiß, ist Hotplug vor Serial ATA nicht vorgesehen. Promise hat sich anscheinend viel Mühe gegeben, um es dranzuflicken. Auf jeden Fall muß das Betriebssystem mit der plötzlich verschwundenen und wieder auftauchenden Platte zurechtkommen. Und genau das dürfte bei "normalen" IDE-Anschlüssen ohne Spezialtreiber wirklich schwer werden.

Vielleicht machen die das ja über einen RAID oder IDE-2-SCSI Controller?! Damit müßte das doch gehen, denn mit SCSI ist das doch möglich, auf alle Fälle schient es mit LInux zu funktionieren: http://www.joachimschlosser.de/Informatik/Tips/linuxtips.html, hört sich IMHO aber nicht ganz so verläßlich an, naja.

Eine Firewire- oder USB-Platte dürfte auch mit Linux funktionieren, und da spielt (wenn Du im richtigen Moment den Stecker rein- und raussteckst) auch das Betriebssystem mit. Das ist auf jeden Fall sauberer als die "drangepfuschte" Lösung von Promise.

Hm, hm, hm. Ich will aber eine Wechelplatte ;-)
Im Ernst, das ist noch deutlich billiger, vor allem wenn man 80 oder 120GB sichern will, das wird mit Firewire empfindlich teuer!
Aber wenn ich's mir recht überlege, es würde ja ausreichen, einmal am Tage(oder von mir aus in der Woche) den Server runterzufahren, Platten tauschen, und wieder hochfahren, den Rest macht dann ein Startscript.
Hm, aber glücklich bin ich damit nicht. Wöchentlich wäre das ja durchaus OK, aber in diesem Fall könnte beim SuperGAU 1 kpl. Woche Arbeit weg sein, unangenehmes Gefühl ;-)
Und wenn Du jeden Tage den Server extra runterfahren mußt... ich weiß nicht. Aber es wäre eine schnelle und günstige Lösung. Nur eben etwas unpraktisch, nur das man nicht nachlässig wird..., aber das darf nunmal nicht passieren.

Aber ich habe es schon oft gehört, das es auch "billige" Server gibt mit IDE Hot-Swap Laufwerken, die im Betrieb austauschbar sind. Und wenn schon, wwenn es dann halt ein Raid-Verbund sein muß dann ist das doch OK, das ist ja dafür vorgesehen. Geht das wohl auch mit einem Soft-Raid, oder meinst Du das geht grundsätzlich nicht mit IDE?

Ich dachte eher an ein wöchentliches Backup. Ich habe bisher geplant, als root den kompletten Dateibaum der Datenplatte(n) auf die Backup-Platte zu kopieren (cp -a /aux /backup). Booten ist kein Problem, dafür habe ich die Systemplatte. ;-) Ernsthaft: Die Konfigurationsdateien und die Liste aller installierten Pakete müßte beim Backup mit auf die Backup-Platte. Wenn dann alles zu Bruch geht, kann ich das System von der Original-CD neu Installieren und anschließend die Konfigurationsdateien wieder zurückkopieren.

Ah ja, daran hatt ich nicht gedacht. Was soll dann auf die System Platte? Die Boot-Partition, Swap-Partition, hm willst Du damit sagen das das was  ich unter / sehe noch gar nicht alles ist, sondern nur eine Partition? Darauf war ich ja jetzt boch gar nicht gekommen ;-)

Also diese Partition Muß ich dann jedesmal mit cp -a / /backup kopieren? Nur warum kopierst Du nur /aux? Ich habe meien Daten schön vertreilt, Konfiguration teilweiese original Redhat undter /etc und was weiß ich, udn ich habe meien Programme lale nach /usr/local isntalliert, und immer die Konfig-Dateien halt mt darein. Sicher müßten die dann alle Zentral liegen. Dann gibt es ja noch mein /root udn /home was noch zu sichern wäre. Und dann plane ich  halt noch Windows-Client-Daten mit Samba zu verwalten, und außerdem noch NFS einrichten, vielleicht auch eienn IMAP server, mal sehen. Außerdem ja noch der DB-Sever und Apache. Alle diese Daten müßte ich ja dann schön abgetrennt speichern, das ich möglichst alles in einem Verzeichnis habe. Aber da sind so viele Sachen, auch init-Scripte... daher hatte ich ja eigentlich gedacht, ich sichere die ganze Partition unter /, dann habe ich zum einen alle Daten, und vielleicht geht es ja das ich die Daten einfach wieder über die neue Festplatte drüberspielen kann(nachdem Linux neu installiert wurde!)

Wieso sicherst Du nur ein Verzeichnis?

dd (also ein Image) halte ich (für mich) nicht für besonders sinnvoll, denn ich will mich "nur" gegen versehentlich gelöschte Dateien absichern. Und die bekomme ich aus einem anderen Dateibaum leichter raus als aus einem Image oder einer riesigen TAR-Datei.

Hm. ich will alles sichern gegen einen Ausfall, ob Software-bedingt, oder Hardware-defekt, das ist das wichtigste, das die Daten dann nicht weg sind, da die wichtig sind! Was hätte denn ein Image für Vorteile? Mir ist wichtig das ich im Fall der Fälle dann auch schnell ein Backup  einspielen kann. Meinst Du das ginge über ein Image besser? Könnte ich bei einem  Image nicht auf eien NEuinstallation verzichnten udn das alte Image auf eine leere Festplatte schreibe und so weitermachen wie am Vortag? Wäre doch schon Praktisch, denn die Konfiguriererei ist auch nicht sobesaonders spaßig, vor allem dauert es recht lange  bis der Server dann wieder voll einsatzfähig ist.

Wie schreibst Du ein Image mit 1,234,567 Sektoren auf eine Platte, die nur 1,234,521 Sektoren hat ?

Wer sagt das ich das will? Ich kann ja 2 Identische Platten nehmen, oder die Backup-Platte größer dimensionieren.

Booten kannst Du ohnehin oft vergessen, weil die Geometrie-Informationen im Image nicht mit der neuen Platte übereinstimmen. Das funktioniert bestenfalls zufällig.

Also geht das nicht wie oben beschreiben, ich kann kein Image auf eine leere Festplatte kopieren und dann diese als Daten-PArtition verwenden, ja? Mit den System-Partitionen(Boot, Swap) mache ich das glaube ich auch auf einer extra Platte, oder spricht was dagegen(außer das ich das dann selbst partitionieren und zuweisen darf :-()?

tar arbeitet mit streams, liest also nicht die ganze Datei ein, sondern brav häppchenweise. Da Du tar aus Sicherheitsgründen aber beim Backup nicht komprimieren lassen solltest, brauchst Du bei Tar annähernd genausoviel Platz wie für ein Unterverzeichnis. Es spart nur bei vielen kleinen Dateien etwas Platz. 10 Tage abwechselnd geht problemlos, wenn Du das hot-swap-problem gelöst hast.

Wie gesagt, es gibt ja Lösungen, und Promise ist nicht der einzige Anbieter. Oder ich verwende halt RAID, wenn das was bringt.

Dank SW-RAID kannst Du einen Teil des RAID1 natürlich auf einer externen Firewire-Platte haben.

Ist wohl das vernpünftigste, vor allem wenn es bei einem Defekt schnell wieder oblie sein muss, oder?

Dazu mußt Du dem SW-RAID "nur" sagen, daß die eingebaute Platte defekt ist, aber nicht die externe. Den Rest macht dann das RAID. Das Backup funktioniert genau andersrum: Die externe wird als "defekt" markiert und das SW-RAID kopiert die Daten von der internen auf die externe Platte.

Wieso backup? Wenn schon raid dann lass ich die Platte auch dran udn tausche die täglich aus, das hätte ich jetzt gedacht udn lasse das System die ganze Zeit  mit RAID 1 laufen. Udn das mit hot-swap IDE, es könnte so schön einfach und günstig sein - wer hat denn damals bei der Spezifikation gepennt ;-)

Wenn dir das reicht, wo ist dann das Problem ? ;-)

Hm, am besten ich mache das so:
Ausrangierter Rechner mit großer Platte und Linux, mit WakeUp on LAN Netzwerkkarte, dann schreibe ich irgendein bash-script, welches über das Netzwerk diesen Rechner startet, und dann am besten per FTP ein tar-Archiv des File-systems hochläd. Oder ein Image. Problem ist aber - was machen wenn der Server jetzt die neuen Daten braucht?
Wie wärs so:
ich besorge _2_ Wechelrahmen, einen für den Server und einen für den Backup-Rechner, dazu 3 80 GB Platten(was auf alle Fälle erheblich billiger ist als 2 Firewire-Platten).

Dann läuft auf dem Server ein softraid 1, mit 1 Platte fest installiert, und einer im Wechelrahmen, die dritte Platte kommt in den backup-Rechner, und wird wie oben bechrieben täglich neu per Script beschreiben.
Wobei, dann kann ich das Backup ja gar nicht ohne weiteres autauschen. Hm, schon schwierig das ganze. Es kann doch nicht sein das Firewire das einzig sehlig machende ist. Außerdem hat der Servcer iMHO gar keine solche Schnittstelle!

Das ist garantiert kein "großer" Server im n*10TByte-Bereich

Nenene, wie gesagt(hab ich das?), LAN, mit 10-12 Client-Rechnern. Es reichen 80-120 GB für die Daten.

Wäre IMHO das biligste da man nur eine Große Platte besorgen muß, am besten dann einen RAID 1, das wäre doch sicher, oder? Wenn der Rechner dann in einem andeen Raum steht?

Transfer-Platte mit Firewire oder USB ? Netzwerk ?

das erste.

Wie wären zwei gemirrorte RAID5-Systeme mit je ein oder zwei Hot Spare Platten ? Dann hast Du eine recht gute Ausfallsicherheit. Gut, kostet etwas. Wie viele Neuner nach dem Komma sollen's denn sein ?

Was fürn Komma? Preislich soll es möglichst niedrig liegen, daher brauche ich an solche Dinge gar nicht zu denken. Softraid1 wäre ein guter kompromiss.

100MByte/s ist die Kapazität von ATA-100. Das schafft aber noch kein Schreib-Lese-Kopf.

Wieviel denn?

Fast-Ethernet läge bei gut 10 M/sec.
Je nach Protokoll-Overhead, natürlich.

FTP ist doch kein Problem, oder?

Die ganze Image-Geschichte ist sogar hauptsächlich wegen Windows gebastelt worden. Siehe z.B. Norton Ghost von Symantec -- das kann (dank viel, viel Code) auch Images auf "zu kleine" Platten wiederherstellen, biegt Boot-Einstellungen gerade, und und und.

Wenn es reicht die Daten-Platte neu zu kopieren wäre das natürlich prima!

Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

Hm, aber glücklich bin ich damit nicht. Wöchentlich wäre das ja durchaus OK, aber in diesem Fall könnte beim SuperGAU 1 kpl. Woche Arbeit weg sein, unangenehmes Gefühl ;-)

ein Backup-Konzept ist vor allem erst mal ein Konzept. Und ein Konzept befaßt sich damit, welche konkreten Ausfall-Situationen mit welchem zulässigen Datenverlust und welcher zulässigen Downtime abgedeckt werden sollen.
Nur wenn Du sauber definierst, wozu Dein Konzept in der Lage sein muß, kannst Du anschließend feststellen, was Du zu dessen Umsetzung wirklich brauchst (ggf. an Hardware, eventuell aber auch an Software und womöglich an architektonischen Voraussetzungen Deiner Anwendung!).

Wenn Deine Anforderung lautet, alle Daten zeitnah gesichert zu bekommen, und die triviale Umsetzung die Leistungsfähigkeit Deiner Hardware (oder Deines Geldbeutels, was nahezu äquivalent ist) überfordert, dann solltest Du versuchen, die unlösbare Gesamt-Aufgabe in lösbare Teil-Aufgaben zu zerlegen.
Das geht los mit der Granularität der Daten. Bestehen Deine Daten ausnahmelos aus Gigabyte-großen, monolithischen Dateien? Oder kannst Du zu jedem Zeitpunkt in effizienter Weise ein Delta gegenüber dem letzten Sicherungszeitpunkt erkennen ("find" hat zu diesem Zweck beispielsweise interessante Parameter) und sichern?
Falls letzteres der Fall ist, dann setzt sich Dein Sicherungskonzept aus einer Kombination von Gesamt- und Delta-Sicherungen zusammen - sowohl bei der Anfertigung des Backups als auch bei der Wiederherstellung der Produktions-Situation. Wobei Du das Gesamt-Backup in eine produktionsarme Phase des Tages- oder Wochenablaufes legen, aber die Delta-Sicherungen im laufenden Betrieb durchführen wirst, um einen möglichst geringen Datenverlust zu erleiden.

Viele Grüße
      Michael

[Alexander Foken]

[Teil 1 von 2 -- Die Forumssoftware mag nicht so lange Antworten.]

Moin Moin !

Promise sagt: Es geht. Ich sage: Soweit ich weiß, ist Hotplug vor Serial ATA nicht vorgesehen. Promise hat sich anscheinend viel Mühe gegeben, um es dranzuflicken. Auf jeden Fall muß das Betriebssystem mit der plötzlich verschwundenen und wieder auftauchenden Platte zurechtkommen. Und genau das dürfte bei "normalen" IDE-Anschlüssen ohne Spezialtreiber wirklich schwer werden.
Vielleicht machen die das ja über einen RAID oder IDE-2-SCSI Controller?!

Der Link führt auf ein Datenblatt für einen nackten Wechselrahmen. Aber ganz weit unten auf der zweiten Seite steht ganz klein "Hot swap with Ultra ATA/133 speed requires Promise SuperSwapTM 1000 and Promise Ultra ATA/133 RAID controller". Das soll man wohl so lesen, daß man für Hot Plug einen speziellen Controller braucht, der genau das verkraftet.

Damit müßte das doch gehen, denn mit SCSI ist das doch möglich, auf alle Fälle schient es mit LInux zu funktionieren: http://www.joachimschlosser.de/Informatik/Tips/linuxtips.html, hört sich IMHO aber nicht ganz so verläßlich an, naja.

Genau was ich sagte. Der IDE-Scan ist übrigens auch nach dem Ausbau fällig, schätze ich, denn sonst ist eine Platte zu viel im Kernel angemeldet. Und bei IDE-Hotplug darf natürlich nur eine Platte an jedem Kabel hängen.

Eine Firewire- oder USB-Platte [...]
Hm, hm, hm. Ich will aber eine Wechelplatte ;-)

Ist es doch. Sogar komfortabler.

Im Ernst, das ist noch deutlich billiger, vor allem wenn man 80 oder 120GB sichern will, das wird mit Firewire empfindlich teuer!

Du brauchst nur einen Adapter ("Bridge") von USB2 oder Firewire auf IDE, möglichst in einem 5,25"-Gehäuse. In das montierst Du einen Wechselrahmen ...

Aber wenn ich's mir recht überlege, es würde ja ausreichen, einmal am Tage(oder von mir aus in der Woche) den Server runterzufahren, Platten tauschen, und wieder hochfahren, den Rest macht dann ein Startscript.

Ich weiß nicht ...
Eigentlich sollte der Server ja wohl 24/7 laufen.

Hm, aber glücklich bin ich damit nicht.

Aber ich habe es schon oft gehört, das es auch "billige" Server gibt mit IDE Hot-Swap Laufwerken, die im Betrieb austauschbar sind.

Es gibt IDE-RAID-Subsysteme, die über SCSI oder Firewire angeschlossen werden. Quasi das gleiche Spielchen wie der "richtige" RAID-Controller mit SCSI-Platten, nur etwas billiger und u.U. geringfügig langsamer.

Und wenn schon, wwenn es dann halt ein Raid-Verbund sein muß dann ist das doch OK, das ist ja dafür vorgesehen.

Nicht für permanenten Platten-"ausfall" für Backup-Zwecke. Insbesondere die Steckverbinder könnten für weniger Steckzyklen ausgelegt sein als bei Deinem Backup anfallen. Eine Platte "soll" eben nur einmal im Jahr oder so ausfallen, und nicht alle 24 Stunden.

Geht das wohl auch mit einem Soft-Raid, oder meinst Du das geht grundsätzlich nicht mit IDE?

Der einzige Unterschied zwischen HW-RAID und SW-RAID ist, daß die RAID-Logik beim SW-RAID im OS sitzt und nicht in der Firmware eines Controllers. Dadurch ist SW-RAID natürlich flexibler. Ich kenne keinen HW-RAID-Kontroller, mit dem ich *ein* RAID aus IDE-, SCSI-, Firewire- und USB-Platten bauen kann. Wenn's mich beißt, kann ich unter Linux auch ein RAID aus IDE, SCSI, Floppy und RAMDISK machen. Hat dann halt nur 1,4 MB Platz. ;-)

Ich dachte eher an ein wöchentliches Backup. Ich habe bisher geplant, als root den kompletten Dateibaum der Datenplatte(n) auf die Backup-Platte zu kopieren (cp -a /aux /backup). Booten ist kein Problem, dafür habe ich die Systemplatte. ;-) Ernsthaft: Die Konfigurationsdateien und die Liste aller installierten Pakete müßte beim Backup mit auf die Backup-Platte. Wenn dann alles zu Bruch geht, kann ich das System von der Original-CD neu Installieren und anschließend die Konfigurationsdateien wieder zurückkopieren.
Ah ja, daran hatt ich nicht gedacht. Was soll dann auf die System Platte? Die Boot-Partition, Swap-Partition, hm willst Du damit sagen das das was  ich unter / sehe noch gar nicht alles ist, sondern nur eine Partition? Darauf war ich ja jetzt boch gar nicht gekommen ;-)

Also diese Partition Muß ich dann jedesmal mit cp -a / /backup kopieren?

Dann kopierst Du /backup nach /backup/backup, und /backup/backup nach /backup/backup/backup ...

Nur warum kopierst Du nur /aux?

Weil meine Daten (fast) nur unter /aux liegen. /aux ist mein "Hausstandard" für Nutzdaten, home, Mail, etc.

Ich habe meien Daten schön vertreilt, Konfiguration teilweiese original Redhat undter /etc und was weiß ich, udn ich habe meien Programme lale nach /usr/local isntalliert, und immer die Konfig-Dateien halt mt darein. Sicher müßten die dann alle Zentral liegen. Dann gibt es ja noch mein /root udn /home was noch zu sichern wäre.

/root ist so gut wie leer
/home ist ein symlink auf /aux/files/home
/var/spool/mail ist ein Symlink auf /aux/files/var_spool_mail
/var/spool/imap ist ein Symlink auf /aux/files/var_spool_imap (und der imapd ist gepatcht, so daß er eben unter /var/spool/imap seine Mailboxen anlegt)
/opt/postgresql/data ist ein Symlink auf /aux/files/pg_data
usw.

/etc müßte ich eigentlich regelmäßig nach /aux kopieren. Ein Symlink auf /aux geht nicht, da /etc beim Booten gebraucht wird, bevor /aux gemountet wird. Und die 1000 Files und Directories unter /etc werde ich garantiert nicht einzeln mit Symlinks nach /aux verschieben.
/var/log/packages müßte ich mit ls /var/log/packages > /aux/packages.txt "sichern"
/usr/local müßte eigentlich ein Symlink auf /aux/files/usr_local sein
/usr/src müßte eigentlich ein Symlink auf /aux/files/usr_src sein

Dann dürfte die Systemplatte sterben...

Die Indirektion über das /aux/files-Verzeichnis kommt daher, daß früher unter /aux mehrere Partitionen gemountet waren (unter /aux/.1 bis /aux/.5), und /files bestand nur aus Symlinks auf Unterverzeichnissen in den einzelnen Partitionen.

Du merkt, ich liebe Symlinks und vermisse sie täglich unter Windows.

Aber da sind so viele Sachen, auch init-Scripte... daher hatte ich ja eigentlich gedacht, ich sichere die ganze Partition unter /, dann habe ich zum einen alle Daten, und vielleicht geht es ja das ich die Daten einfach wieder über die neue Festplatte drüberspielen kann(nachdem Linux neu installiert wurde!)

So ungefähr. Es gibt eigentlich nur wenige Stellen, die nach Filesystem Standard Daten von Dir liegen sollten:

/etc für Konfigurationsdateien
/var für rechnerspezifische Daten (deswegen war X11 in der Slackware lange unter /var: Es ist hardware- und damit rechnerspezifisch)
... wobei unter /var/log auch die meistens nicht kritischen Logfiles liegen. /var/spool/mail willst Du aber definitiv sichern! /var/run, /var/pid, /var/db, /var/lock, var/state, /var/tmp sind nur "bessere" Temp-Verzeichnisse.
/usr/local für all das, was Du selbst installiert hast (laut FS-Standard hat keine Distribution dort auch nur ein Byte abzulegen!)
/opt - naja, KDE will da hin. Eigentlich gehört es unter /usr/X11R6/bin. /opt ist anders strukturiert als der Rest. Unter /usr gibt es für Executables ein Sammelverzeichnis, unter /opt hat jedes Paket erstmal ein Unterverzeichnis. Die Konfiguration soll dann aber unter /etc/opt/programm abgelegt werden. Dort liegt sie aber nicht immer. /opt ist eine blöde Idee, IMHO. Trotzdem liegen dort mein Apache, mein Samba, mein PostgreSQL. /opt/*/bin wird für jeden User in dem Path eingetragen.

Fallen:
* Unter /usr/src liegt z.B. der Linux-Kernel samt Konfiguration. Sobald man aber selbst einen Kernel installiert, müßte der der Logik nach unter /usr/local liegen. Wichtig ist eigentlich nur /usr/src/linux/.config
* Viele Programme haben ihre Config unter /usr/lib oder /usr/share: lynx und joe, um nur zwei zu nennen. Abhilfe: Symlinks, was sonst!
* Selbst installierte Perl-Module landen unter /usr/lib/perl5/site_perl

Wieso sicherst Du nur ein Verzeichnis?

Siehe oben. Alles außerhalb von /aux sollten fertige Dateien von der Slackware CDROM oder Symlinks sein. Im Moment mache ich aber gar kein Backup. Ich plane es. Seit Monaten. :-(

Was hätte denn ein Image für Vorteile? Mir ist wichtig das ich im Fall der Fälle dann auch schnell ein Backup  einspielen kann. Meinst Du das ginge über ein Image besser?

Richtig. Für die Systemplatte kann ein Image sehr hilfreich sein, eben weil man schnell wieder ein laufendes System hat. So lange man noch eine "passende" Reserveplatte hat, ist ein Image völlig unproblematisch. So ein Image kannst Du sauber aber nur dann anlegen, wenn Du von einer Diskette oder CD bootest, denn von einer rw-gemounteten Partition wirst Du selten ein funktionierendes Image bekommen. Im schlimmsten Fall mag nach dem Einspielen eines Images LILO nicht mehr booten, weil die Geometrie nicht ganz stimmt, dann ist noch einmal Rescue CD/Floppy angesagt, um LILO auf die Beine zu helfen.

Also geht das nicht wie oben beschreiben, ich kann kein Image auf eine leere Festplatte kopieren und dann diese als Daten-PArtition verwenden, ja? Mit den System-Partitionen(Boot, Swap) mache ich das glaube ich auch auf einer extra Platte, oder spricht was dagegen(außer das ich das dann selbst partitionieren und zuweisen darf :-()?

Swap zu sichern ist Unsinn. Wenn Du /tmp auf einer eigenen Partition hast, brauchst Du die auch nicht sichern. /tmp darf (und sollte) bei jedem Reboot gelöscht werden. Die Partitionierung kannst Du am besten mit fdisk -l /dev/hda | lpr "sichern". Dann bleibt noch der Master Boot Record, den Du ohnehin neu anlegen mußt (1x fdisk), und / und /boot (bei mir zwei getrennte Partitionen). LILO sitzt im Superblock der /boot-Partition innerhalb der ersten 1024 Zylinder.

Natürlich hindert dich niemand, die ganze Platte in ein Image zu schreiben, aber ich würde das allerhöchstens partitionsweise machen. Bei mir liegen SWAP, / und /boot auf einer Platte. Wenn die ausfällt, und ich Images von / und /boot hätte, könnte ich notfalls auch eine etwas kleinere Platte als Ersatz benutzen, indem ich SWAP etwas kleiner mache oder komplett auf eine andere Platte lege.

Dank SW-RAID kannst Du einen Teil des RAID1 natürlich auf einer externen Firewire-Platte haben.
Ist wohl das vernpünftigste, vor allem wenn es bei einem Defekt schnell wieder oblie sein muss, oder?

Wahrscheinlich.

Wieso backup? Wenn schon raid dann lass ich die Platte auch dran udn tausche die täglich aus, das hätte ich jetzt gedacht udn lasse das System die ganze Zeit  mit RAID 1 laufen. Udn das mit hot-swap IDE, es könnte so schön einfach und günstig sein - wer hat denn damals bei der Spezifikation gepennt ;-)

Ja, Du kannst (bei Firewire/USB) die Platten "einfach so" austauschen. Gibt aber regelmäßig Mecker vom SW-RAID, weil schon wieder eine Platte "kaputt" ist. Und eine Festplatte "lose" neben dem Server liegen zu haben - waaaah!

[Alexander Foken]

[Teil 2 von 2]

Ausrangierter Rechner mit großer Platte und Linux, mit WakeUp on LAN Netzwerkkarte, dann schreibe ich irgendein bash-script, welches über das Netzwerk diesen Rechner startet,

(ftp://ftp.scyld.com/pub/diag/ether-wake.c / ftp://ftp.scyld.com/pub/diag/etherwake.8 vom Linux-NIC-Guru Donald Becker)

und dann am besten per FTP ein tar-Archiv des File-systems hochläd. Oder ein Image.

Soweit ok.

Problem ist aber - was machen wenn der Server jetzt die neuen Daten braucht?
Wie wärs so:
ich besorge _2_ Wechelrahmen, einen für den Server und einen für den Backup-Rechner, dazu 3 80 GB Platten(was auf alle Fälle erheblich billiger ist als 2 Firewire-Platten).

Du bräuchtest nur eine -- mit Wechselrahmen.

Dann läuft auf dem Server ein softraid 1, mit 1 Platte fest installiert, und einer im Wechelrahmen,

Du solltest beide Server-Platten im Wechselrahmen haben. Frei nach Murphy stirbt sonst die fest eingebaute Platte zuerst.

die dritte Platte kommt in den backup-Rechner, und wird wie oben bechrieben täglich neu per Script beschreiben.
Wobei, dann kann ich das Backup ja gar nicht ohne weiteres autauschen. Hm, schon schwierig das ganze. Es kann doch nicht sein das Firewire das einzig sehlig machende ist.

Nein, aber es hilft sehr.

Außerdem hat der Servcer iMHO gar keine solche Schnittstelle!

Dem könnte man ja mit einer Firewire-Karte abhelfen.

So, jetzt schaffe ich mal den Backup-Rechner wieder ab, ignoriere mein "laß die Finger vom Image", und verordne Dir eine Firewire-Karte und ein Firewire-Gehäuse mit Wechselrahmen, in dem abwechselnd zwei IDE-Platten laufen. Insgesamt brauchst Du vier möglichst identische Platten (und vielleicht ein oder zwei in Reserve).

Und dann kommt die große RAID-1-Mißbrauch-Imaging-Aktion:

Das RAID-1 (Mirroring, nur zur Erinnerung) in Deinem Server konfiguiertst Du erstmal so, daß Linux direkt vom RAID bootet (RAID autodetect, Partitionstyp auf FE und der Rest geht fast von selbst) und alle Daten auf dem RAID liegen, Swap nutzt leeren Platz auf beiden Platten getrennt.
Jede Platte sollte ein IDE-Kabel für sich haben, notfalls mit dem CDROM als Secondary Slave.

Dann kommt eine IDE-Platte in den Firewire-Rahmen und an den Server. Diese Platte wird jetzt als dritte Platte ins RAID-1 gehängt, sprich: Du speicherst jedes Byte auf drei Platten. Dann wartest Du, bis das SW-Raid alles rüberkopiert hat (/proc/mdstat lesen). Dann meldest Du die Firewire-Platte aus dem RAID ab, nochmal ein sync zur Sicherheit, und ziehst den Firewire-Rahmen samt Platte ab. Jetzt hast Du eine Backup-Platte, von der Dein Server wahrscheinlich sogar booten würde: Sie steckt im Firewire-Rahmen.

IDE-Platte aus dem Firewire-Rahmen raus, nächste rein, nächstes Backup.

Server-Ausfall:

Beide(!) RAID-Platten rausnehmen, Backup-Platte rein. Booten und die zweite Platte als defekt konfigurieren. Runterfahren. Neue Platte im Rahmen reinstecken, RAID wiederaufbauen lassen. Neues Backup anfertigen. Wenn Du dabei Fehler machst, hast Du nur noch einen Versuch mit dem alten Backup. Deswegen solltest Du das vielleicht einmal durchspielen und jeden Schritt exakt dokumentieren, den Du machen mußt.

Wie wären zwei gemirrorte RAID5-Systeme mit je ein oder zwei Hot Spare Platten ? Dann hast Du eine recht gute Ausfallsicherheit. Gut, kostet etwas. Wie viele Neuner nach dem Komma sollen's denn sein ?
Was fürn Komma?

Das Komma in "99,999% Verfügbarkeit". Je mehr Neuner, desto teurer.

Preislich soll es möglichst niedrig liegen, daher brauche ich an solche Dinge gar nicht zu denken. Softraid1 wäre ein guter kompromiss.

So sehe ich das auch.

100MByte/s ist die Kapazität von ATA-100. Das schafft aber noch kein Schreib-Lese-Kopf.
Wieviel denn?

Das steht öfters mal in der c't, im Plattenvergleich. Soweit ich weiß, gibt es kaum eine IDE-Platte, die auch nur ATA-66 auslasten würde. Im Burst aus dem Cache heraus sind durchaus mal 100 MByte/sec drin, aber der Cache ist im Glücksfall 512 KByte groß. Wenn aber die Platte auf einen Schlag von 0 auf 80% voll bringst oder ein vollständiges Image machst, ist der Cache fast nutzlos. Dann zählt fast nur der Durchsatz am Kopf (und der ist für Schreiben und Lesen auch noch unterschiedlich).

Fast-Ethernet läge bei gut 10 M/sec.
Je nach Protokoll-Overhead, natürlich.
FTP ist doch kein Problem, oder?

Wenn Du's wirklich schnell haben willst, nimmst Du netcat über TCP-Sockets und pipest dein tar gleich ins netcat. (Da fällt mir gerade rmt ein, das macht prinipiell genau das, nur mit einem Minimum an Protokoll, um Fehler abfangen zu können. => man rmt) Aber das bringt gegenüber FTP wohl höchstens ein paar Prozent.

Problematisch an FTP ist, daß Du Dein backup.tar erst einmal auf der lokalen Maschine haben mußt. Wenn Du (wie auch immer: NFS/AFS/SaMBa) ein Verzeichnis von der Backup-Kiste mountest, kannst Du gleich auf die Backup-Maschine schreiben, mit ein klein wenig Protokoll-Overhead.

Alexander

[Thomas Schmieder]

Hi Bio,

Eigentlich sollte man zwei identische Systeme haben, damit man immer eines schrotten kann.

Geeeenau!

Wie könnte man das erreichen?
Unter Linux ne HDD-Copy ziehen und dann makeboot auf die Kopie ansetzen? Ich meine, so ganz ohne irgendwelche Spezial-Image-Software. Nur mit Betriebssystembefehlen. Zwei identische Platten...

Und wenn man die zweite (im Wechselrahmen) dann auch noch im Betrieb rausnehmen könnte und die dritte dafür reinstecken könnte, wäre es super (unter IDE natürlich). Gibt es hotpluggable IDE-Syseme?

Liebe Grüße aus http://www.braunschweig.de

Tom

[Fabian Transchel]

Hi Tom, Andreas, Bio, ...,

Eigentlich sollte man zwei identische Systeme haben, damit man immer eines schrotten kann.

Geeeenau!

Wie könnte man das erreichen?
Unter Linux ne HDD-Copy ziehen und dann makeboot auf die Kopie ansetzen? Ich meine, so ganz ohne irgendwelche Spezial-Image-Software. Nur mit Betriebssystembefehlen. Zwei identische Platten...

Ich glaube nicht, dass man (ohne DriveImage) _das gesamte_ System backuppen kann, wohl nur die non-System-Daten sprich DB und Document_Root. Ich lasse mich aber gerne eines besseren belehren, denn in dem Falle passt ein ganzes Server-System (ohne die zu verwaltenden Daten versteht sich...) locker auf eine CD, und das wär doch was ;-)

Und wenn man die zweite (im Wechselrahmen) dann auch noch im Betrieb rausnehmen könnte und die dritte dafür reinstecken könnte, wäre es super (unter IDE natürlich). Gibt es hotpluggable IDE-Syseme?

Du kennst Fire-Wire? Ich weiß allerdings nicht, ob das in Linux schon hinreichend unterstützt wird. Ausserdem wird es derzeit schweineteuer sein, adäquate Fire-Wire-Laufwerke, die backup-redundant arbeiten können, zu bekommen.

Fabian

[Christian Seiler]

Hallo Fabian,

Ich glaube nicht, dass man (ohne DriveImage) _das gesamte_ System backuppen kann, wohl nur die non-System-Daten sprich DB und Document_Root.

Du kennst das Kommando dd anscheinend nicht.

Ich lasse mich aber gerne eines besseren belehren,

Bittesehr.

denn in dem Falle passt ein ganzes Server-System (ohne die zu verwaltenden Daten versteht sich...) locker auf eine CD, und das wär doch was ;-)

Klar, meinetwegen auch auf zwei oder drei oder vier oder auf NFS oder...: http://freshmeat.net/projects/mkcdrec

Du kennst Fire-Wire? Ich weiß allerdings nicht, ob das in Linux schon hinreichend unterstützt wird.

http://www.linux1394.org/cgi-bin/hcl.cgi

Christian

[Bio]

Sup!

Ich glaube nicht, dass man (ohne DriveImage) _das gesamte_ System backuppen kann, wohl nur die non-System-Daten sprich DB und Document_Root. Ich lasse mich aber gerne eines besseren belehren, denn in dem Falle passt ein ganzes Server-System (ohne die zu verwaltenden Daten versteht sich...) locker auf eine CD, und das wär doch was ;-)

man dd ;-)

Gruesse,

Bio

[Andreas Korthaus]

Hallo!

man dd ;-)

Das nenne ich mal ein gesprächiges Manual ;-)

Grüße
Andreas

[Thomas Schmieder]

Hi,

man dd ;-)
Das nenne ich mal ein gesprächiges Manual ;-)

verstehe trotzdem nur Bahnhof. Wie kann ich das jetzt für ein "Image" einsetzen?

Liebe Grüße aus http://www.braunschweig.de

Tom

[Sven Rautenberg]

Moin!

Hi,

man dd ;-)
Das nenne ich mal ein gesprächiges Manual ;-)

verstehe trotzdem nur Bahnhof. Wie kann ich das jetzt für ein "Image" einsetzen?

Unter Linux gilt: Alles ist Datei.

Also liest du die Datei /dev/hda aus und schreibst sie als Backup in eine andere Datei. Und wenn du nur eine Partion sichern willst, liest du die Datei /dev/hda1 aus. Jedenfalls grundsätzlich.

Rückschreiben geht genauso. Allerdings solltest du es vermeiden, auf einem aktiven Dateisystem zu arbeiten. Um die Root-Partition zu sichern bzw. das Bootlaufwerk, erscheint es ratsam, von einer anderen Quelle aus zu booten - von Diskette oder CD beispielsweise, oder aus dem Netzwerk.

- Sven Rautenberg

[Andreas Korthaus]

Hi Sven!

Unter Linux gilt: Alles ist Datei.

Ah, auch die Partitionen? Interessant...

Also liest du die Datei /dev/hda aus und schreibst sie als Backup in eine andere Datei. Und wenn du nur eine Partion sichern willst, liest du die Datei /dev/hda1 aus. Jedenfalls grundsätzlich.

Angenommen ich habe 2 verschiedene Platten, eine "live"-Platte im System integriert, und eine "backup"-Platte im Wechelrahmen. Könnte ich als backup zusammen mit dd und tar nicht die Partitionen in ein Archiv schreiben, also auf der Backup-Platte das Archiv backup_23-01-2003.tar.bz2 anlegen, mit den kompletten Partitionen als Dateien drin? Hat die Partitions-Datei dann die Größe der Partition oder des Dateinhaltes? Kann das tar "ausgleichen"(d.h. den leeren Teil der Partition "wegkomprimieren")?
Wenn das nicht geht, kann ich das Filrsystem direkt in das tar-Archiv kopieren, und im Schadensfall komplett wiederherstellen?

"Szenario": live-Platte ist defekt, Rechner abgestürzt und bootet nicht mehr. In welcher Form müssen jetzt die alten Daten vorliegen, damit ich sie wiederherstellen kann? Ich baue also eine neu, leere Festplatte ein, schiebe die backup-Platte rein und dann? Wie kommen die Daten auf die live-Platte? Und wenn ich sie kopiere,(womit wenn ich kein OS habe?), ist das kein Problem für Linux? Ich könnte ja auch eien alte kleien Platte einbauen, mit einem kleien Not-LInux, welchs in dieem Fall startet, dann würden dort die Platten beide gemountet, ud ich könnte mit cp von der backup auf die live-Platte kopieren, udn dann neu starten. Aber ich bin mir sehr sicher das das mnicht funktionieren würde. Es müssen ja auch entsprechende Partitionen geschaffen werden, das entsprechende Dateisystem..., das geht ja nicht mal eben so mit cp!
Wie macht man das sonst? vor allem wenn man kein Not-Linux hat, oder wenn aus irgendwienm Grund das auch nicht merh läuft? Kann ich linux vielleicht komplett von einer CD booten?

Rückschreiben geht genauso. Allerdings solltest du es vermeiden, auf einem aktiven Dateisystem zu arbeiten. Um die Root-Partition zu sichern bzw. das Bootlaufwerk, erscheint es ratsam, von einer anderen Quelle aus zu booten - von Diskette oder CD beispielsweise, oder aus dem Netzwerk.

Über das Netzwerk booten? Wie das? Was brauche ich auf dem Remote-Rechner dafür, und was auf dem Server?

Viele Grüße
Andreas

[Sven Rautenberg]

Moin!

Könnte ich als backup zusammen mit dd und tar nicht die Partitionen in ein Archiv schreiben, also auf der Backup-Platte das Archiv backup_23-01-2003.tar.bz2 anlegen, mit den kompletten Partitionen als Dateien drin?

Könntest du.

Hat die Partitions-Datei dann die Größe der Partition oder des Dateinhaltes?

Die Partitionsgröße.

Kann das tar "ausgleichen"(d.h. den leeren Teil der Partition "wegkomprimieren")?

Wenn Nullen oder komprimierbares Zeugs drinsteht, dann ja. Dauert aber natürlich entsprechend lange, um das zu tun. 1:1-Kopieren ist mit Sicherheit schneller.

Wenn das nicht geht, kann ich das Filrsystem direkt in das tar-Archiv kopieren, und im Schadensfall komplett wiederherstellen?

Ob komprimiert oder nicht, dürfte egal sein.

Du hast mit tar allerdings den Vorteil, dass du auf Dateiebene arbeitest. Beim Rücksichern bist du nicht darauf angewiesen, dass die neue Platte wirklich 100% identisch ist.

"Szenario": live-Platte ist defekt, Rechner abgestürzt und bootet nicht mehr. In welcher Form müssen jetzt die alten Daten vorliegen, damit ich sie wiederherstellen kann?

Das festzustellen ist Teil einer Backupstrategie, für die ich kein Experte bin. :)

Ich baue also eine neu, leere Festplatte ein, schiebe die backup-Platte rein und dann?

Um herauszufinden, was zu tun ist, solltest du diesen Ernstfall mindestens einmal durchgespielt haben, bevor du dich darauf verläßt. Und zwar nicht nur gedanklich, sondern real.

Wie kommen die Daten auf die live-Platte? Und wenn ich sie kopiere,(womit wenn ich kein OS habe?), ist das kein Problem für Linux?

Die Daten kommen so auf die Platte, wie sie heruntergekommen sind - jedenfalls theoretisch. ;)

Und wenn dein System nicht mehr bootet - für sowas hat man Notfalldisketten, oder nicht?

Aber ich bin mir sehr sicher das das mnicht funktionieren würde. Es müssen ja auch entsprechende Partitionen geschaffen werden, das entsprechende Dateisystem..., das geht ja nicht mal eben so mit cp!

Wenn du die gesamte Festplatte kopiert hast (und nicht nur eine Partition), dann sollte die Partitionstabelle eigentlich mit dabei sein.

Wie macht man das sonst? vor allem wenn man kein Not-Linux hat, oder wenn aus irgendwienm Grund das auch nicht merh läuft? Kann ich linux vielleicht komplett von einer CD booten?

Sollte ebenfalls funktionieren. SuSE hat einen Notfall-Bootmodus auf Diskette, und mit Sicherheit auch auf CD. Es funktioniert also grundsätzlich.

Über das Netzwerk booten? Wie das? Was brauche ich auf dem Remote-Rechner dafür, und was auf dem Server?

Dafür brauchst du eine bootfähige Netzwerkkarte sowie einen passenden Server, der Bootimages via TFTP (oder was immer die Netzwerkkarte benötigt - TFTP ist aber gebräuchlich) ausliefern kann. Das ist in der Regel zwingend zusammen mit DHCP zu kombinieren (aber erfordert nicht zwingend, dass DHCP und TFTP von derselben Maschine angeboten werden).

- Sven Rautenberg

[Andreas Korthaus]

Hallo!

Eigentlich sollte man zwei identische Systeme haben, damit man immer eines schrotten kann.

Geeeenau!

Wie könnte man das erreichen?

Vielleicht ein etwas anderer Ansatz: Linux auf einem Chip: http://developer.axis.com/products/etrax100lx/index.html, nur weiß ich nicht, wie das genau funktioniert und für welche Platformen das gedacht ist. Ich denke das ist nichts für sowas ;-)

Unter Linux ne HDD-Copy ziehen und dann makeboot auf die Kopie ansetzen? Ich meine, so ganz ohne irgendwelche Spezial-Image-Software. Nur mit Betriebssystembefehlen. Zwei identische Platten...

Wozu identische Platten? Willst Du auf jeder Platte eine komplette Linux-Installation haben und dann immer neu starten? Das hat ja wenig sinn wenn die eine Version produktiv eingesetzt wird, oder?

Und wenn man die zweite (im Wechselrahmen) dann auch noch im Betrieb rausnehmen könnte und die dritte dafür reinstecken könnte, wäre es super (unter IDE natürlich). Gibt es hotpluggable IDE-Syseme?

Das Thema interessiert mich ebenfalls, es scheint auch zu funktionieren, siehe
http://www.joachimschlosser.de/Informatik/Tips/linuxtips.html

Heißt das mit anderen Worten, ich brauche nur eien solchen Wechselrahmen und eine stinknormale IDE-Festplatte(genau so wie die die innen verbaut sind) und ich kann diese sogar bei einem laufenden System austauschen?

Ich dachte das seien ganz spezielle Platten?! Kennt sich da jemand aus? Wäre auch eine _sehr_ sehr_ günstige und schnelle Alternative für ein Back-up oder nicht?

Grüße
Andreas

[Andreas Korthaus]

Hallo nochmal!

Und wenn man die zweite (im Wechselrahmen) dann auch noch im Betrieb rausnehmen könnte und die dritte dafür reinstecken könnte, wäre es super (unter IDE natürlich). Gibt es hotpluggable IDE-Syseme?

Das Thema interessiert mich ebenfalls, es scheint auch zu funktionieren, siehe
http://www.joachimschlosser.de/Informatik/Tips/linuxtips.html

Also, mit hot-plug ist es natürlich etwas teuerer(>100 EUR), aber es funktioniert wohl: http://www.promise.com/marketing/datasheet/file/SuperSwap1000_DataSheet.pdf(1M)

Weiß nur noch nicht wie sich das mit den verschiedenen OS verträgt, bei Linux gibts da ne Menge Forums-Diskussionen drum, scheint aber mit einem Kernel-Patch zu funktionieren.

Nur wie soll das dann praktisch aussehen? Der Rechner läuft, ich schiebe die Wechelfestplatte ein, das Betriebssystem mountet die irgendwie, und dann lasse ich ein Shell-Script mit dd... laufen?

Oder was?

Grüße
Andreas

[Thomas Schmieder]

Hi Andreas,

Nur wie soll das dann praktisch aussehen? Der Rechner läuft, ich schiebe die Wechelfestplatte ein, das Betriebssystem mountet die irgendwie, und dann lasse ich ein Shell-Script mit dd... laufen?

Ja, so müsste das laufen.

Und wir haben bisher immer üner einen Umweg mit tar gesichert. Das ging gegenüber einem Streamer oder einem Copy über eine ssh-Verbindung und WinDoof-Client rattenschnell. Ungefähr ein 50tel der Zeit.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Thomas Schmieder]

Hallo Andreas,

Das Thema interessiert mich ebenfalls, es scheint auch zu funktionieren, siehe
http://www.joachimschlosser.de/Informatik/Tips/linuxtips.html

Und mich erstmal!

Unsere kleinen Masschinen sind alle mit einer festeingebauten und einer gleichen Platte auf Wechselrahmen bestückt. Bisher musste ich da immer noch runterfahren und dann wieder rauf. Wäre ja echt g*** wenn das klappen könnte. Da bastel ich sogar noch Hardware dafür. Relais oder so...

Heißt das mit anderen Worten, ich brauche nur eien solchen Wechselrahmen und eine stinknormale IDE-Festplatte(genau so wie die die innen verbaut sind) und ich kann diese sogar bei einem laufenden System austauschen?

Das liest sich jedenfalls so.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Andreas Korthaus]

Hallo!

Eigentlich ist es egal, wie Du es hinbekommst, daß es läuft, aber:

Die Frage ist ob es auch stabil läuft!

NEVER CHANGE A RUNNING SYSTEM!!!

Ist das so? ich dachte gerade bei Webserver-Software muß man bzgl. Sicherheitslücken auf dem neusten Stand bleiben, und das heißt doch wohl das man öfter mal updaten sollte, oder?

Eigentlich sollte man zwei identische Systeme haben, damit man immer eines schrotten kann.

Ich habe hie rmeine lokale Linux-Installation, auf der ich nach herzenslust teste, und dann halt den produktiven Webserver, auf den ich dann die zuvor "getesteten" Programme genau so aufspiele.

Aber bei Webservern kann ich das ja ganz einfach machen, indem ich 2 Server installiere, und den einen auf einem anderen Port laufen lasse, dann kann ich recht schnell umschwenken.

Grüße
Andreas

[Alexander Foken]

Moin Moin !

Was nehmen die denn dann solche Versionsnummern?

Die kommen wahrscheinlich aus dem CVS.

Habe den Aufwand einen schönen Server aufzusetzen doch etwas unterschätzt, naja, so langsam werde ich dafür war mit ./configure, make, make install ;-)

Irgendwann denkst Du nur noch "software installieren" und ertappst Dich dabei, daß plötzlich auf der Konsole "./configure && make && make install" steht. Dann darfst Du Dich Guru nennen. ;-)

Mal so allgemein gefragt, ich bin jetzt bestimmt kein Linux/Apache-Fachmann, würdet Ihr es einem wie mir eher epfehlen, auf "alt bewährte" RPMs zu setzen, oder das Risiko einzugehen Fehler bei der eigenen Konfiguration zu machen, dafür aktuelle und individuell zugeschnittene Versionen zu haben? Kann dieses Risiko so überhaupt nicht einschätzen, es läuft zwar, aber ich weiß ja nicht ob das bei irgendeiner Kleinigkeit alles abstürzt ;-)

Mir ist noch nichts kaputt gegangen, zumindest Apache und Samba installiere ich grundsätzlich aus den aktuellen Sources, statt das entsprechende Package zu installieren.

Und mal ehrlich gesagt: Viel mehr als configure, make und make install machen die RPM-Einpacker bei einer hochwertigen Software wie Apache auch nicht, außer noch eine laaaaaaaaaaaaange Liste von Abhängigkeiten ins RPM einzubauen und ein paar Verzeichnisnamen umzubiegen.

Alexander

[Thomas W.]

Hallo Alexander,

Und mal ehrlich gesagt: Viel mehr als configure, make und make install machen die RPM-Einpacker bei einer hochwertigen Software wie Apache auch nicht, außer noch eine laaaaaaaaaaaaange Liste von Abhängigkeiten ins RPM einzubauen und ein paar Verzeichnisnamen umzubiegen.

Huestl, das gepackte Diff-File des Apache in Debian 3.0 (1.3.26) hat 316kb; und das sind nicht nur ein paar Verzeichnisnamen (ist zwar .deb und nicht .rpm, aber das gilt mit Sicherheit auch fuer die anderen Distris).

Gruss
Thomas

[Michael Schröpl]

Hi Alexander,

Was nehmen die denn dann solche Versionsnummern?
Die kommen wahrscheinlich aus dem CVS.

die Versionsnummern haben Tradition: Kevin Kiley hat jeder mod_gzip-Version jeweils die Versionsnummer derjenigen Apache-Version gegeben, gegen die er das neue Release getestet hatte, plus eine zusätzliche Stelle für Bugfixes. Christian und ich haben beschlossen, uns daran zu halten.

Viele Grüße
      Michael

[Thomas Schmieder]

Hallo Andreas,

das einzige Risiko vor dem ich immer Angst habe sind Scheunentore[tm]

Ruck zuck ist Dein schöner Server im Eimer und Spielball für thorn & Co., natürlich nur, wenn er am globalen Netz hängt...

Es schadet aber bestimmt nix, selber was über den Aufbau zu wissen. Dümmer wird man davon nicht. In diesem Zusammenhang nochmal vielen Dank für Deine Infos im Thread von vorhin. Das werden wir Samstag mal sichten.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Andreas Korthaus]

Hi Tom!

das einzige Risiko vor dem ich immer Angst habe sind Scheunentore[tm]

das habe ich weniger, ich denke bei PHP weiß ich inzwischen was ich tue, PERL habe ich nicht, udn auch sonst werd eich alles an Server-Software, Apache/PHP-Modulen deaktivieren was ich nicht brauche, ich denke auch MySQL bzw. Postgres bekomme ich dicht, darauf greife ich nur über localhost zu, außerdem bin ich der einzige auf dem Server, d.h. ich habe keien Kunden die Scheunentore aufstoßen können, daher kann ich mit meinen PHP Einstellungen etwas freizügiger sein.
Ich mache mir eher Sorgen um die Stabilität. Das kann ja bei mir noch so gut laufen, manuell kann ich das definitiv nicht alles testen, und automatisch wüßte ich auch nicht wie.

Ruck zuck ist Dein schöner Server im Eimer und Spielball für thorn & Co., natürlich nur, wenn er am globalen Netz hängt...

Dann macht ein Webserver aber wenig Sinn(in meinem Fall zumindest ;-))

Es schadet aber bestimmt nix, selber was über den Aufbau zu wissen. Dümmer wird man davon nicht.

Das glaube ich auch. Außerdem kann ich so auch bestimmte Sicherheitslücken schließen, zum einen durch aktuellere Versioenn zum andeen auch druch nicht benötigte, deaktivirte Module.

In diesem Zusammenhang nochmal vielen Dank für Deine Infos im Thread von vorhin. Das werden wir Samstag mal sichten.

Gerne! ich bin noch nicht wirklich fertig, mod_perl werde ich doch weglasen da ich das gar nicht brauche wie mir gerade eingefallen ist ;-) Ich benutze PERL nur als "Shell-Script" aus PHP.

Dafür aber dann mod_gzip, bin mal gespannt wie wird und was das bringt.

Grüße
Andreas

[Michael Schröpl]

Hi Alexander,

Und ganz genau wird man's wohl in der Doku[1] nachlesen können.

mea culpa. Diese Information gehört wirklich dort hinein. Wo doch innerhalb dieses Monats schon der zweite danach fragt ... (der andere war auf der offiziellen Produkt-Mailing-Liste)

[1] Doku ? Was ist das ? Kann man das essen ?

http://www.schroepl.net/projekte/mod_gzip/

Viele Grüße
      Michael

[Alexander Foken]

Moin Moin !

Und ganz genau wird man's wohl in der Doku[1] nachlesen können.

mea culpa. Diese Information gehört wirklich dort hinein. Wo doch innerhalb dieses Monats schon der zweite danach fragt ... (der andere war auf der offiziellen Produkt-Mailing-Liste)

[1] Doku ? Was ist das ? Kann man das essen ?

Whoops! Vielleicht sollte ich mal die fragliche Doku lesen, bevor ich darüber lästere, daß niemand Dokus liest. Das hast Du wohl etwas anders gelesen als ich es gemeint hatte. War nicht böse gemeint, ich bin davon ausgegangen, daß Infos über das Versionsnummernschema in der Doku drinstehen.

Alexander

[Michael Schröpl]

Hi Alexander,

Vielleicht sollte ich mal die fragliche Doku lesen, bevor ich darüber lästere, daß niemand Dokus liest.

nur zu ...

War nicht böse gemeint, ich bin davon ausgegangen, daß Infos über das Versionsnummernschema in der Doku drinstehen.

Habe ich auch nicht als böse empfunden - ich stimme Dir ja zu.
Nur gehört da eben auch noch so viel anderes hinein ... ich müßte mir dafür einfach mehr Zeit nehmen. (Weniger Forum lesen, vielleicht?)

Viele Grüße
      Michael

[Michael Schröpl]

Hi Andreas Korthaus,

apache 1.3.27 und mod_gzip 1.3.26.1a - ist das kompatibel?

ja. Die Apache-1.3-API ist seit langem stabil, da tut sich nichts mehr.

mod_gzip benötigt die Apache-eigene regular-expression-engine; diese wurde in einer Version 1.3.singledigit eingeführt. Bis dahin zurück funktioniert alles. (Ich habe hier im Büro Apache 1.3.12 mit mod_gzip 1.3.19.2a laufen.)

Heißt das wenn ich mod_gzip verwenden will muß ich auf apache 1.3.26 "downgraden"?

Nein. Apache 1.3.27 ist ja auch nur ein relativ kleiner Patch zu Apache 1.3.26.

Viele Grüße
      Michael

[Bio]

Sup!

Was macht man eigentlich bei Apache 2.0?
Kann man da mod_cache und mod_deflate kombiniert einsetzen, oder müssen wir auf mod_gzip_cached_2 warten?

Gruesse,

Bio

[Michael Schröpl]

Hi Bio,

Was macht man eigentlich bei Apache 2.0?
Kann man da mod_cache und mod_deflate kombiniert einsetzen, oder müssen wir auf mod_gzip_cached_2 warten?

das kommt darauf an, was genau Du haben willst.

Wenn Du "einfach nur komprimieren" willst, dann nimm mod_deflate, das ist für Apache 2.0 die einfachste und von der Apache Group unterstützte Lösung.

Wenn Du einen Teil der Konfigurationssprache von mod_gzip brauchst, dann nimm mod_gzip für Apache 2.0 - das gibt es. (u. a. bei
    http://www.pcp-computer.de/gkn/apache/httpd-2.0/win32/modules/
; auch wenn dies nur das Windows-Binary zu sein scheint: Der Quelltext liegt bei.)
Das ist allerdings eine deutlich ältere mod_gzip-Version als 1.3.26.1a, weil sich die 1.3er-Implementierung nicht so ohne weiteres nach 2.0 portieren läßt - das Innenleben der beiden Apaches ist nun mal grundverschieden, und ein beträchtlicher Teil von mod_gzip 1.3 beschäftigt sich damit, genau dieses 1.3er-Innenleben korrekt zu bedienen.
mod_gzip 2.0.44 ist auch _viel_ kleiner als mod_gzip 1.3, weil es - im Gegensatz zu der 1.3er-Version - keine eigene gzip-Implementierung mitbringt (die alleine 5000 Zeilen C-Code ausmacht), sondern eine vorinstallierte zlib mit benutzt (genau wie mod_deflate). Ob dies der Weisheit letzter Schluß ist (die Experten sind sich uneinig, ob die zlib thread-safe sei oder nicht), kann ich nicht sagen.

Ob man konkret mod_deflate plus mod_cache kombiniert einsetzen kann, dazu kann ich mangels Wissen über das Filterkonzept von Apache 2.0 nichts sagen; denkbar wäre es aber durchaus.
Dies zu erforschen wäre allerdings ein interessantes Projekt - mach mal!
Ich fände jedes Argument wertvoll, das besagt, daß eine Portierung von mod_gzip nach Apache 2.0 überflüssig ist, weil der Apache dasselbe mit Bordmitteln auch schon kann ...

Viele Grüße
      Michael

[Bio]

Sup!

Die Untersuchung ist irgendwo in meiner TODO-Pipeline ;-)

Gruesse,

Bio