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; außerdem habe ich einige "normale"
> Server in "Freundschaftshousing".

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


> Außerdem muss ftp schnellstmöglich sterben.

Da bin ich voll Deiner Meinung!


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

Den ftp-Server sehe ich als genauso sicher an wie die lokalen Festplatten (wer 
weiß wo seine _kaputte_ Festplatte mal eingebaut wird!). Meistens ist der 
ftp-Server über ein eigenes Netzwerk erreichbar. Bei Bitkippern habe ich da 
natürlich verloren.
Wo es geht setze ich rsync über ssh ein. Da habe ich zumindest Verschlüsselung 
und je nach Festplattenkapazität 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 löscht _ausversehen_ $DATEI und will diese in
> > einer möglichst aktuellen Version wieder haben. Das ist meiner Meinung
> > nach die häufigste Nutzung eines Backups.
> > 2. Desaster-Recovery: Das System nach einem Totalausfall möglichst
> > schnell wieder zum Laufen bringen (ist normalerweise der seltenste Fall
> > aber der wichtigste!).
> > 3. Archiving: Daten _müssen_ einen bestimmten Zeitraum extern archiviert
> >    werden. Wichtig für spätere Rechtsansprüche 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@news1.tnib.de> in de.comm.provider.server.

Aje, da kommen ja gleich noch die Faktoren Datenverschlüsselung auf der 
Festplatte hinzu plus effektive Bandbreitennutzung.
Das mit dem verschlüsselten Backup kommt erst ganz langsam hier bei meinen 
Kunden an. Allerdings noch in einer ganz harmlosen Ausführung, nämlich 
dahingehend dass die Daten auf Band verschlüsselt sind. Die Verschlüsselung 
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 für eine _sichere- Lösung ist den Kunden 
(noch) zu hoch.


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

Ja, genau. Die IT-Manager können soetwas halt nur schwer in Zahlen fassen! 
Also sind es einfach _unnötige_ Ausgaben.


> > Mich würde 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, würde 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 zerstört.
> Mein Wunsch wäre etwas, zu dem ich rdiff-backup und rsync machen kann
> und außer mir niemand an die Daten kommt.

Für $KUNDE bedeutet das immerhin ein enormer Aufwand, schon alleine die 
Schlüsselverwaltung! Und damit meine ich: Wo ist der Schlüssel für die 
Verschlüsselung (das ist noch der einfache Part) und wo ist der Schlüssel für 
die Entschlüsselung, wer darf diesen benutzen und wie bekommt man trotzdem 
kurze Restore-Zeiten hin!? Und wenn es dann noch um die Verschlüsselung der 
Dateisysteme geht kommt man zu dem Problem wie mit einem Reboot umgegangen 
wird.
Da kommt noch was auf mich zu...


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


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