[2008R2] Disaster recovery AD/Exchange/SQL

[Micoschoft]

Goedemiddag tweakers!

Sinds vandaag ingeschreven op dit forum omdat ik met een probleem zit en wellicht kunnen jullie mij een stapje verder helpen.

Ik werk voor een organisatie waar we netwerkbeheer doen voor bedrijven die te klein zijn om eigen beheerders in dienst te nemen, het MKB dus. Klein begonnen en langzamerhand krijgen we grote en veel eisende klanten.

Voor het geval dat het een keer goed fout gaat, ben ik nu bezig met een disaster recovery oplossing en de bedoeling is dat we zo snel mogelijk weer up en runnning zijn.

Netwerk nu:
SRV01: Win 2008R2, FSMO, GC, Exchange 2010, DFS namespace en replicatie
SRV02: Win 2008R2, GC, SQL, DFS namespace en replicatie

Backup nu:
Beide servers: Online backup, interne windows backup naar USB schijf, VSS.

Disaster recovery (bij brand/instorten hoofdkantoor en beide servers offline):
- SRV01/02 clean install
- DCPROMO
- Exchange installeren
- SQL installeren
- Handmatig gebruikers aanmaken
- Import SQL databases
- EDB extracten naar PST files
- PST import
- Restore userdata

Op deze manier kunnen we alles binnen 1 t/m 3 dagen weer operationeel krijgen (Afhankelijk groote klant).

Nu hebben we een klant, die geld heeft en bereid is te investeren in een recovery oplossing zodat ze binnen 1 dag weer online kunnen zijn. Als ik bovenstaand zou uitvoeren kost het ons zeker 3 dagen omdat het nogal wat data/gebruikers zijn die teruggezet moeten worden.

Conclusie: huidig plan is FAIL.

Wat ik tot nu toe gedaan heb (en tot niets geleid heeft):
Test 1:
- Clean install Windows 2008R2, maak een lege active directory aan en boot in Active Directory restore mode. Met onze online backup oplossing herstel ik de systemstate, restart en blue screen omdat de hardeschijf drivers (andere hardsware) niet aanwezig zijn.

Test2 (theoretisch):
1. LAN to LAN configureren met ons kantoor.
2. 2de SITE aanmaken in active directory in andere subnet
3. SRVREP01 installeren met de volgende functies:
* GC server (AD replicatie)
* DFS replicatie (user profiles; user data; company data)

Nu de recovery:
1. NTDSUTIL: seize FSMO rollen van SRV01 naar SRVREP01
2. remove SRV01/SRV02 uit active directory
3. Clean install SRV01 en toevoegen aan het domein.
4. exchange installeren met commando: setup.exe /m:recoverserver /dc:SRV01
5. online backup: .edb bestanden downloaden en mounten op SRV01
6. Clean install SRV02 en toevoegen aan het domein.
7. SQL installeren
8. online backup: SQL databases downloaden en mounten
9. SRVREP01 toevoegen aan DFS namespace voor beschikbaar maken profiles/USER- Companydata.

Test2 (praktijk)
1. LAN to LAN configureren met ons kantoor.
2. 2de SITE aanmaken in active directory in andere subnet
3. SVRREP01 installeren met de volgende functies:
* GC server (AD replicatie)
* DFS replicatie (user profiles; user data; company data)

Nu de recovery:
1. NTDSUTIL: seize FSMO rollen van SRV01 naar SRVREP01
2. remove SRV01/SRV02 uit active directory
3. Clean install SRV01 en toevoegen aan het domein. [FAIL!!!]

Als ik de server SRVREP01 herstart, verliest deze server zijn SYSVOL en NETLOGON shares en het aanmelden van nieuwe computers/server zal niet meer gaan. Als dit in reallife zou gebeuren hebben we een heel groot probleem.

Wat is een disaster recovery oplossing waarvan je uit kan gaan dat het werkt?

[powerboat]

Virtualiseren en naar een externe locatie syncen ? of iets van HBA

[Micoschoft]

Virtualiseren zal helaas niet gaan, SRV01 en SRV02 kan ik niets aan veranderen.

Wat bedoel je met HBA?

[MarkieNL]

De Windows Server Backup bevat toch ook een optie om naar verschillende hardware te restoren?
Of mag de laatste backup niet van de vorige dag zijn?

[Micoschoft]

Windows server backup kan inderdaad naar andere hardware restoren, maar als er brand uitbreekt heb je die schijven niet meer waar die backups op staan.

Weeklijks schijven omwisselen is geen optie.

Ik heb 2 schijven op kantoor liggen, die zijn nu 2 maanden oud, maar probleem is als ik systemstate terug zet kom ik weer bij het blue screen (TEST1) probleem.

[0fbe]

Waarom maak je geen gebruik van de Exchange 2010 fail-over mogelijkheden? Ook SQL-server 2008 R2 heeft fail-over clustering.

Of je gebruikt een back-up oplossing op een externe locatie waar je binnen 24-uur een image terug kan draaien op de server.

Gezien je huidige disaster recovery plan vraag ik mij af of je jezelf niet eens af moet vragen of je voldoende kennis in huis hebt om dusdanige omgevingen op te zetten.

[johnkeates]

Ik gebruik een waterdicht systeem waarbij ook de redundantie elke 2 dagen getest wordt;

1. Alle servers op een hypervisor draaien, die op zichzelf dan maar 3GB aan ruimte nodig heeft.

Ik gebruik XEN om dat te realiseren. Windows 2008 R2 heeft gewoon bare-metal speed.

2. Alle servers gewoon VSS en Win backup laten draaien naar iSCSI diskje in colo

Ik gebruik BSD in de colo's om iSCSI targets te hebben. Snel, waterdicht, veilig. RAID, met ook weer extra backup server(s)

3. Elke 2 nachten servers om en om down laten gaan (en loggen). Als 1 niet meer up komt stopt de redundancy check, komt er een mailtje en een smsje, ondertussen draait alles nog, en kan ik ondertussen windows debuggen.

Ik doe dat om dat je beter zelf in de gaten kan houden of iets blijft werken als er wat down is, dan het ooit tegen komen en niet zeker weten of het wel goed gaat. Training of geen training, MS cert of geen cert, real cases zijn altijd 'echt'. Theorie helpt tot een bepaald punt.

4. Als een server down is, wordt er via LVM een snapshot gemaakt. Server gaat weer up, snapshot wordt ondertussen naar iSCSI target gestuurd. Als server weer up is, is de volgende aan de beurt (na sync/rep).

3 en 4 zijn niet vereist, snapshots kunnen ook gemaakt worden terwijl systeem 'hot' is.


Mocht er dan wat mis gaan, dan kan er binnen 8 uur een splinternieuwe server draaien. Heb dit op 4 verschillende locaties in nederland gehad, en het werkt. (Hoewel 2 locaties in dezelfde gemeente waren - de andere 2 waren in compleet andere gedeeltes van het land) AD/Exch enz. hebben nergens last van, ook al waarschuwt microsoft voor diverse technieken die hier op lijken. Komt waarschijnlijk door dat er niet van een hibernation achtig systeem wordt uitgegaan.

Bijkomend voordeel is dat er ook op andere (qua hardware) servers geboot kan worden. (Hoewel het wel Intel-gebonden is, gaat niet tussen intel en amd werken) Dus stel dat hardware ooit verouderd wordt, dan kan er op een compleet nieuw systeem direct een nieuwe server instance gestart worden.

Kosten van dit alles:

- software: 0
- hardware: net zo veel als je klant maar nodig heeft
- traffic: afhankelijk van data van klant
- sla: afhankelijk van wat de klant wil qua snelheid van restore

Ik biedt zelf voor single-server ondernemingen een per-incident optie aan, dan hebben ze een 99.98% garantie dat ze binnen 8 uur weer kunnen werken, maar betalen ze minder dan 1000 euro per incident. Dat is een koopje vergeleken met andere bedrijven. BPOS is niet voor elk bedrijf een optie, net als GApps niet altijd mogelijk is. Er zijn hier en daar bedrijven die nog met erg oude software aan de slag zijn die niet op nieuwe hardware wil draaien, daar is dit ook een oplossing voor, om dat je een device model kan maken dat oudere opties biedt. Kost wel 5% performance, maar is altijd sneller, zekerder, en goedkoper dan andere oplossingen.

Wellicht kan je hier wat mee, misschien niet. Bij mijn weten is zijn de procedures die je zo zelf opnoemt vrij algemeen, er is ook niet heel veel tijdsbesparing te doen verder. Wat je wel kan doen is een server in een colo draaien die allen als BDC en dan ook DFS op een of andere manier snel (difftransfers?) linken naar een coloserver. Probleem is een beetje dat DFS via een standaard link niet heel lekker werkt/backupt. Dan zou je aan glas moeten denken, en dat wordt als duur ervaren door het MKB.


Edit:

Zoals diverse mensen melden moet je natuurlijk wel gebruik maken van de al-ingebouwde failover mogelijkheden. Wat ik beschrijf is een overlappende oplossing, maar die is natuurlijk alleen van toepassing als je failover oplossing FAILde. Eerst je 'gewone' netwerk op orde hebben, daarna met je disaster recovery aan de gang. Hoewel mijn oplossing misschien 'disaster recovery recovery' zou moeten heten... Soms heb je het nodig, soms betaalt de klant er goud geld voor.

[ Voor 6% gewijzigd door johnkeates op 22-01-2011 17:45 ]

[Micoschoft]

simplendi schreef op zaterdag 22 januari 2011 @ 17:37:
Waarom maak je geen gebruik van de Exchange 2010 fail-over mogelijkheden? Ook SQL-server 2008 R2 heeft fail-over clustering.

Is hier een extra licentie voor Exchange nodig?

Of je gebruikt een back-up oplossing op een externe locatie waar je binnen 24-uur een image terug kan draaien op de server.

Welke oplossing is hier geschikt voor?

Gezien je huidige disaster recovery plan vraag ik mij af of je jezelf niet eens af moet vragen of je voldoende kennis in huis hebt om dusdanige omgevingen op te zetten.

Inderdaad is dit het punt dat ik hulp van buitenaf nodig heb, microsoft cursussen gaan beginnen. Ook is het zo dat de meeste klanten een downtime van 1 tot 3 dagen niet zo erg vinden en niet willen investeren in een betere oplossing.

[0fbe]

Micoschoft schreef op zaterdag 22 januari 2011 @ 17:45:
[...]

Is hier een extra licentie voor Exchange nodig?


[...]

Je moet daarvoor wel de Enterprise versies van zowel 2008R2 als Exchange 2010 draaien, ja.

Wij gebruiken meestal Ahsay Backup voor Offsite-backup. Deze heeft Exchange ondersteuning zowel op het database als mailbox niveau en ondersteund ook bare-metal restores.

[ Voor 24% gewijzigd door 0fbe op 22-01-2011 17:57 ]

[Micoschoft]

johnkeates schreef op zaterdag 22 januari 2011 @ 17:42:
1. Alle servers op een hypervisor draaien, die op zichzelf dan maar 3GB aan ruimte nodig heeft.

Ik gebruik XEN om dat te realiseren. Windows 2008 R2 heeft gewoon bare-metal speed.

Is dit te realiseren in een productie omgeving?

2. Alle servers gewoon VSS en Win backup laten draaien naar iSCSI diskje in colo

Ik heb ergens gelezen, dat win backup om de 7 dagen een Full backup maakt.
Wat is jou ervaring hiermee? Full backups van 2 servers is meer dan 300GB aan data..

Bied jij deze oplossing ook aan voor externe bedrijven? Afgelopen week is er besproken op kantoor dat we dit soort complexe materie graag willen uitbesteden in de toekomst.

[Micoschoft]

simplendi schreef op zaterdag 22 januari 2011 @ 17:56:
[...]

Je moet daarvoor wel de Enterprise versies van zowel 2008R2 als Exchange 2010 draaien, ja.

Wij gebruiken meestal Ahsay Backup voor Offsite-backup. Deze heeft Exchange ondersteuning zowel op het database als mailbox niveau en ondersteund ook bare-metal restores.

Hier hebben we gelijk al een punt.
Windows is 2008 standaard, en 2010 ook.

[0fbe]

Micoschoft schreef op zaterdag 22 januari 2011 @ 17:56:
[...]

Is dit te realiseren in een productie omgeving?

Natuurlijk is dat te realiseren... (Alhoewel ik de oplossing van johnkeates met 2 dagelijks reboots, niet zo'n goed idee vind, je hebt namelijk momenten waarop je redundantie (onnodig) 0 is.)

[...]

Ik heb ergens gelezen, dat win backup om de 7 dagen een Full backup maakt.
Wat is jou ervaring hiermee? Full backups van 2 servers is meer dan 300GB aan data..

Bied jij deze oplossing ook aan voor externe bedrijven? Afgelopen week is er besproken op kantoor dat we dit soort complexe materie graag willen uitbesteden in de toekomst.

De Windows Backup is zelf in te delen in incrementieel en differentieel...

[ Voor 4% gewijzigd door 0fbe op 22-01-2011 18:00 ]

[Micoschoft]

simplendi schreef op zaterdag 22 januari 2011 @ 17:59:
De Windows Backup is zelf in te delen in incrementieel en differentieel...

Is het dan mogelijk om een NAS bij ons op kantoor te plaatsen, daar de full backups op te zetten (van 2 maanden oud)

en met VSSADMIN en windows scheduler iedere avond een incrementele backup weg te laten schrijven?

[johnkeates]

Ik heb die oplossing sinds 2007 in productie draaien, en tot nu toe geen last mee gehad. Windows 2008 R2 moet wel testsiging aan hebben staan om dat er geen certificaat beschikbaar is voor de paravirtualisatiedrivers, maar dat is geen probleem verder. Mocht een klant dat willen, kan er altijd een ondertekende driver geregeld worden, maar dat kost natuurlijk geld. Op het moment draaien er 12 van dit soort opstellingen door nederland, en een in griekenland.

Windows backup kan je zo instellen als je zelf wil, dus stel dat je alleen databackups wil hebben en de full backups zelf wil doen, dan is dat geen probleem. Qua backup grootte heb ik zelf ±500GB aan data per server, maar de meeste klanten komen niet boven de 4TB uit, dus heb je aan een 6TB RAID6 Array genoeg op de iSCSI target server. Probleem is wel dat je een flinke upload lijn nodig hebt, hoewel dat tegenwoordig niet zo'n probleem meer is. Stel dat een snelle upload naar colo niet beschikbaar is, dan maak je gewoon de incrementiele backups direct naar je colo, en de full backups gewoon aan de lopende band (via snapshots) zodra ze klaar zijn. Dus stel dat de hypervisor 3 dagen aan het uploaden is, dan heb je elke 3 dagen een full backup. Wil de klant meer, dan betaalt de klant maar eerst voor een snellere lijn.

Verder bied ik deze oplossing aan mijn eigen klanten aan, dat is vooral om dat ik liever volledig beheer heb, om dat het anders zo lastig te bepalen is of iemand anders iets veranderd heeft. Logboeken zijn leuk, maar worden niet altijd netjes gebruikt naar mijn ervaring.

Stel dat de een vergelijkbare oplossing nodig hebt, dan kan ik je wel aanwijzingen geven, of misschien een configuratie naar een server naar keuze maken, maar echt veel tijd kan ik er niet in stoppen, om dat mijn eigen klanten en bedrijf vrij veel aandacht nodig hebben. Er zijn altijd weer mensen die nieuwe dingen willen, of die kopjes koffie over printers en patchkasten gooien...

Als je trouwens wil uitbesteden kan je misschien ook meteen kijken naar terminal achtige oplossingen zonder lokale server. Microsoft biedt dat aan, maar er is ook de mogelijkheid om je servers gewoon in colo's te dumpen en dan de klanten lekker op afstand te laten werken. Sommige willen dat niet (data in eigen huis e.d., willen ook altijd LUKS op de colo servers hebben, met eigen sleutels) en dan kan dat dus niet.


Edit: redundantie is nooit 0, om dat je om het zo te zeggen in een dependency chain werkt. Als de server niet up & synced/repped is stopt de automatische controle, en wordt dat aan de sysadmin groep gemeld. Is nog nooit voor gekomen, maar ik snap je punt. Bovendien (ik weet niet of ik dat goed geschreven had) is het ook niet zo dat het 2x per dag is, maar ik bedoelde ter illustratie 1x per 2 dagen. Het is ook optioneel, maar voor een consistentere backup/snapshot wel voordelig.

[ Voor 9% gewijzigd door johnkeates op 22-01-2011 18:13 ]

[rookie no. 1]

Gewoon af en toe een DISK2VHD maken van de servers en buiten het pand bewaren. Samen met online backup (en een snelle internet-verbinding) ben je redelijk rap weer online. Wel belangrijk dat de online backup ook eventuele database goed kan meenemen.

Voordeel van een DISK2VHD is dat je vanaf moment van brand/diefstal ofzo gelijk een change in hardware kan krijgen en met Hyper-V je VHD's kan gebruiken.

[0fbe]

Micoschoft schreef op zaterdag 22 januari 2011 @ 18:05:
[...]

Is het dan mogelijk om een NAS bij ons op kantoor te plaatsen, daar de full backups op te zetten (van 2 maanden oud)

en met VSSADMIN en windows scheduler iedere avond een incrementele backup weg te laten schrijven?

Windows Back-up kan geen incrementele back-ups naar netwerkschijven maken. Wel kan je een schijf via iSCSI mounten en daarop incrementieel backuppen. Daarvoor zal je echter wel een eigen glasvezel of tunnel naar het kantoor moeten hebben om veiligheid van je data te garanderen.

[Micoschoft]

Bedankt voor jullie reactie tot zover:

Korte termijn oplossingen die ik kan doen is dus:
1. iSCSI mounten naar een SAN op ons kantoor. Hiermee kan ik met Windows backup iedere avond incrementele backup en in 1x per week differentiele backup naar de SAN op kantoor wegschrijven.

voordeel hiervan is; Windows server backup restore werkt goed en heb hier meerdere malen mee getest en weet hoe het werkt.
Hoe zit het met corruptie van backup bestanden, is er een tool die VSSADMIN bestand op corruptie kan controlleren?

2. DISK2VHD image maken, deze opslaan op kantoor.

Mocht er iets fout gaan, neem ik aan dat ik de systemstate in een Hyper-V omgeving wel gewoon gerestored kan worden (laatste versie van active directory).

En online backup restore gebruiken om laatste data terug te krijgen.

Een oplossing op langere termijn zoals John beschrijft, voordeel hiervan is dat elke 2 dagen ook getest wordt of er een restore mogelijk zou zijn.

[Razwer]

DR plannen zijn nou eenmaal duur. Je zal bij een goede oplossing toch wat geld kwijt zijn aan licenties en evt hardware.
Ik zou eens goed lezen over DAG (exchange) met evt een replay lag time
en logship voor SQL
evt een investering in DPM zou ook niet verkeerd zijn.

een goede DR design je niet in een paar tellen en er zijn vele wegen die naar rome leiden.

[johnkeates]

Een ding klopt niet, licenties en hardware zijn geen garantie en ook geen noodzaak bij goede oplossingen. Kennis daarentegen wel. Dat moet je hebben, hoe dan ook, om welke oplossing dan ook aan te bieden. Dit post ik meer om Razwer's post wat te relativeren, dan om een oplossing voor de TS te maken, want die heeft zijn antwoorden al (grotendeels) gevonden. Stel dat iemand hier terecht komt, dan is dat wel goed om te weten.

[elevator]

johnkeates schreef op zaterdag 22 januari 2011 @ 17:42:
3. Elke 2 nachten servers om en om down laten gaan (en loggen). Als 1 niet meer up komt stopt de redundancy check, komt er een mailtje en een smsje, ondertussen draait alles nog, en kan ik ondertussen windows debuggen.

Ik doe dat om dat je beter zelf in de gaten kan houden of iets blijft werken als er wat down is, dan het ooit tegen komen en niet zeker weten of het wel goed gaat. Training of geen training, MS cert of geen cert, real cases zijn altijd 'echt'. Theorie helpt tot een bepaald punt.

4. Als een server down is, wordt er via LVM een snapshot gemaakt. Server gaat weer up, snapshot wordt ondertussen naar iSCSI target gestuurd. Als server weer up is, is de volgende aan de beurt (na sync/rep).

De reden dat Microsoft het niet ondersteunt om image-level backups terug te zetten van AD, of dat nou via LVM of een harddisk-level image tool is, is dat je kan hebt dat je een USN rollback creeert, niet omdat Microsoft je wil pesten in jouw gedachtengang

Lees je eventjes in over USN rollback en vraag je daarna goed af of dit nog steeds is wat je wilt

[Razwer]

johnkeates schreef op zondag 30 januari 2011 @ 05:18:
Een ding klopt niet, licenties en hardware zijn geen garantie en ook geen noodzaak bij goede oplossingen.

niet geheel mee eens dat het geen noodzaak is. we praten nu wel heel globaal maar in 9 van de 10 gevallen zal er een stuk hardware (server, storage, tapedrive, tape, offsite backup iets, extra capaciteit op datalijn etc) en/of licenties (backupsoftware, server licenties, applicatie licenties) bij een gemiddeld DR plan moeten worden aangeschaft.
Uiteraard is dit niks waard zonder de juiste kennis.

[Question Mark]

simplendi schreef op zaterdag 22 januari 2011 @ 17:56:
[...]

Je moet daarvoor wel de Enterprise versies van zowel 2008R2 als Exchange 2010 draaien, ja.

Exchange 2010 standard kan ook opgenomen worden in een DAG.

[Jazzy]

Het idee van disaster recovery is dat je de bestaande omgeving een andere plek weer in de lucht krijgt. Als je dat wilt voor een simpele opstelling met twee servertjes dan doe je het volgende:
- Ga een echt backuppakket gebruiken
- Zorg dat je kunt restoren naar andere hardware (moet je soms een apart product of licentie voor aanschaffen)
- Backup naar iets wat je buiten het pand legt (tape danwel USB disks)

Daarvoor hoef je dus niets aan de bestaande servers te veranderen. Stel dat er nu ingebroken wordt oid. dan moet je het volgende doen:
- Plaats twee nieuwe/andere servers
- Restore van backup

En de sleutel hierbij is testen, testen en testen. Mits goed beschreven kun je zo prima binnen pakweg 24 uur terug in de lucht zijn.

- EDB extracten naar PST files
- PST import

Dat zijn de opties voor als je het compleet verneukt hebt, dat kan nooit onderdeel zijn van een DR procedure.

[Razwer]

Question Mark schreef op maandag 31 januari 2011 @ 09:58:
[...]

Exchange 2010 standard kan ook opgenomen worden in een DAG.

Windows Standard daarintegen niet.

[Jazzy]

Dat werd ook niet beweerd.

[Razwer]

Jazzy schreef op maandag 31 januari 2011 @ 21:31:
Dat werd ook niet beweerd.

true, nadat ik postte zag ik dat het een spuit 11 reactie was. excuus

[ninjazx9r98]

Geen direct antwoord op je vragen maar houdt er rekening mee dat disaster recovery veel meer is dan alleen een technische oplossing waar je nu vragen over hebt.
De technische oplossing is nog de meeste simpele van het verhaal, organisatorisch komt er ook nog heel wat bij kijken.
Je noemt één dag om weer online te zijn, is dat één werkdag, is dat één dag van 24 uur?
Kan/mag er 24 uur per dag gebeld worden bij een disaster?
Waar gaat men naartoe bellen?
Krijg je te maken met standby diensten plus vergoeding?
Je hebt het over 'we', zijn dat genoeg mensen om ook binnen één dag online te kunnen zijn in de vakantieperiode?
Hoe vaak ga je testen of de gekozen oplossing nog steeds werkt/voldoet?

Voor wat betreft techniek wil je bij voorkeur een situatie creëren die de productieomgeving zo dicht mogelijk benadert.
Schone installatie van OS plus applicatie moet je in principe niet willen, je mist specifieke aanpassingen aan OS en applicaties, mogelijke 'registerhacks', patches, servicepacks, scripts enz enz enz.
Uiteraard kun je dat allemaal documenteren en vervolgens een soort van stappenplan doorlopen maar dat zal gruwelijk veel tijd gaan kosten om nog maar niet te spreken over nauwkeurig bijhouden van alle changes in de loop der tijd.

Heb je er trouwens al aan gedacht dat DNS aangepast moet worden zodat de exchange server ook daadwerkelijk wat kan gaan doen op een alternatie locatie?
En wat te doen met de firewall die er ongetwijfeld ook tussen zit?

Hoe langer je nadenkt over disaster recovery, hoe meer zaken je kunt verzinnen die goed geregeld dienen te zijn om binnen relatief korte tijd weer online te zijn en dat gaat zoals gezegd veel verder dan alleen techniek.