Backups erstellen

Maxim schrieb:
> Soll ein Netzwerkspeicher mit RAID1 als Speicherplatz dienen?

Nur nebenbei: RAID1 ersetzt kein Backup.

Maxim schrieb:

> Oder doch lieber ein Onlinebackup? Z.B. zahlt man für 250GB 50€/Jahr.

Wie lang dauert es, die Daten einer defekten Platte wiederherzustellen?

Maxim schrieb:
> In einem kleinen Geschäft soll ein Netzwerk aufgebaut werden. Ein Server
> und zwei Desktsoprechner sind vorgesehen. Wie erstellt man am besten
> Backups? Soll ein Netzwerkspeicher mit RAID1 als Speicherplatz dienen?
> Welche Software braucht man dafür? Oder reichen die Funktionen von
> Windows 7 schon aus?

Wie Jörg schon schrieb: RAID ist kein Backup!

Was passiert bei einem Brand oder einer üblen Spannungsspitze, die alle 
Platten abrauchen lässt?

Vernünftige Backuplösungen sind immer örtlich getrennt einzurichten.

Das muss gar nicht teuer sein, aber dann erfordert es eine gewisse 
Disziplin.

Hier wird z.B. alles Wichtige zentral per (Linux-)Sambaserver (sparsamer 
PC mit 400GB-Platte) zur Verfügung gestellt, an den ich dann eine von 
zwei verschlüsselten USB-Platten anstöpsele. Per rsync/ssh und 
selbstgebasteltem Skript erfolgt dann der (inkrementelle) Abgleich 
sowohl mit den Sambaverzeichnissen als auch den anderen Rechnern im 
Netz. Die jeweils neue Version nehme ich dann einmal pro Woche mit und 
tausche diese mit derjenigen im Bankschließfach.

Im Ernstfall kann ich so jeden Rechner innerhalb von 30 Minuten wieder 
ans Laufen bringen. Zusätzlich habe ich alle Versionen der letzten zwei 
Jahre vorliegen.

Wenn es wirklich ganz schlimm kommt (alle Rechner und alle Platten 
defekt), ist also maximal die Arbeit einer Woche verloren.
Damit können wir im Ernstfall leben.

Und ja, das habe ich getestet :-)

Das ist übrigens ganz wichtig: Backuplösungen auch wirklich TESTEN!
Man dachte nur, dass man ein Backup hat - aber es wurden schon seit 
Jahren nur leere verzeichnisse angelegt usw.
Das ist alles schon dagewesen.

rsync gibt es auch für Windows und es ist meiner Meinung nach eines der 
besten und ausgereiftesten Tools für solche Dinge überhaupt.

Bei so etwas verlasse ich mich nicht auf Externe. Es geht hierbei 
schließlich um das Überleben des Unternehmens. So etwas gibt man mMn 
unter gar keinen Umständen aus der Hand.

Chris D.

Peter II schrieb:

> das runter laden mag ja noch gehen, aber wie bekommt man die Daten
> sinnvoll dort hin?

Da sehe ich kein Problem, es wird irgendwelche Clients geben. Wenn die 
Daten eines neu eingerichteten Servers inkrementell anwachsen und nicht 
gleich kübelweise von den PCs abgeladen werden ist das auch von 
Durchsatz und Datenmenge kein Problem.

Aber wenn 250GB über eine 10Mb-Leitung runter geladen werden müssen, 
dann sind das mehrere Tage am Stück. Und man sollte sicher sein, dass 
ein günstigerweise verwendetes Allerwelts-DSL nicht vom Provider 
vorsorglich aufgrund exzessiven Missbrauchs gedrosselt wird.

Ich halte das in einer kommerziellen Umgebung und signifikanten 
Datenmengen mit gewisser Verfügbarkeitsanforderung nur für leidlich 
akzeptabel, wenn der Storage-Provider ggf. einen Restore per 
Turnschuhnetzwerk vorsieht, d.h. USB-Platte per Express.

Chris D. schrieb:
> rsync gibt es auch für Windows und es ist meiner Meinung nach eines der
> besten und ausgereiftesten Tools für solche Dinge überhaupt.

Naja, ich habe von rsync in der Vergangenheit zu viele Coredumps
gesehen, als dass ich mich darauf wirklich verlassen mag. :-/  Kann
sein, dass sie das inzwischen alles repariert haben, aber sowas zeugt
halt nicht gerade von Qualität, die bereits durch das Design vorgegeben
ist.  Dies und die völlig kranke Syntax (es ist ein Unterschied, ob
man auf der Kommandozeile nach einem Verzeichnisnamen noch einen
Schrägstrich schreibt oder nicht, und welche der Varianten was genau
tut, kann sich kein Schwein merken) machen es mir etwas suspekt.

Zu Hause habe ich mittlerweile Bacula laufen.  Geht ganz gut, auch
wenn es mich stört, dass es nicht in der Lage ist, eine Art
bootstrap saveset zu schreiben, der mit natürlichen Werkzeugen des
Betriebssystems (tar, restore) rückgelesen werden kann, sodass man
erstmal wieder ein Bacula braucht für eine recovery from scratch.
Aber in dieser Hinsicht sind kommerzielle Backupsysteme (wie Legato)
auch nicht anders.

Maxim schrieb:
> Oder doch lieber ein Onlinebackup? Z.B. zahlt man für 250GB 50€/Jahr.

Und wer liest das alles noch mit?

Ich mag gern der Herr meiner Daten sein.

Peter II schrieb:

> naja wir haben datenbanken bis 60GB.

Yep, kannste vergessen. Ich dachte eher an die üblichen Allerweltsdaten 
auf Workgroup-Fileservern, wie Briefe, einfach Excel-Sheets und 
dergleichen.

> Die Datei ändert sich ständig. Man
> müsste mit einem binary Diff rangegenen.

Nope, die Wahrscheinlichkeit, dass du den Kram im Desasterfall wieder 
zusammengebacken kriegst geht in Richtung Konkurs.

Jörg Wunsch schrieb:

> Und wer liest das alles noch mit?
> Ich mag gern der Herr meiner Daten sein.

Nur ernst zu nehmen, wenn verschlüsselt.

Jörg Wunsch schrieb:
> Chris D. schrieb:
>> rsync gibt es auch für Windows und es ist meiner Meinung nach eines der
>> besten und ausgereiftesten Tools für solche Dinge überhaupt.
>
> Naja, ich habe von rsync in der Vergangenheit zu viele Coredumps
> gesehen, als dass ich mich darauf wirklich verlassen mag. :-/

Kann ich für mich nicht bestätigen. Damals als Serveradmin (unter 
SunOS/Solaris) habe ich alles per rsync erledigt. Ich hatte in den 15 
Jahren bisher noch keinen einzigen Coredump, weder als Server/Client 
noch als Client/Client-Version

> Kann sein, dass sie das inzwischen alles repariert haben, aber sowas zeugt
> halt nicht gerade von Qualität, die bereits durch das Design vorgegeben
> ist.

Lag vielleicht an Deiner speziellen Version. Wie gesagt, ich hatte weder 
unter SunOS noch Solaris noch Linux damit jemals Probleme.

>  Dies und die völlig kranke Syntax (es ist ein Unterschied, ob
> man auf der Kommandozeile nach einem Verzeichnisnamen noch einen
> Schrägstrich schreibt oder nicht, und welche der Varianten was genau
> tut, kann sich kein Schwein merken) machen es mir etwas suspekt.

Naja, dann dürfte man 90% der Tools nicht verwenden - sage ich als 
vi-Vielnutzer ;-)

Außerdem nutzt man so etwas ja nicht von der Kommandozeile aus: man 
erstellt sich einmal in Ruhe ein vernünftiges Skript und dann vergisst 
man die Optionen wieder (so auch hier geschehen :-).

> Maxim schrieb:
>> Oder doch lieber ein Onlinebackup? Z.B. zahlt man für 250GB 50€/Jahr.
> Und wer liest das alles noch mit?
> Ich mag gern der Herr meiner Daten sein.

Dafür gibt es Verschlüsselung. Aber ich will meine Daten trotzdem sicher 
verwahrt wissen - davon hängt schließlich im Ernstfall mein "Überleben" 
ab. Und das ist nur bei mir selbst gewährleistet.

Chris D.

P.S.: Datenbank-Backups sind im laufenden Betrieb in der Tat ein 
Problem. Hier wird das so "gelöst", dass für die Sicherung der 
MySQL-Server kurz gestoppt und danach wieder angeworfen wird. Da die 
Sicherung eh nicht zu regulären Arbeitszeiten geschieht, ist das kein 
Drama (Sind allerdings auch nur 5GB).

Chris D. schrieb:
>> Kann sein, dass sie das inzwischen alles repariert haben, aber sowas zeugt
>> halt nicht gerade von Qualität, die bereits durch das Design vorgegeben
>> ist.
>
> Lag vielleicht an Deiner speziellen Version. Wie gesagt, ich hatte weder
> unter SunOS noch Solaris noch Linux damit jemals Probleme.

Kann sein, dass FreeBSD da zuweilen eine stärkere Tendenz hat,
schlecht geschriebene Software zum Absturz zu bringen.  Da kann
man beispielsweise festlegen, dass mit malloc() geholter Speicher
mit 0xd0d0d0d0 vorgefüllt wird.  Bei allen anderen Systemen dürfte
die Wahrscheinlichkeit, dass da 0 drin steht, recht hoch sein, und
dann klappt später ein

if (pointer == NULL) {
  /* assign it */
  ...
}

Bei FreeBSD -> Coredump. :)  Gleichfalls für Benutzen bereits wieder
freigegebenen Speichers.

Ja, ich weiss schon, warum mich mit C eine gewisse Hassliebe verbindet.

40 Jahre - und noch immer muss man sich mit so einem Scheiss wie "buffer 
overflow" und "nichtinitialisiertem Speicher" rumschlagen.

Wenn es nicht so traurig wäre, könnte man drüber lachen :-/

Chris D.