[SBS] Partitie indeling SBS server

[Operations]

Goed ik heb een testservertje zoals wellicht duidelijk is adhv me overige SBS vragen.

Nu vroeg ik me af wat nou de MS way voor het partitioneren van je Server is.

Heb nu dit:

C:\ Windows
D:\ Exchange / SQL data / Roaming profiles / user folders
E:\ normale data (word e.d.)

Dit heb ik puur gedaan zo van mocht er iets met windows gebeuren staan die dingen op D veilig, maar dat is natuurlijk een XP denkwijze (buiten het feit dat ik ook wel images maak).

Iemand die kan toe lichten hoe het binnen grote bedrijven meestal gedaan wordt?

[CAP-Team]

Bij grote bedrijven heb je vaak voor elke server taak een aparte (viruele) server.
- active directory server
- fileserver
- print server
- exchange server
- database server
- backup server

enz. eventueel redundant uitgevoerd.

Persoonlijk geef ik er de voorkeur aan om de C: partitie van een server op zo'n 20 GB te zetten en de D: partitie voor de data.

In ieder geval het is maar net wat je zelf prettig vind werken

[ Voor 29% gewijzigd door CAP-Team op 22-09-2006 23:36 ]

[djluc]

Ik zou vooral zo proberen te verdelen dat je, mocht je capaciteit tekort komen over een paar jaar, je redelijk simpel een geheel volume kan vervangen. Verder is een splitsing data/systeem fijn.

[Question Mark]

MS adviseert omwege performance redenen ook de page-file op een aparte fysieke (gemirrorde) disk te plaatsen. (let wel, dit is een MS advies, niet de mijne). Over het nut hiervan valt nl. te discussieren.

Wat wel belangrijk is, is om de transaction log files van Exchange en SQL op aparte disken dan de bijbehorende databases te plaaten. Middels deze logfiles kan een gerestorede database teruggebracht worden tot het moment van crashen. Plaats je de logfiles en databases nu op dezelfde disken en deze zouden uitvallen, dan rest niets anders dan een restore en ben je dus data kwijt. Je hebt immers geen logfiles meer die je kunt "replayen".

Bovenstaand zijn uiteraard de guide-lines voor de meest ideale opzet. Je zult zelf moeten bepalen hoe erg het is als er data mist, en of dit opweegt tegen de extra investering in disken.

[djluc]

De performance reden zijn inderdaad discutabel als je het over een server hebt met slechts een paar concurrent users. De MS adviezen zijn in het algemeen niet daarop gericht.

Wat betreft de logs apart houden: Dat is inderdaad wel een goed punt. Je kunt dus in geval van een crash van je raid array op z'n slechts alle data vanaf de laatste backup kwijt zijn.

[aZuL2001]

Het is slim om op de disk waar je exchange db's staan wel de nodige ruimte vrij te houden.
Als je die db's moet recoveren worden ze gekopieerd, en dan baal je als je na veel uren wachten er achter komt dat er geen diskspace genoeg was.

[Question Mark]

djluc schreef op zaterdag 23 september 2006 @ 11:59:
Wat betreft de logs apart houden: Dat is inderdaad wel een goed punt. Je kunt dus in geval van een crash van je raid array op z'n slechts alle data vanaf de laatste backup kwijt zijn.

Goed ingericht is géén data kwijt

Als een disk-array met de databases crasht: Een restore uitvoeren van back-up en het replayen van de logfiles (die er nog zijn aangezien deze op een ander disk-array stonden) is voldoende om de DB up-to-date te brengen.

[Operations]

Dus het is niet zo als je bijvoorbeeld met NTbackup je exchange DB backupped en er gebeurd iets mee dat je deze gewoon netjes met ntbackup terug kunt zetten? Hier heb je dus ook de logfiles voor nodig?

[Question Mark]

Je kunt met NTbackup rustig backuppen en restoren, in dat geval heb je je database gerestored vanaf het moment dat de laatste backup gemaakt is. Als je daarentegen de logfiles nog zou hebben, dan kun door de logfiles te "replayen" de database restoren tot het moment van de crash. Da's het verschil.

In het eerste geval ben je de data tussen de laatste backup en het moment van crashen kwijt. In het tweede geval ben je geen data kwijt.