GerhardG

könnte es sein das eine firewall die übertragung blockiert?

versuch mal die dateien von hand zu übertragen, bei windows xp ist ein tftp client dabei.

Naja, wenn man beide so benutzt, wie es sein sollte, dann ja. Ansonsten bekommt man ein Band genausoschnell kaputt wie eine HDD.

ich wüßte nicht wie eine platte den freien fall aus 1,5m aushalten soll, ein lto/ait band steckt sowas recht problemlos weg. selbst wenn das gehäuse springen sollte bleiben die daten erhalten.

bei extremfällen wie feuer hast du natürlich recht.

Da vergleichst du grade Äpfel mit Birnen ;)

Klar, eine HDD ist günstiger als ein LTO3 Band, ABER eine HDD braucht kein extra Laufwerk und die sind bei LTO3 noch teuer. Wenn man also dann den Preis/Gig vergleicht ist die HDD deutlich günstiger.

rechne 25x 200/400 lto bänder (etwa 400 euro) und 25x 300gb hdd (etwa 2000 euro). da fehlt nicht mehr viel zum lto2 laufwerk. bei der hdd brauchst du dann immer noch etwas dazu was alle platten aufnehmen kann (zb ein nas), dagegen ist ein lto schon fast geschenkt ;)

ich möchte backup to disk nicht verteufeln, ganz im gegenteil. aber die meinung backup to disk ist viel billiger stimmt nur im kleineren bereich wo zb mit usb platten gearbeitet wird.

Eine reine NAS-Lösung wird da auch irgendwann an ihre Grenzen stossen, da sich die gebräuchlichen NAS-Lösungen auch nicht ewig erweitern lassen.

klar, auch eine bandlösung kann nicht unbegrenzt (wirtschaftlich) erweitert werden. spätestens wenn ein größerer wechsler ansteht kommt man um ein vorgeschaltenes backup to disk kaum mehr herum.

Und bezüglich nur Backup to Disk, am Freitag war ein Versicherungsmensch bei einem Kunden, um dort die IT zu überprüfen (der Kunde ist etwas größer und international tätig) und ht dort beiläufig erwähnt, das die meisten Versicherungen nicht haften, wenn nur eine toDisk-Lösung genutzt wird. Einzigste Ausnahme ist wohl, wenn die Lösung nicht im selben Brandabschnitt, besser noch komplett ausgelagert ist.

Wenn man aber sowas realisiert, reicht eine einfache NAS-Lösung meistens nicht mehr aus, da ein einfaches Auslagern der Disk gar nicht möglich ist.

ein eigener brandabschnitt für einen dasi raum wäre natürlich immer optimal. das angesprochene auslagern der daten halte ich für besonders wichtig, viele vertrauen blind den feuerfesten tresor.

Die meisten toDisk-Lösungen sind auch nur aufgekommen, da moderne Bandlaufwerke eine zu hohe Datentransferrate haben und bei den herkömmlichen Methoden nicht mehr in einen Streamingmode kommen sondern zu viele Start/Stopp-Zyklen haben, was die Lebensdauer der Laufwerke deutlich reduziert.

ack.

Zu diesem Thema gibt es viele Meinungen und auch Ansätze/Ideen, nur sweit es mich betrifft, werde ich immer eine Lösung mit Tape am Ende vorziehen. Das hat zum einen Gründe aus dem Bereich "einfachere Auslagerung von Sicherungen" zum anderen aber auch rechtliche Hintergründe (Aufbewahrungszeiten von Daten und so "super" Erfindungen wie Basel II ode auch Sarbanes-Oxley-Act oder sehr speziell für DE "Grundsätze zum Datenzugriff und zur Prüfung digitaler Unterlagen")

ganz meine meinung.

"nicht personalisierte" daten werden nur dann übertragen wenn DU diese funktion aktivierst. persönliche daten werden aber in keinerlei modi übertragen.

google desktop

ios feiert bald den 30iger ;)

http://de.wikipedia.org/wiki/Internetwork_Operating_System

http://en.wikipedia.org/wiki/CatOS

http://en.wikipedia.org/wiki/Catalyst_switch

ntfsresize aus den freien ntfstools.

Es ist sicherlich richtig, das Bänder aus rein mechanischen Gründen leichter "kaputt" gehen als Festplatten.

verglicher mit einer hdd ist ein band ja schon fast unzerstörbar.

Kein Argument für Bänder ist die Datenmenge. Auf Platten geht einfach mehr drauf.

eine große festplatte hat 250-500gb, ein großes band hat 400-800gb?

Bezüglich der Kosten muss man das differenziert betrachten: eine reinrassige SAN-Lösung über FC ist sicherlich teurer als ein gutes Bandlaufwerk mit Medien. NAS ist da sicherlich billiger.

ein ordentliches nas ist um einiges teurer als die bandsicherung. vergleiche einfach was eine 500gb festplatte und ein 400/800gb lto band kostet. spätestens wenn man mehrere tages/wochen/monats/jahres stände halten muss, wird eine reine nas lösung extrem teuer.

eine platte fällt auf den boden => kaputt

ein band fällt auf den boden => die hülle wird staubig

backup auf nas ist ein recht teurer spaß, des weiteren ist es nicht so einfach das backup sicher zu lagern (brand, hochwasser,...).

warum nicht einfach ein netzlaufwerk verbinden?

mit windows boardmittel => shared storage und jede menge teures zubehör

mit cluster software von dritthersteller => wie unter suse ein schneller lan link und am besten ein zusätzlicher heartbeat

die default config hat keine endung, das passt schon so. im prinzip schaut es schon sehr gut aus, der bootloader wird geladen und er sucht nach einer config.

wird net.img vom tftp geladen, sollte tftpd32 auch anzeiten?

der pxelinux.cfg ordner liegt auch im tftproot?

die datei net.img liegt ebenfalls im tftproot?

die rdp session ist unabhängig von der konsole, die maximale farbtiefe usw kannst du in der terminal service configuration festlegen.

ntfs rechte entziehen, geht recht einfach mit xcals + psexec

ok, ich hab schnell eine komplett abgespeckte version für dich gebastelt. meine umgebung ist etwas komplexer da u.a. ein thinclient os für pxe boot dabei ist.

ich bräuchte kurze ne email adresse, sind etwa 1,1mb.

das ganze funktioniert so, entpacke mein zip in dein tftproot. im dhcp musst du statt des 3com bootloaders (mba.pxe) nun den pxelinux bootloader eintragen (pxelinux.0). wenn du nun einen client via lan startest, sollte mein beigelegtes image booten.

images hinzufügen:

für dos images wird ein mini bootloader namens "memdisk" verwendet, dieser liegt ebenfalls im tftproot. wenn du nun eine funktionierende bootdisk in ein pxe image umwandeln möchtest, musst du nur die diskette mit rawwrite ( http://uranus.it.swin.edu.au/~jn/linux/rawwritewin-0.7.zip ) in eine datei schreiben. dieses image legst du einfach im tftproot ab und hinterlegst den namen der datei in der "default" config datei.

die "default" konfigurations datei liegt im unterordner"pxelinux.cfg". hier kannst du auch beschreibungen oder hilfetexte hinterlegen die beim starten angezeigt werden sollen. als beispiel habe ich eine kleines dos bootimage eingetragen und als image beigelegt (net.img). hier kannst du beliebige viele images hinzufügen und auswählen.

beispiel config:

default dos

prompt 1

timeout 1000000

display pxes.msg

F0 pxes.msg

F1 helpopt.msg

label dos

kernel memdisk

append initrd=net.img

label biosupdate

kernel memdisk

append initrd=biosupdate.img

ganz so schön und einfach ist es auch wieder nicht. damit du entsprechende kurze ausfallszeiten hast brauchst du schon mehr als ein paar vm´s. ohne entsprechende hard- und software geht nichts.

bei teurer hardware würde ich es mir 2x überlegen ob du den deutlich schwächeren virtual server von microsoft verwendest. alleine die hdd i/o ist je nach umgebung um etwa 15% geringer als in vmware. ganz zu schweigen das du mit virtual server anstehst und nicht einfach zu esx wechseln kannst.

du hast pm

wie gesagt, das hat mit linux überhaupt nichts zu tun. du legst wie mit mbutil die dateien am windows tftproot ab und fertig. am dhcp lebst du weiterhin das bootfile fest und der client holt sich alles notwendige via tftp.

ich kann dir gerne meine thinclient umgebung zukommen lassen, weitere bootfiles sollten dann kein problem sein.

nicht vergessen, die erste beta läuft in wenigen tagen aus! der neue build 22088 kann einfach darüber installiert werden, alle settings werden übernommen.

des weiteren ist die vermarktung wie angekündigt frei. ein logischer schritt, insbesondere wo lösungen wie xen den markt komplett aufrollen.

shutdown.exe aus dem resource kit + windows eigenen taskplaner.

das 3com tool ist total veraltet.

am besten nimmst du pxelinux als bootmanager. trotz des namens hat dieser NICHTS mit linux zu tun, er kommt einfach aus der oss ecke. mit pxelinux + memdisk kannst du weit verzweigte menüs erstellen, bilder/hilfe/faq und wwi alles einbinden.

man kann einen dc mit fremdmittel ohne weiteres "clustern", beispielsweise mit vmware/drbd wo die nötigen ads services und datenbanken ebenfalls gespiegelt werden (cold standby). ohne zusätzlichen dc hast du aber beim umschalten min 30 sekunden bis 4-5 minuten keinen dc. des weiteren hilft der beste cluster nicht weiter wenn die partition mit den ad informationen fehlerhaft ist und dieser fehler ebenfalls gespiegelt wird.

cpu ist "unwichtig", hautpsache ram und viel platten i/o. da linux je nach konfig freien ram zum cachen verwendet, kann es hier durchaus zu spürbaren unterschieden kommen. bei richtigen servern kommt dies aber nicht mehr so stark zum tragen.

hast du den debug modul deaktiviert, dieser soll in der beta etwas bremsen?

es gibt seit kurzen übrigens ne neue beta :)

sie wären nicht der erste großkonzern der komplett umstellt. aber da ibm kein reiner linux dienstleister ist, werden sie wohl weiterhin auch windows clients verwenden. aber wohl überall wo möglich, werden sie früher oder später aus kostengründen umstellen.