[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Heimserver Stromverbrauch und Fileserver


Hi,

Am Montag, 4. Dezember 2006 14:04 schrieb Marc Haber:
> On Mon, Dec 04, 2006 at 01:53:46PM +0100, Markus Hochholdinger wrote:
> > Am Montag, 4. Dezember 2006 10:50 schrieb Marc Haber:
[..]
> Nicht im untersten Preissegment; ausserdem habe ich einige "normale"
> Server in "Freundschaftshousing".

uh, dann scheine ich mich in diesem untersten Preissegment nicht zu bewegen.


> Ausserdem muss ftp schnellstmoeglich sterben.

Da bin ich voll Deiner Meinung!


> >  Ich bin mittlerweile dazu uebergegangen nur das System (normalerweise
> >  so um die 1 bis 4 GB) lokal zu packen und das tgz auf den ftp-Server
> >  zu schieben.
> Nicht verschluesselt? Und wie schuetzt Du Dich gegen einzelne Bitkipper?

Den ftp-Server sehe ich als genauso sicher an wie die lokalen Festplatten (wer 
weiss wo seine _kaputte_ Festplatte mal eingebaut wird!). Meistens ist der 
ftp-Server ueber ein eigenes Netzwerk erreichbar. Bei Bitkippern habe ich da 
natuerlich verloren.
Wo es geht setze ich rsync ueber ssh ein. Da habe ich zumindest Verschluesselung 
und je nach Festplattenkapazitaet auf dem Ziel-Host auch eine Versionierung.


> >  Hierbei
> >  muss man aufpassen dass ein evtl. externer Server eine schlechtere
> >  Anbindung hat und das kopieren ziemlich lange dauern kann.
> Genau, da klassische ADSL-Problem.

Yep.


> > Meiner Meinung nach gibt es auch mehrere unterschiedliche Ziele beim
> > Backup-Konzept die es zu beachten gibt:
> > 1. File-Recovery: $USER loescht _ausversehen_ $DATEI und will diese in
> > einer moeglichst aktuellen Version wieder haben. Das ist meiner Meinung
> > nach die haeufigste Nutzung eines Backups.
> > 2. Desaster-Recovery: Das System nach einem Totalausfall moeglichst
> > schnell wieder zum Laufen bringen (ist normalerweise der seltenste Fall
> > aber der wichtigste!).
> > 3. Archiving: Daten _muessen_ einen bestimmten Zeitraum extern archiviert
> >    werden. Wichtig fuer spaetere Rechtsansprueche Dritter (war zum Zeitpunkt
> > X etwas verbotenes auf der Webseite Y gestanden).
> Ja. Ich habe dazu schon im Usenet mal was geschrieben, siehe
> <ejppfk$cf7$1@xxxxxxxxxxxxx> in de.comm.provider.server.

Aje, da kommen ja gleich noch die Faktoren Datenverschluesselung auf der 
Festplatte hinzu plus effektive Bandbreitennutzung.
Das mit dem verschluesselten Backup kommt erst ganz langsam hier bei meinen 
Kunden an. Allerdings noch in einer ganz harmlosen Ausfuehrung, naemlich 
dahingehend dass die Daten auf Band verschluesselt sind. Die Verschluesselung 
bei der Generierung des Backups hat noch keiner im Blickfeld und will diese 
auch nicht im Blickfeld haben. Sprich: "Per Definition sind die verwendeten 
Server sicher." Bzw. der Aufwand fuer eine _sichere- Loesung ist den Kunden 
(noch) zu hoch.


> In Kommerziellen Umgebungen immer wieder gerne genommen ist "Ja, wir
> sollten mal ein Desaster Recovery zur Uebung fahren um unsere Prozesse
> zu verifizieren, aber die dazu notwendige Hardware wurde nicht
> genehmigt."

Ja, genau. Die IT-Manager koennen soetwas halt nur schwer in Zahlen fassen! 
Also sind es einfach _unnoetige_ Ausgaben.


> > Mich wuerde auch interessieren wie andere mit dem Thema Backup externer
> > Server umgehen!? Vorallem wie ihr den normalerweise vorhandenen
> > ftp-Backup-Space nutzt?
> Bei Alturo hatte ich etwas selbst gestrickt mit afio, gpg und
> ncftpput, wuerde mir aber heute eher duplicity angucken und ggf. mal
> gucken, wie man tar parametrieren muss, damit ein einzelner Bitkipper
> nicht den ganzen Rest der Datei zerstoert.
> Mein Wunsch waere etwas, zu dem ich rdiff-backup und rsync machen kann
> und ausser mir niemand an die Daten kommt.

Fuer $KUNDE bedeutet das immerhin ein enormer Aufwand, schon alleine die 
Schluesselverwaltung! Und damit meine ich: Wo ist der Schluessel fuer die 
Verschluesselung (das ist noch der einfache Part) und wo ist der Schluessel fuer 
die Entschluesselung, wer darf diesen benutzen und wie bekommt man trotzdem 
kurze Restore-Zeiten hin!? Und wenn es dann noch um die Verschluesselung der 
Dateisysteme geht kommt man zu dem Problem wie mit einem Reboot umgegangen 
wird.
Da kommt noch was auf mich zu...


-- 
Gruss
                                                          \|/
       eMHa                                              (o o)
------------------------------------------------------oOO--U--OOo--
 Markus Hochholdinger
 e-mail  mailto:Markus@xxxxxxxxxxxxxxxxx             .oooO
 www     http://www.hochholdinger.net                (   )   Oooo.
------------------------------------------------------\ (----(   )-
                                                       \_)    ) /
                                                             (_/



-- 
http://mailman.uugrn.org/mailman/listinfo/uugrn