Back-up Platform Setup en Ervaringen

[NukeLed]

Beste mede Tweakers,

Hierbij verneem ik graag jullie advies en ervaringen omtrent een back-up platform. Wij zijn momenteel bezig met het opzetten van een nieuw online back-up platform. En lopen tegen enkele problemen en of vragen aan. Ik zal jullie eerst de set-up even uitleggen.

Wij maken gebruik van één fysieke server host (Win2k8 R2 Enterprise SP1) met daarop vier virtuele back-up servers. (Hyper-V) Deze zijn Windows 2k8 Standard R2 SP1. Deze virtuele servers zijn verbonden met een Synology RS2211+ NAS. Als software maken we gebruik van Ahsay.

De Sonology NAS heeft 10 schijven van 2TB elk in een RAID 6 opstelling. We houden zo ongeveer 14,5TB aan effectieve ruimte over. De 4 virtuele back-up servers slaan hun data op de NAS op. Deze nas heeft 1 volume van 14,5TB. De data opslag gebeurd via iSCSI.

Op de NAS hebben we 4 iSCSI targets gemaakt met 4 LUN's. Hier zijn we mogelijk de fout in gegaan. Deze LUNS zijn alle 4 geconfigureerd met 14TB aan ruimte. Natuurlijk is er niet 4x 14TB aan ruimte beschikbaar maar 14,5TB totaal. Nu lopen we tegen het probleem aan dat er op sommige LUN's data corruptie optreed.

Hadden wij dit kunnen voorkomen door de LUN's een maximum ruimte moeten geven van 3,5TB per LUN? (3,5 x 4 is 14TB totaal) Of is er misschien nog een betere configuratie mogelijk? Hadden we het volume moeten opdelen in 4 verschillende volumes en per volume 1 LUN aanwijzen met de vaste grote van dat volume? Of zijn er nog betere configuraties mogelijk?

Verder lopen we met bovenstaande configuratie tegen het probleem aan dat we relaties minder snel kunnen verplaatsen naar een andere back-up server omdat de data niet rechtstreeks van bijv. LUN1 naar LUN2 gekopieerd kan worden maar dit via de server moet. We zouden hier liever één volume hebben met daarop 4 mappen. (voor elke back-up server 1 map) Zodoende dat we een klant sneller kunnen verplaatsen naar een andere back-up server.

Graag jullie mening en of ervaringen over bovenstaande. Het is totaal niet de bedoeling dat jullie ons een gepaste omgeving laten zien waar wij na de tijd gebruik van kunnen maken. Ik deel graag mijn ervaringen en kennis met anderen en hoop ook dat jullie bovenstaande op dezelfde manier zien. Mogelijk zijn er nog mede tweakers hier die tegen een zelfde soort situatie aanlopen en uit deze situatie ook leer kunnen trekken.

In ieder geval bedankt voor de genomen moeite.

[X-DraGoN]

Het lijkt me voor de hand liggende en dat geef je zelf ook al aan dat je je totale HD ruimte had moeten opdelen 1 4 aparte stukken al naar gelang de gewenste grote. Met deze config ga je sowieso tegen problemen analopen vroeg op laat (ook reeds gebeurd). Dat je niet snel backups kan terug zetten van BV. LUN1 naar LUN zal je er dan maar bij moeten pakken.
Je kan natuurlijk ook heel basaal gaan werken, en wel je 1 volume à 14.5 TB houden en gewoon 4 mapjes maken die je elke keer mount in je server.

[NukeLed]

Bedankt voor je snelle reactie! Je laatste argument is inderdaad erg basaal en niet wenselijk in ons geval aangezien er dacht en nacht een back-up gemaakt wordt. Dit gebeurd dan automatisch. Wij hebben ook al nagedacht over een share met 4 mappen op de NAS en deze te koppelen per virtuele server echter bij het afmelden van de sessie zal je aangemaakte netwerk share dan worden ontkoppeld. Wij zouden ook niet 1,2,3, weten hoe je een permanente netwerk share zou kunnen mounten op je windows machine.

Daarnaast ondersteund de back-up software helaas geen UNC paden, hij moet je koppeling zien als fysieke schijf.

[Anoniem: 302882]

Hoi,

Als ik dit zo lees klinkt de setup opzich wel oke echter zou ik niet op deze manier backuppen als je zoveel data heb 14,5 ter is veel. Ik zou toch eerder gaan denken aan een site to colo upload systeem dus dan ga je met replicatie aan de slag.

Vervolgens zou ik aan deze server een normaal kabinet hangen en daar naar toe backuppen. Ik vind backuppen naar NAS vragen om problemen. Als dat ding overhit raakt kan dat je schijven al aan tasten.

Echter wil je hier aan blijven werken, wat X-DraGoN ook zegt, deze setup wordt er een met veel problemen. De enige manier om dit echt goed te laten werken is 1 groot volume er van te maken. Heb je dit wel best practices ingericht? Mogelijk een whitepaper opzoeken? Ik heb het onderstaande gevonden:

http://publib.boulder.ibm...e0_t_backing_up_luns.html - Dit is geen best practices

Ga je uiteindelijk toch besluiten om op een ander backup systeem over te gaan moet je aan een aantal dingen gaan denken.

- Tapes (taperobot)
- BackupExec is dan je beste / meest betaalbare optie.

BackupExec kan enorm gammel zijn tenzij je het vanaf dag 1 goed inricht. Zet de juiste exclusions aan en zorg dat de configuratie best practices is(Symantec Whitepaper).

- Replicatie backups
Dit is wel de way to go tegenwoordig. Hier zit alleen 1 gevaar in. Als de internet lijn niet breed genoeg is kan dit natuurlijk problemen geven aangezien je met replica backups het liefst elk uur een incremental wil draaien om zoveel mogelijk data op een dag bij elkaar te spijkeren. Als je last heb van een dunne internetlijn zal je dataverkeer moeten knijpen.

Er zijn veel suppliers hiervoor maar ook enorm veel troep op de markt. Als je gaat rond zoeken blijf vooral weg bij Zenith (BDR). Ik heb een keer 2 dagen zitten rotzooien omdat er spontaan home directories werden verwijderd (bleek dit pakket te zijn).

Als je adviezen nodig heb kan je mij altijd even pm-en.

Gr.

[kroegtijger]

Site to colo is leuk, maar dat kost je wel bakken met bandbreedte. Die moet TS wel tot zn beschikking hebben dan uiteraard...

Worden de servers ook 's nachts gebruikt? Of kun je dan wel over de volledige capaciteit hiervan beschikken?
En hoeveel data verandert er? (oftewel, wat ben je aan storage-ruimte kwijt voor een differential?).

[Anoniem: 302882]

Site to colo kost bandbreedte welke te knijpen is en als dat overdag problematiek oplevert heb je een slechte internet lijn met maar 1 of 2x QoS op je lijn

[ Voor 20% gewijzigd door Anoniem: 302882 op 22-06-2012 16:54 ]

[NukeLed]

In het begin vergeten de vermelden dat het hier al een site-2-colo omgeving betreft. Het gaat hier om diverse klanten die een back-up wegschrijven naar onze back-up servers in de colo.

[KennieNL]

NukeLed schreef op vrijdag 22 juni 2012 @ 14:10:
Daarnaast ondersteund de back-up software helaas geen UNC paden, hij moet je koppeling zien als fysieke schijf.

Wij gebruiken bij ons Ahsay OBM naar een QNAP NAS toe, en werken gewoon via een UNC path.
Hun supporten het zelfs... heb het namelijk voor installatie hiervan nagevraagd.

Welke versie van Ahsay gebruik je?

[LordMorgoth]

Let wel dat Ahsay erg happig is met het toevoegen van functionaliteit, maar wat minder snel is met het oplossing van problemen in de software. Sinds versie 6 van OBM of OBS is het huilen met de pet op.

[Coen Rosdorff]

KennieNL schreef op zaterdag 23 juni 2012 @ 22:19:
Welke versie van Ahsay gebruik je?

Hier historische ervaring met Ahsay. Beetje een open zenuw nog.
Leuk in een kleine omgeving. Maar in een grote omgeving een drama.

[NukeLed]

De problemen zijn inmiddels opgelost, hebben Ahsay nu werkend met UNC paden en de back-ups verlopen voorspoedig.