Meest optimale backupstructuur voor server

[Verwijderd]

We hebben hier een server met een RAID 10 setup (4x 750 GB, die in 2x 1,5TB staan). De RAID array wordt softwarematig geregeld via de disk utility van OSX Leopard server. Zo'n mirrored RAID is erg veilig qua HD uitval echter is er helaas een paar maanden terug de hele raid array op z'n kop gegaan (lang verhaal).

We hebben naast de RAID 10, ook 2 externe schrijven die beide 1,5 TB zijn (extern1, extern2). Ik heb zelf wel een idee wat een goede backup structuur is, maar ik hoor graag van anderen advies wat een mogelijke betere setting zou zijn.

Mijn idee is als volgt:
De 1.5 TB RAID array elke nacht backuppen naar een extern1. Extern2 ligt offsite. En dan ééns per week extern1 en extern2 omwisselen.

Volgens mij is zo alles wel afgevangen:

• Als een HD kapot gaat, kunnen we een extra 750GB schijf die hier ligt, erin stoppen. Er kan tussentijds gewoon doorgewerkt worden
• Als de RAID array op z'n gat gaat, ligt er een dag oude backup klaar om direct ingeplugd te worden en kan verder worden gewerkt.
• Als het pand afbrandt, is er nog een week oude backup.

De hoeveelheid schijfruimte om die 1.5TB in de lucht te houden is wel behoorlijk groot: 6,75 TB. 5x0,75 (RAID10 + extra schijf) + 2x1,5TB (extern1, extern2). RAID5 is een optie om meer ruimte te creeeren, maar er gaat veel snelheid verloren als een schijf kapot gaat en rebuilden is ook niet heel snel. Heb daar echter niet bijster veel ervaring mee, maar volgens mij is dat ook niet verstandig softwarematig te gaan doen.

Maar misschien zie ik mogelijkheden over het hoofd? Extra tips en adviezen zijn dus meer dan welkom! Vandaar ook dit topic.

[Eximius]

Extern als in USB?
Dat gaat dan wel even duren iedere nacht om 1,5TB erheen te pompen?

[Verwijderd]

FireWire. En hoeft niet de volledige 1.5TB natuurlijk, enkel de geupdate bestanden.

[Seth4Chaos]

Verwijderd schreef op maandag 22 juni 2009 @ 12:45:
We hebben hier een server met een RAID 10 setup (4x 750 GB, die in 2x 1,5TB staan). De RAID array wordt softwarematig geregeld via de disk utility van OSX Leopard server. Zo'n mirrored RAID is erg veilig qua HD uitval echter is er helaas een paar maanden terug de hele raid array op z'n kop gegaan (lang verhaal).

We hebben naast de RAID 10, ook 2 externe schrijven die beide 1,5 TB zijn (extern1, extern2). Ik heb zelf wel een idee wat een goede backup structuur is, maar ik hoor graag van anderen advies wat een mogelijke betere setting zou zijn.

Mijn idee is als volgt:
De 1.5 TB RAID array elke nacht backuppen naar een extern1. Extern2 ligt offsite. En dan ééns per week extern1 en extern2 omwisselen.

Volgens mij is zo alles wel afgevangen:

• Als een HD kapot gaat, kunnen we een extra 750GB schijf die hier ligt, erin stoppen. Er kan tussentijds gewoon doorgewerkt worden
• Als de RAID array op z'n gat gaat, ligt er een dag oude backup klaar om direct ingeplugd te worden en kan verder worden gewerkt.
• Als het pand afbrandt, is er nog een week oude backup.

goeie setup lijkt me zo.

Ik weet niet hoe je die wissel wilt doen maar als je eerst de offsite disk on-site haalt dan is er een moment dat al je backups on-site zijn, dit hoeft niet erg te zijn maar kan wel (vliegtuig crash op je gebouw?). Gewoon iets om rekening mee te houden.

De hoeveelheid schijfruimte om die 1.5TB in de lucht te houden is wel behoorlijk groot: 6,75 TB. 5x0,75 (RAID10 + extra schijf) + 2x1,5TB (extern1, extern2). RAID5 is een optie om meer ruimte te creeeren, maar er gaat veel snelheid verloren als een schijf kapot gaat en rebuilden is ook niet heel snel. Heb daar echter niet bijster veel ervaring mee, maar volgens mij is dat ook niet verstandig softwarematig te gaan doen.

Het ligt er aan hoe waardevol die informatie is en hoe lang je offline mag/wilt/kunt zijn om te bepalen of die hoeveelheid schijfruimte het waard is.

Overigens heb ik hier gehad dat raid5 sneller was dan raid1 (ook met lezen). Dit was wel een hardware-raid oplossing. De enige manier om hier achter te komen is een disk-test te doen met beide opstellingen. Maar als ik het zo hoor is het al een live situatie en dan wordt dit moeilijk.

Maar misschien zie ik mogelijkheden over het hoofd? Extra tips en adviezen zijn dus meer dan welkom! Vandaar ook dit topic.

dit soort keuzen hangt erg veel af van hoe waardevol zijn de gegevens en hoe lang mag/kan/wil je offline zijn bij bepaalde situaties (HD crash, servercrash, gebouw afgebrand).

[Verwijderd]

Thx voor de fijne reactie!

Seth4Chaos schreef op maandag 22 juni 2009 @ 15:44:
Ik weet niet hoe je die wissel wilt doen maar als je eerst de offsite disk on-site haalt dan is er een moment dat al je backups on-site zijn, dit hoeft niet erg te zijn maar kan wel (vliegtuig crash op je gebouw?). Gewoon iets om rekening mee te houden.

Er is idd een moment dat alles on-site is. Vinden we niet erg aangezien dit maar max een paar uur is en ik naast de schijf zit.

Het ligt er aan hoe waardevol die informatie is en hoe lang je offline mag/wilt/kunt zijn om te bepalen of die hoeveelheid schijfruimte het waard is.

De data is van vitaal belang voor het bedrijf. Dat het beschikbaar is ook, aangezien zodra het niet beschikbaar is, niemand meer kan werken. Iedereen werkt namelijk met de bestanden op de server.

Als anderen nog inzichten hebben in bovenstaande situatie, graag!

[Wouter.S]

Ik ben totaal geen expert in raid/servers/backup zaken maar de setup die je daar hebt staan lijkt mij een veilige setup. Als ik hoor dat de data cruciaal is plus dat de offline time klein moet zijn lijkt het mij niet echt aangeraden veel wijzigingen door te voeren. Het werkt en het is veilig, dat het wat schijven kost is niet echt problematisch toch? Tenzij je natuurlijk meer ruimte nodig hebt, dan moet je de zaken wel anders regelen.

Als je je ook nog tegen vliegtuigcrashen wilt beschermen kan je eventueel nog een derde 1.5TB schijf kopen om telkens nog een schijf off-site te hebben. Dit lijkt mij wel een beetje overdone maar kom

[Verwijderd]

Verwijderd schreef op maandag 22 juni 2009 @ 16:26:
Thx voor de fijne reactie!


[...]

Er is idd een moment dat alles on-site is. Vinden we niet erg aangezien dit maar max een paar uur is en ik naast de schijf zit.


[...]

De data is van vitaal belang voor het bedrijf. Dat het beschikbaar is ook, aangezien zodra het niet beschikbaar is, niemand meer kan werken. Iedereen werkt namelijk met de bestanden op de server.

Als anderen nog inzichten hebben in bovenstaande situatie, graag!

ik zou een tweede externe schijf gebruiken als offsite backup. met zoiets sipels als een stroompiek op het net zou de pc al de geest kunnen geven, inclusief de randapparatuur. En dat is nou juist waar de backup voor zou willen hebben?

[LuckY]

Schijven als offsite backup ?Firewire externe schijven?
Koop een fatsoenlijke tapedrive USB diskjes zijn niet bestand tegen meervoudig vervoeren en vooral niet voor 24/7 gebruik.
Wij hadden meerdere Freecom Datatank 1 TB Die als tijdelijk opslag diende in de server ruimte.
Deze hadden een verhuizing niet overleefd 3 van de 5 (300 Meter verder). Ik zou echt zoeken naar _goede_ hardeschijf met een goede garantie. Maar liever tapes (minder bewegende onderdelen goede mogelijkheden tot encrypten.
Want hoe ga je met de beveiliging om, wordt het met een passphrase gedaan of encryptie?

En een RAID is GEEN Backup dat is een synchronisatie. Als jij een RAID 10 hebt, en je krijgt een error in een systemfile wordt die error ook gemirrored naar je andere schijven.
Een raid werkt alleen tegen het Fysiek kapot gaan van de schijf.

En hoe doe je de het versie beheer? Ik weet niet waar de backup voor dient maar als mijn hoster/systeembeheerder niet een specifieke file kan terug vinden .....
Als jij om maandag een file maakt en je delete hem dinsdag en je hebt hem maandag weer nodig heb jij dat bestand niet meer.

[ Voor 13% gewijzigd door LuckY op 22-06-2009 17:04 ]

[alt-92]

LuckyY schreef op maandag 22 juni 2009 @ 17:01:
Een raid werkt alleen tegen het Fysiek kapot gaan van de schijf.

*uitvallen van een schijf*.
Zelfs een draaiende kapotte schijf kan je datacorruptie op je RAIDset opleveren met een beetje pech.

[Tsurany]

Erg slecht backup systeem lijkt me. De data is van vitaal belang, zonder data kan niet gewerkt worden. Valt je server weg dan ben je volledig afhankelijk van twee externe hardeschijven waarvan 1 niet direct beschikbaar is en het recoveren van anderhalf terrabyte van die andere schijf lang gaat duren. Het gaat je zeker een dag duren puur om te recoveren van die externe schijf.

[Question Mark]

Verwijderd schreef op maandag 22 juni 2009 @ 12:45:
Mijn idee is als volgt:
De 1.5 TB RAID array elke nacht backuppen naar een extern1. Extern2 ligt offsite. En dan ééns per week extern1 en extern2 omwisselen.

Volgens mij is zo alles wel afgevangen:

• Als de RAID array op z'n gat gaat, ligt er een dag oude backup klaar om direct ingeplugd te worden en kan verder worden gewerkt.
• Als het pand afbrandt, is er nog een week oude backup.

Verwijderd schreef op maandag 22 juni 2009 @ 14:36:
FireWire. En hoeft niet de volledige 1.5TB natuurlijk, enkel de geupdate bestanden.

Hoe wil je gaan restoren als je continue een incremental backup uitvoerd naar hetzelfde (of twee) medium(s)?

Bij een incremental backup heb je een full backup nodig plus alle daarna uitgevoerde incremental backups. Kies dan voor een differential backup: maak éénmalig een full backup plus dagelijks een differential. Dan heb je genoeg aan je full plus laatste diff voor een full restore...

Edit:

Tenzij je van plan bent om te "backuppen" middels een kopieer-achtige actie. In dat geval hoeven inderdaad alleen maar de gewijzigde bestanden gekopieerd te worden, maar dient wel de volledige 1.5 TB aan data vergeleken te worden. Mocht je middels een kopieeractie willen backuppen: hoe ga je om met open files?

[ Voor 12% gewijzigd door Question Mark op 23-06-2009 08:02 ]

[Verwijderd]

hmmm ik vind dit altijd heel eng worden ... vooral als ik hier iets van een osx server lees. No offence maar ik zou er mijn bedrijf niet op durven draaien. De reden is dat apple nogal eenvoudig over sommige zaken denkt en zodoende de gebruikers schijnbaar ook.

Ik gok dat je huidige disk's SATA disken zijn. Deze zijn niet gemaakt voor een productie omgeving, bij een beetje belasting zakt de performance drastisch in elkaar. Heb je wel eens getest als je een disk vervangt uit je raid set hoe lang de rebuild tijd is ? En wat de performance inpackt hiervan is ? Hoe snel kunnen de mensen nog werken en wat gebeurt er wanneer de nog goede disk overlijd ? Ja een ongeluk komt nooit alleen.

Als je server uitvalt en er lopen 5 man een dag uit hun neus te eten was het misschien handiger om wat extra geld te investeren in een RAID 6 disk setje, SAS wel te verstaan. Door de kleinere disken is je rebuild tijd korter en SAS disken kunnen een hogere I/O load aan waardoor je geen echt grote performance dip krijgt bij een rebuild.

Verders zoals boven al was vermeld harddisken zijn geen backup medium !!! Koop een fatsoenlijke tapedrive iets a la LTO3 of 4. En maak een goed roterend backup schema met de tapes op een veilige locatie ver weg bij je server. Sommige banken schijnen niet zoveel geld meer te hebben dus misschien hebben ze nog wat ruimte in hun kluis.

Test je backup en RESTORE plan en kijk of het voldoet. En ga shoppen bij een serieuze hardware fabrikant welke verstand hebben van servers bouwen, 's werelds grootste is zo slecht nog niet, zij leveren alles wat je nodig hebt, zelfs tot debian software aan toe voor server monitoring. Ik neem aan dat je immers ook OSX clients aan je server knoopt.

Nog een stukje over incremental backup's : Baseer niet alles op EEN enkele full backup ! Maak regelmatig full backups bv elk weekend en borduur hierop de rest van de week voort met incrementals. Mocht je full backup stuk zijn dan kan je nog terug grijpen naar je vorige en heb je hooguit een week data verlies in dit geval.

[ Voor 8% gewijzigd door Verwijderd op 23-06-2009 22:34 ]

[LuckY]

Verwijderd schreef op dinsdag 23 juni 2009 @ 22:28:
hmmm ik vind dit altijd heel eng worden ... vooral als ik hier iets van een osx server lees. No offence maar ik zou er mijn bedrijf niet op durven draaien. De reden is dat apple nogal eenvoudig over sommige zaken denkt en zodoende de gebruikers schijnbaar ook.

Ik gok dat je huidige disk's SATA disken zijn. Deze zijn niet gemaakt voor een productie omgeving, bij een beetje belasting zakt de performance drastisch in elkaar. Heb je wel eens getest als je een disk vervangt uit je raid set hoe lang de rebuild tijd is ? En wat de performance inpackt hiervan is ? Hoe snel kunnen de mensen nog werken en wat gebeurt er wanneer de nog goede disk overlijd ? Ja een ongeluk komt nooit alleen.

Als je server uitvalt en er lopen 5 man een dag uit hun neus te eten was het misschien handiger om wat extra geld te investeren in een RAID 6 disk setje, SAS wel te verstaan. Door de kleinere disken is je rebuild tijd korter en SAS disken kunnen een hogere I/O load aan waardoor je geen echt grote performance dip krijgt bij een rebuild.

Verders zoals boven al was vermeld harddisken zijn geen backup medium !!! Koop een fatsoenlijke tapedrive iets a la LTO3 of 4. En maak een goed roterend backup schema met de tapes op een veilige locatie ver weg bij je server. Sommige banken schijnen niet zoveel geld meer te hebben dus misschien hebben ze nog wat ruimte in hun kluis.

Test je backup en RESTORE plan en kijk of het voldoet. En ga shoppen bij een serieuze hardware fabrikant welke verstand hebben van servers bouwen, 's werelds grootste is zo slecht nog niet, zij leveren alles wat je nodig hebt, zelfs tot debian software aan toe voor server monitoring. Ik neem aan dat je immers ook OSX clients aan je server knoopt.

Nog een stukje over incremental backup's : Baseer niet alles op EEN enkele full backup ! Maak regelmatig full backups bv elk weekend en borduur hierop de rest van de week voort met incrementals. Mocht je full backup stuk zijn dan kan je nog terug grijpen naar je vorige en heb je hooguit een week data verlies in dit geval.

OSX Server kan evenveel als 2003, en er is net als bij dell of HP een maintenance plan / 4 hour onsite support het heet dan alleen Apple Care.
Echter kan je ook SAS schijven in je server gooien

[Your Xserve includes three hot-swap drive bays that support both SATA (Serial ATA) and SAS (Serial Attached SCSI) Apple Drive Modules and offer up to 3 terabytes of internal data storage. Configure each drive bay separately. Drive bays that are not configured with a drive module ship with a nonfunctional blank drive carrier. SAS drives are available separately from the Apple Online Store.

Tevems kan je vanuit Apple software support krjgen. (http://www.apple.com/supp...macosxserver_sw_supt.html )

Alliance covers an unlimited number of enterprise-level incidents across multiple locations and provides one-hour response for priority 1 issues, 24/7.(5) This plan includes an onsite review by an Apple technical support engineer.

Dat zie ik andere hardware vendors nog niet doen, omdat jij (niet persoonlijk opnemen plox) niet er mee om kan gaan wil zeggen dat anderen dat niet kunnen.

[Verwijderd]

Ik hoop dat je er van bewust bent dat response tijd ongelijk is aan de tijd die nodig is om je server weer up en running te krijgen.

Verder was ik niet aan het flamen op het merk apple maar de matige configuratie waarmee jij je server runt. In dit geval ben je helaas beperkt tot Apple en ik vind het nogal storend van apple dat ze dit soort dingen promoten voor bedrijven. Je main data server van je bedrijf op SATA runnen en dan ook nog denken dat je je backup van 1,5T binnen een half uurtje weer op je server hebt staan als de boel crashed ?

Mensen zijn vervangbaar (ja ze zoeken soms een andere baan, gaan met pensioen of krijgen een ernstig ongeluk). Je zoekt dan een nieuwe opvolger. Data is niet vervangbaar, je kan niet je data aanvullen met willekeurige bitjes van internet. Ik weet niet wat jullie business is maar meestal gaat het om ontwerpen, tekeningen, crm data etc. Hier is uren werk in gestoken, creatieve ideeen ed. ofwel onbetaalbaar en jij wil je gehele hart van je bedrijf op zo'n oplossing zetten... ik zou er slapenloze nachten van krijgen.

[LuckY]

Verwijderd schreef op woensdag 24 juni 2009 @ 19:45:
Ik hoop dat je er van bewust bent dat response tijd ongelijk is aan de tijd die nodig is om je server weer up en running te krijgen.

Verder was ik niet aan het flamen op het merk apple maar de matige configuratie waarmee jij je server runt. In dit geval ben je helaas beperkt tot Apple en ik vind het nogal storend van apple dat ze dit soort dingen promoten voor bedrijven. Je main data server van je bedrijf op SATA runnen en dan ook nog denken dat je je backup van 1,5T binnen een half uurtje weer op je server hebt staan als de boel crashed ?

Mensen zijn vervangbaar (ja ze zoeken soms een andere baan, gaan met pensioen of krijgen een ernstig ongeluk). Je zoekt dan een nieuwe opvolger. Data is niet vervangbaar, je kan niet je data aanvullen met willekeurige bitjes van internet. Ik weet niet wat jullie business is maar meestal gaat het om ontwerpen, tekeningen, crm data etc. Hier is uren werk in gestoken, creatieve ideeen ed. ofwel onbetaalbaar en jij wil je gehele hart van je bedrijf op zo'n oplossing zetten... ik zou er slapenloze nachten van krijgen.

Het is niet mijn omgeving en ook niet mijn configuratie ik ben niet de TS
Backuppen van en naar Sata is niet ideaal, ben ik het compleet met je eens.
Echter is die 1hour support van apple wel netjes alleen duur (45k de jaar )
De sata schijven kunnen ook vervangen worden door SAS zoals ik al eerder aangaf.
Tevens raad apple afaik ook gewoon tape drives aan.

Alleen zijn de mensen in het bedrijf die het niet geheel snappen/verkeerd op pakken.

[Liegebeest]

Zie ik onderdaad vaker, op fora als OneMoreThing en MacFreak: mensen vertrouwen erg op backups naar externe schijven. En dat is inderdaad geen goed idee. Zelfs Apple verkoopt in hun online store LTO4 tape jukeboxen en dat is natuurlijk met een reden!

Nee, met schijfjes heen en weer drentelen voor je backups is GEEN goed idee.

Desnoods, als je wat geld uit wilt sparen, kan je zelfs een Firewire tape jukebox halen, maar daar passen maar vier tapes in. Schiet niet echt op als je 1.5TB, plus incrementals wilt opslaan.

Begrijp me niet verkeerd: backups naar schijf -kunnen- wel degelijk goed gaan, maar dat komt niet neer op een schijfkopie. Nee, je gebruikt de diskpool dan ter vervanging van een tape pool. Je werkt dan zoals normaal met een full, gevolgd door een aantal incrementals. Maar die diskpool moet dan wel degelijk heel ergens ander staan dan je servers

[Oogje]

Verwijderd schreef op maandag 22 juni 2009 @ 16:26:

[...]

De data is van vitaal belang voor het bedrijf. Dat het beschikbaar is ook, aangezien zodra het niet beschikbaar is, niemand meer kan werken. Iedereen werkt namelijk met de bestanden op de server.

Als anderen nog inzichten hebben in bovenstaande situatie, graag!

Hier even op inhakend, bij een complete crash worst-case een week terug in data lijkt me dan niet echt fijn?

[thunder7]

Wat ik nog mis in dit geheel: 1x per dag een backup betekent ook dat bij een storing je 23 uur transacties kwijt kunt zijn. Ik ken sectoren, eh nee, ik ken eigenlijk geen sectoren waarin dat geen probleem zou zijn.

Wat gebeurt er in het bedrijf als na een dag werken, om 18:00 alles kapot gaat en jij komt na een nacht heel hard werken de volgende morgen met het bericht: hier is uw data, tot en met 02:00 gisterochtend?

[kraats]

Verwijderd schreef op dinsdag 23 juni 2009 @ 22:28:
Verders zoals boven al was vermeld harddisken zijn geen backup medium !!! Koop een fatsoenlijke tapedrive iets a la LTO3 of 4. En maak een goed roterend backup schema met de tapes op een veilige locatie ver weg bij je server. Sommige banken schijnen niet zoveel geld meer te hebben dus misschien hebben ze nog wat ruimte in hun kluis.

Ik moest heel even inhaken op dit stukje: tapes plaatsen bij een bank is imho géén goed idee, omdat op de kluis vaak een tijdsslot zit en je dus kans hebt een heel weekend niet bij je tapes te kunnen.

[Gomez12]

thunder7 schreef op donderdag 02 juli 2009 @ 22:09:
Wat ik nog mis in dit geheel: 1x per dag een backup betekent ook dat bij een storing je 23 uur transacties kwijt kunt zijn. Ik ken sectoren, eh nee, ik ken eigenlijk geen sectoren waarin dat geen probleem zou zijn.

Wat gebeurt er in het bedrijf als na een dag werken, om 18:00 alles kapot gaat en jij komt na een nacht heel hard werken de volgende morgen met het bericht: hier is uw data, tot en met 02:00 gisterochtend?

Tja, wat is het alternatief? Transactie logs in real time naar buiten sturen?

Wat wij vroeger nog deden was gewoon transactie logs naar 2e raid gooien... En dan nog intern enkele consumenten nassen hebben hangen waar 1x per uur een robocopy heen ging. ( en dan op een schedule per NAS per dag )

Crasht zo'n consumenten NAS heb je voor 100 euro een nieuwe en het werkt extreem makkelijk als iemand snel even iets van vanochtend terug moet hebben ( gecrashte NAS en iemand wil toch iets terug hebben dan werd het directie werk, moeten de transactie logs gebruikt worden of niet )

Let er enkel op met zo'n setup dat die NASsen geen backup zijn ( eigenlijk is het niets behalve wat gemak ). Je reguliere backup /restore schema blijft nog steeds van kracht

[Parasietje]

Onze backup-situatie is als volgt:

* bedrijfskritische server op raid5
* backupserver die elke nacht een incremental backup doet van server 1
** plus elke week een full backup, retention time van die backups is 1 maand
* elke nacht stuurt de backupserver zijn data door naar een off-site backupserver
** off-site backupserver heeft full backup + diffs van een week

Je bespaart hier ook personeelskosten mee; het kan best zijn dat de usb-hardeschijf-vervoerder ziek valt, en je dus 2 weken geen switches doet. Ook is versleuren van schijfjes echt heel erg slecht. Een backupserver hoeft echt geen dure bak te zijn; alleen zorgen dat hij een deftige voeding heeft.

[thunder7]

Gomez12 schreef op donderdag 02 juli 2009 @ 22:53:
[...]

Tja, wat is het alternatief? Transactie logs in real time naar buiten sturen?

Wat wij vroeger nog deden was gewoon transactie logs naar 2e raid gooien... En dan nog intern enkele consumenten nassen hebben hangen waar 1x per uur een robocopy heen ging. ( en dan op een schedule per NAS per dag )

Wij sturen onze transaction logs van de database op het SAN elke 20 minuten naar de interne harde schijf, en naar de interne harde schijf van een andere server. Naar buiten zou beter zijn, maar dat ligt wat lastig met de beveiliging.

[Liegebeest]

Bij de "mission critical" bakken waar ik aan heb gewerkt zag ik vaak het volgende:

* HA clustering, met cluster op productie site en failover cluster op de uitwijk
* Data op het SAN, met glasvezel ook op uitwijk locatie
* Op SAN data van productie site naar uitwijk locatie syncen
* Dagelijkse backups naar tape library.

Op die fiets heb je bij een failover nooit meer dan een uur aan data verlies en mocht -alles- uitfikken dan ben je een dag kwijt.

[Verwijderd]

Ik ben er nu nog niet helemaal uit. Het volgende speelt namelijk: we hebben nu 5x750GB schijven waarvan 4 in RAID 10 staan (1.5TB). Dit zijn trouwens geen SATA, maar PATA schijven. We hebben qua snelheid hier geen last van aangezien qua belasting op de server het allemaal erg meevalt. Het gaat ons er meer om dat de data die we op onze fileserver plaatsen, daar veilig staat. Er hangt in onze serverkast ook een 19" UPS voor de server die ook stroompiekjes opvangt.

Maar wat is de kans dat RAID 10 zomaar kapot gaat? Een volledige RAID array gaat niet zomaar kapot lijkt me? Echter ben ik hier geen expert in, dus hoor ik graag jullie mening over. Want als die RAID array kapot gaat, hebben we nog altijd in de genoemde setup in TS waarbij we een dag terug gaan. Maar het zou nogal matig zijn als het risico hoog is dat een softwarematige raid snel kapot kan gaan.

Voor de duidelijkheid, het is geen groot bedrijf, we werken hier met 6 man. Er zijn niet budgetten om hele moeilijke backupsystemen aan te leggen. Het gaat er voornamelijk om dat onze data veilig is en we verder kunnen in geval van nood.

[ Voor 7% gewijzigd door Verwijderd op 06-07-2009 16:52 ]

[Gomez12]

Tja, als het softwarematige raid is dan heb je imho een heel zwak punt, je boot-hdd waarop je driver staat raakt beschadigd en wat dan?

Software matige raid blijft imho gewoon software die ten prooi kan vallen aan alles wat software kan aanvallen.

Snel kapot zal het niet gaan ( maar dat gaat een enkele hdd ook niet ), maar als murphy toeslaat heb ik toch liever een stukje dedicated software draaien wat niet zomaar door een os aangepast kan worden...

In grote van risico ( imho ) is het :
1 : Enkele hdd zonder iets
2 : Meerdere hdd's met periodieke synchronisatie
3 : Software raid
4 : Hardware raid met battery backupped write cache

Stap 1/3 is in verhouding gratis, maar stap 4 kost bedrijfsmatig ook niet zoveel. Het begint pas prijzig te worden als je verder dan stap 4 wilt...
Imho zou ik dan ook zoveel mogelijk voor stap 4 kiezen, beste kosten baten verhouding bij een klein bedrijfje waar murphy op de loer ligt...

[Question Mark]

Verwijderd schreef op maandag 06 juli 2009 @ 16:51:
Want als die RAID array kapot gaat, hebben we nog altijd in de genoemde setup in TS waarbij we een dag terug gaan.

Kun je nog eens uitleggen hoe je nu precies gaat backuppen?

In de TS meld je nl. dat je een kopieeractie gaat uitvoeren naar twee externe disks, die je wekelijks omwisselt. Even later meld je, dat je om het tijdswindows zo klein mogelijk te houden enkel gewijzigde bestanden (incremental) gaat backuppen.

Hoe wil je dan nu, met een externe disk die kennelijk enkel de incremental files van de vorige dag bevat, de RAID 10 gaan restoren?

[Verwijderd]

Gomez12 schreef op maandag 06 juli 2009 @ 20:01:
Tja, als het softwarematige raid is dan heb je imho een heel zwak punt, je boot-hdd waarop je driver staat raakt beschadigd en wat dan?

Software matige raid blijft imho gewoon software die ten prooi kan vallen aan alles wat software kan aanvallen.

Snel kapot zal het niet gaan ( maar dat gaat een enkele hdd ook niet ), maar als murphy toeslaat heb ik toch liever een stukje dedicated software draaien wat niet zomaar door een os aangepast kan worden...

In grote van risico ( imho ) is het :
1 : Enkele hdd zonder iets
2 : Meerdere hdd's met periodieke synchronisatie
3 : Software raid
4 : Hardware raid met battery backupped write cache

Stap 1/3 is in verhouding gratis, maar stap 4 kost bedrijfsmatig ook niet zoveel. Het begint pas prijzig te worden als je verder dan stap 4 wilt...
Imho zou ik dan ook zoveel mogelijk voor stap 4 kiezen, beste kosten baten verhouding bij een klein bedrijfje waar murphy op de loer ligt...

helaas kan je raid controller ook kapot gaan, maar dan kan je meestal je raid config weer van je schijven afhalen (aka controller vervangen en het werkt weer). moet je wel hopen dat je geen corruptie hebt van data natuurlijk.

ik vind het overigens wel grappig dat de TS een software raid-10 gemaakt heeft. De performance winst van de raid 10 gaat direct weer weg naar de software raid overhead imho