Backup Exec 2010 - Inrichten van Backup

[tc982]

Voor een klant van mij, ben ik op zoek naar de beste manier om goed een backup te nemen van hun servers. Er zijn in totaal 28 servers, waar we een backup naar disk op nemen. Om het overzichtelijk te maken, zal ik de huidige setup doorgeven, deze is door de vorige IT firma opgezet :

Hardware :

Backup Server met Backup Exec 2010 R3
- Een P2000 gekoppeld op iSCSI met 4,6TB aan ruimte op de backup server.
- Elke dag word momenteel een full backup genomen op deze schijf met een totale grootte van 1TB
- In het tweede gebouw staat in de kelder een 6TB storage server met daarop HP Software om de SAN folder te "snapshotten"
- Er is een iSCSI netwerk waar de clients gebruik van kunnen maken.

Waarom is deze opstelling verkeerd voor de klant :

- Backup window word maar kleiner en kleiner, en momenteel worden er servers gebackupped in de dag omdat de windows zo lang loopt
- Er is geen echte "retentie" deze bedraagd momenteel maar 3 dagen, veel te kort dus
- Indien de SAN niet meer zou werken, deze is echt alleen voor backup doeleinden en als failover van de Hyper-V cluster, dan moet er gerestored worden van de backup storage server, maar deze moeten allemaal eerst geimporteerd worden in backup exec en gecatlogiseerd worden, bijgevolg ben je daar al bijna een dag mee zoet.

Ja maar, wat heb je nou zelf in gedachten :

- De backup jobs uit elkaar halen :

• Elke weekdag 3 / 4 servers full backuppen
• Elke weekdag de resterende server Incremental Backuppen

- Hardware :

• Backuppen naar de SAN via iSCSI
• De huidige storage server herinstalleren met Windows Server 2008 R2 ( klant heeft de nodige licenties ) en de iSCSI Software Connector erop installeren, deze presenteren aan de backup server als een extra disk.
• Copy jobs van de backups jobs laten lopen op deze storage server zodat er ook een externe backup is ( deze staat dus in een ander gebouw, geconnecteerd op Gigabit )

Ik heb zitten kijken naar de Job Policy's maar daar kan in een policy geen meerdere selectielijsten gebruiken, dus dat leek me niet echt te lukken.
Het zal dus 7 verschillende backup jobs worden.

Nu is mijn vraag, aangezien een opstelling altijd beter kan, wat zouden jullie anders doen.
-
≈

[Harrie666]

als je backup server of de storage daarvan onderuit gaat dan heb je altijd een probleem. Mocht dat gebeuren is je productie nog niet offline dus is er normaal gesproken niet zo veel aan de hand.

Wat als je in het weekend een Full backup draait en doordeweeks een Incremental ? Scheelt je een hoop tijd ? Als het toch allemaal vanaf storage gerestored kan worden maakt het niet zo veel uit dat het geheel uit meerdere files bestaat.

[DukeBox]

Waarom kijk je niet naar incremental forever oplossingen ?

[tc982]

Harrie666 schreef op donderdag 29 maart 2012 @ 21:51:
als je backup server of de storage daarvan onderuit gaat dan heb je altijd een probleem. Mocht dat gebeuren is je productie nog niet offline dus is er normaal gesproken niet zo veel aan de hand.

Wat als je in het weekend een Full backup draait en doordeweeks een Incremental ? Scheelt je een hoop tijd ? Als het toch allemaal vanaf storage gerestored kan worden maakt het niet zo veel uit dat het geheel uit meerdere files bestaat.

De twee systemen zijn bedoeld om lokaal een backup te hebben en nog een backup op een externe locatie. Ze hebben drie gebouwen gescheiden door een straat met een fiber in de grond. Dus dat leek de beste oplossing.

DukeBox schreef op donderdag 29 maart 2012 @ 21:58:
Waarom kijk je niet naar incremental forever oplossingen ?

De klant wilt blijven gebruik maken van de huidige infratructuur en wilt blijven werken met Backup Exec. Ook is het zo dat er redelijk wat databases in gebruik zijn ( 2 sql, 1 firebird en 1 SQL ) en ze hier graag minstens 1 keer per week een full backup van hebben.

[nilisvw]

Ik zie dat je incremental in gedachten hebt. Misshien een tip om Differential te pakken. Dan heb je elke dag toch een backup met de datawijzigingen vanaf de laatste full backup. Kost iets meer ruimte en duurt iets langer, maar bij ons valt dat reuze mee.

[tc982]

nilisvw schreef op vrijdag 30 maart 2012 @ 02:32:
Ik zie dat je incremental in gedachten hebt. Misshien een tip om Differential te pakken. Dan heb je elke dag toch een backup met de datawijzigingen vanaf de laatste full backup. Kost iets meer ruimte en duurt iets langer, maar bij ons valt dat reuze mee.

Het probleem is met databases dat differential moeilijk ligt. En we van de 1TB data op een differential toch nog 400GB per dag hebben.

[Johnny E]

Heb je al gekeken naar mogelijke botlenecks en dus ook optimalisaties die mogelijk zijn om de backups sneller te laten verlopen? Zijn het netwerk en de backup storage wel ingericht om de maximale performance te kunnen leveren?

Gaat het hier trouwens om een volledig fysieke omgeving of om een gevirtualiseerde omgeving?
Indien het volledig gevirtualiseerd is dan kan ik je VeeAM aanraden (v6 doet zowel Hyper-V als VMWare).

Wij draaien het nu ruim 3 jaar tot zeer grote tevredenheid. De 12TB productie data neemt met 30 dagen retentie 14TB ruimte in. De gebruikte backup ruimte zouden we naar beneden kunnen krijgen door meer backup jobs te combineren en beter gebruik te maken van de deduplicatie binnen VeeAM.

VeeAM doet helaas geen tape-out voor lange termijn opslag, hier hebben we dan ook no BackupExec 2010 voor. Die de VeeAM vbk bestanden met de recente full backup 1x per week naar tape schrijft.
VeeAM heeft ook VSS integratie waardoor je ook consistente SQL en Exchange backups kan maken zonder extra licenties of agents.

Als het gaat om uitsluitend fysieke servers dan wordt het een moeilijker verhaal, kijk dan kritisch of wel alles gebackupt moet worden. Ik zou hoe dan ook toch eens met de opdracht gever gaan praten over RPO / RTO wensen en eisen wat hiervan verwacht wordt.

[tc982]

Johnny E schreef op vrijdag 30 maart 2012 @ 10:07:
Heb je al gekeken naar mogelijke botlenecks en dus ook optimalisaties die mogelijk zijn om de backups sneller te laten verlopen? Zijn het netwerk en de backup storage wel ingericht om de maximale performance te kunnen leveren?

Gaat het hier trouwens om een volledig fysieke omgeving of om een gevirtualiseerde omgeving?
Indien het volledig gevirtualiseerd is dan kan ik je VeeAM aanraden (v6 doet zowel Hyper-V als VMWare).

Wij draaien het nu ruim 3 jaar tot zeer grote tevredenheid. De 12TB productie data neemt met 30 dagen retentie 14TB ruimte in. De gebruikte backup ruimte zouden we naar beneden kunnen krijgen door meer backup jobs te combineren en beter gebruik te maken van de deduplicatie binnen VeeAM.

VeeAM doet helaas geen tape-out voor lange termijn opslag, hier hebben we dan ook no BackupExec 2010 voor. Die de VeeAM vbk bestanden met de recente full backup 1x per week naar tape schrijft.
VeeAM heeft ook VSS integratie waardoor je ook consistente SQL en Exchange backups kan maken zonder extra licenties of agents.

Als het gaat om uitsluitend fysieke servers dan wordt het een moeilijker verhaal, kijk dan kritisch of wel alles gebackupt moet worden. Ik zou hoe dan ook toch eens met de opdracht gever gaan praten over RPO / RTO wensen en eisen wat hiervan verwacht wordt.

Is inderdaad een zwaar gevirtualiseerde omgeving, maar de klant heeft al geinvesteerd door de vorige IT firma met Hyper-V agents voor Backup Exec. En deze zijn zeer duur

Ps: Integrating Veeam Backup and Symantec Backup Exec 12 ( Link : http://www.alliancetechpa...p_and_symantec_backup.pdf ) . Misschien handig.

[Johnny E]

Als je het goed kan onderbouwen met argumenten dan kan het zijn dat de klant er dan wel voor open staat om te kiezen voor een andere oplossing. Zoals je het beschrijft is de huidige situatie niet meer toereikend en is er geen retentie.

Ik zou dus zeggen:
1: Start de discussie met de klant om de wensen en eisen mbt RPO/RTO inzichtelijk te krijgen.
2. Onderzoek of je de huidige backup setup kan optimaliseren en wat de gevolgen zullen zijn en of deze dan passen bij de RPO/RTO wensen en eisen.
3. Kom met een goed verhaal inclusief kosten baten analyze over hoe jij denkt dat je de backup conform de wensen en eisen kan vorm geven.

[tc982]

Johnny E schreef op vrijdag 30 maart 2012 @ 16:33:
Als je het goed kan onderbouwen met argumenten dan kan het zijn dat de klant er dan wel voor open staat om te kiezen voor een andere oplossing. Zoals je het beschrijft is de huidige situatie niet meer toereikend en is er geen retentie.

Ik zou dus zeggen:
1: Start de discussie met de klant om de wensen en eisen mbt RPO/RTO inzichtelijk te krijgen.
2. Onderzoek of je de huidige backup setup kan optimaliseren en wat de gevolgen zullen zijn en of deze dan passen bij de RPO/RTO wensen en eisen.
3. Kom met een goed verhaal inclusief kosten baten analyze over hoe jij denkt dat je de backup conform de wensen en eisen kan vorm geven.

Dat is het juist. De klant heeft deze investeringen gedaan, en staat niet open om extra geld te investeren. Dus deze discussie ga ik hier niet voeren. De klant vind dat er genoeg hardware en software is, die al heel veel heeft gekost. En deze moet nu gewoon geoptimaliseerd worden. De klant wilt het backup verhaal bekijken over 3 jaar, wanneer de hardware kost van nu is afgeschreven. Ik kan hem niet ongelijk geven. Vergeet niet , er zijn in totaal 28 servers, waarvan er 6 Hyper-V servers zijn. Die licenties voor Backup Exec zijn niet mis, en nog niet verteerd door de klant.

[col-dejong]

Voor zover ik durf te zeggen en weet,
hebben we op het bedrijf ook 2 P2000sa hangen.
Er werd naar de P2000's geschreven en naar een tape library.
Voor zover ik weet was het zo geregeld dat er aan het einde van de maand een full backup draaide
en elke dag een incremental muv de databases.
We maken enkel geen gebruik van Symantec maar Simpana.

[ninjazx9r98]

Een backup window is de tijd die beschikbaar is om backups te maken en is over het algemeen dus afhankelijk van de werktijden binnen een bedrijf.
Als ik de probleemstelling lees krijg ik echter het idee dat er iets heel anders bedoelt wordt met een backup window.
Er wordt ook gesproken over backups die overdag lopen omdat het window zo lang loopt?
Je lijkt eigenlijk gewoon te zeggen dat de backups enorm lang duren waardoor er niet voldoende tijd is gedurende de avond/nacht om die backups te maken?
Of bedoel je met de opmerking dat de backup window kleiner en kleiner wordt dat het bedrijf steeds langer open is?

Zoals Johny E ook al aangeeft zou ik eerst eens gaan kijken of je de bottlenecks in kaart kunt brengen.
De hoeveelheid data waar je het over hebt (1TB) is niet idioot veel en moet je met een fatsoenlijke omgeving binnen een paar uurtjes weg kunnen schrijven.
In geval van een gigabit heb je het in het gunstigste geval over grofweg 2,5 uur voor 1TB.
Waarom duurt het overigens een dag om te importeren en catalogiseren, uiteraard zijn niet alle details bekend maar gezien de hoeveelheden data waar je over praat klinkt dat als overdreven lang.

Ik krijg eerder het idee dat er iets serieus mis is in/met die omgeving dan dat je het direct in de manier van backuppen moet gaan zoeken.

[ Voor 4% gewijzigd door ninjazx9r98 op 30-03-2012 23:58 ]

[tc982]

ninjazx9r98 schreef op vrijdag 30 maart 2012 @ 23:54:
Een backup window is de tijd die beschikbaar is om backups te maken en is over het algemeen dus afhankelijk van de werktijden binnen een bedrijf.
Als ik de probleemstelling lees krijg ik echter het idee dat er iets heel anders bedoelt wordt met een backup window.
Er wordt ook gesproken over backups die overdag lopen omdat het window zo lang loopt?
Je lijkt eigenlijk gewoon te zeggen dat de backups enorm lang duren waardoor er niet voldoende tijd is gedurende de avond/nacht om die backups te maken?
Of bedoel je met de opmerking dat de backup window kleiner en kleiner wordt dat het bedrijf steeds langer open is?

Zoals Johny E ook al aangeeft zou ik eerst eens gaan kijken of je de bottlenecks in kaart kunt brengen.
De hoeveelheid data waar je het over hebt (1TB) is niet idioot veel en moet je met een fatsoenlijke omgeving binnen een paar uurtjes weg kunnen schrijven.
In geval van een gigabit heb je het in het gunstigste geval over grofweg 2,5 uur voor 1TB.
Waarom duurt het overigens een dag om te importeren en catalogiseren, uiteraard zijn niet alle details bekend maar gezien de hoeveelheden data waar je over praat klinkt dat als overdreven lang.

Ik krijg eerder het idee dat er iets serieus mis is in/met die omgeving dan dat je het direct in de manier van backuppen moet gaan zoeken.

Het zijn vooral de Exchange 2003 die enorm lang duurt, samen met de Hyper-V agents van Backup Exec zelf.
Het backup window is de tussen 20:00 en 8 uur. Het is nu vooral de verify die zolang duurt ( van 06:00 tot 11:00 ). Dus ik weet niet hoe jij dit in 2,5 uur doet van een 28tal servers te samen.

[ninjazx9r98]

Kort door de bocht doet het aantal servers er niet eens zoveel toe, het is de configuratie van de jobs en een kwestie van plannen.
De 2,5 uur die ik noem is gebaseerd op de aanname dat je een één gigabit connectie vol drukt met data en dan is dat de tijd die je nodig hebt om 1TB te verwerken.
De omgeving waar jij het over hebt doet daar echter vier keer zo lang over (aanname, 20:00 tot 06:00 )
Kunnen er niet meer servers gelijktijdig gebackupped worden om de bandbreedte beter te benutten?

Wat is overigens het probleem dat de verify zo lang duurt?
De servers waar je een backup van gemaakt hebt hebben daar als het goed is helemaal geen last van aangezien er helemaal niet gekeken wordt naar bron data (dat kan ook niet, die is mogelijk uren eerder weggeschreven en ondertussen al weer gewijzigd).
Bij een verify wordt de backup data gelezen, daar wordt een checksum van gemaakt en die wordt vergeleken met de checksum die tijdens de backup is gemaakt.

[col-dejong]

Ter aanvulling van ninjazx9r98:
Hoeveel data stuur je door -
Hoeveel servers backup je in 1x -
Misschien zorgen dat je meerdere streams tegelijk kan verwerken -
En daarbij misschien moet denken aan een 2e server waar je dan weer streams aanhangt

[Remco]

tc982 schreef op zaterdag 31 maart 2012 @ 14:34:
[...]
Het zijn vooral de Exchange 2003 die enorm lang duurt, samen met de Hyper-V agents van Backup Exec zelf.
Het backup window is de tussen 20:00 en 8 uur. Het is nu vooral de verify die zolang duurt ( van 06:00 tot 11:00 ). Dus ik weet niet hoe jij dit in 2,5 uur doet van een 28tal servers te samen.

Wij doen hier ook backuppen met Veeam in combinatie met Backup Exec voor het naar tape zetten. Wij gebruiken de reversed incremental methode van Veeam zodat we altijd een actuele full backup hebben. En die schrijven we dan ook overdag weg naar tape.
De Veeam jobs duren in totaal ongeveer 5 uur, en de grootte is 1,8 TB voor 45 servers. Let wel, dat is inclusief het omrekenen naar reversed incremental. Anders zou het wellicht nog sneller verlopen.
Wij hebben de backup server dan wel op een P2000 aangesloten via 8 Gbit fiber.

[ Voor 6% gewijzigd door Remco op 02-04-2012 16:14 ]

[tc982]

Remco schreef op maandag 02 april 2012 @ 16:13:
[...]

Wij doen hier ook backuppen met Veeam in combinatie met Backup Exec voor het naar tape zetten. Wij gebruiken de reversed incremental methode van Veeam zodat we altijd een actuele full backup hebben. En die schrijven we dan ook overdag weg naar tape.
De Veeam jobs duren in totaal ongeveer 5 uur, en de grootte is 1,8 TB voor 45 servers. Let wel, dat is inclusief het omrekenen naar reversed incremental. Anders zou het wellicht nog sneller verlopen.
Wij hebben de backup server dan wel op een P2000 aangesloten via 8 Gbit fiber.

De P2000 is een P2000i met iSCSI dus op 1GB, er is ook op die SAN maar 1 controller ( don't ask ). Dus dat is al bottleneck 1, er moet nog een backup netwerk aangelegd worden, dat is bottleneck nummer 2, en we gebruiken Backup Exec met Hyper-V agents, dat is bottleneck nr 3. Vervolgens wilt de klant een Exchange 2003 met item recovery, dat is bottleneck 4. Ik weet waar het zit, vandaar ook mijn vraag dat iemand het anders zou doen met de HUIDIGE soft en hardware. Op termijn zal er zeker een veeam komen, maar nu niet spijtig genoeg.

col-dejong schreef op zaterdag 31 maart 2012 @ 15:54:
Ter aanvulling van ninjazx9r98:
Hoeveel data stuur je door -
Hoeveel servers backup je in 1x -
Misschien zorgen dat je meerdere streams tegelijk kan verwerken -
En daarbij misschien moet denken aan een 2e server waar je dan weer streams aanhangt

Er is in totaal 1TB ( 1,1GB ) aan data
Nu word er 28 servers in 1x gebackupped, allemaal full
Er word allemaal gebackupped achter elkaar zonder verschillende streams

In de toekomst zou het dus 2 streams worden, zoals aangeraden door Symantec zelf, 1 die de full backups doe, vervolgens 1 stream die de differentials/incrementals doe.

[ninjazx9r98]

Ik krijg niet echt het idee dat je weet waar het zit of je bent niet duidelijk/volledig genoeg in je uitleg.
Je zegt dat iSCSI een bottleneck is met slechts 1Gbit maar je spreekt over problemen met de lengte van het backupwindow wat dat totaal tegenspreekt.
Zoals eerder gezegd, als je de volle capaciteit van gigabit zou benutten was je in 2,5 uur klaar met die ene TB waar je het over hebt.

Misschien dat je kunt toelichten waarom je van mening bent dat die 1Gbit iSCSI verbinding een bottleneck is?

Waar ik overigens als eerste naar zou kijken is servers parallel gaan backuppen in plaats van achter elkaar.
Dat is op dit moment de meest snelle en efficiente oplossing met de huidige hard en software.
Dit zou moeten kunnen aangezien het er met de informatie die je geeft niet op lijkt dat die ene Gbit iSCSI op dit moment een probleem is.

Overigens snap ik je verhaal over die twee streams volgens Symantec niet helemaal.
Meestal heeft men het over het gelijktijdig backuppen van meerdere jobs/systemen als er gepraat wordt over meerdere streams maar jij lijkt iets anders te bedoelen?

[ Voor 5% gewijzigd door ninjazx9r98 op 02-04-2012 21:45 ]

[ZeRoC00L]

Huh ?

en we gebruiken Backup Exec met Hyper-V agents, dat is bottleneck nr 3. Vervolgens wilt de klant een Exchange 2003 met item recovery, dat is bottleneck 4

Waarom is BE met Hyper-V een bottleneck ??
Daarnaast is BE in staat om een GRT backup te maken van je VM, waarna het toch mogelijk is individuele items (files / mailbox items) te restoren.

[Xtr3me4me]

Wij hadden hier ook een probleem mee. Ultrium 2 Tapes 400GB gecomprimeerde data.
Oude Tape Unit tot 24 Tapes en 12TB Storage works. En dit allemaal op een VmWare Server 2008 R2 met Backup Exec 2010 R3.

Het is waardeloos. Ik heb de oplossing bedacht ermee, omdat de boel te traag gewoon werd. Bedoel incrementals deden tot wel 15 uur. Absurd voor 3 a 4 tapes. En weekends +/- 14 a 16 tapes.

Hier wilde ik er vanaf. Dus heb een nieuwe Storageworks besteld 24TB. (Dit omdat ik langer dan 3 dagen op disk wilde hebben voor backup terug te kunnen halen)
Een nieuwe Autoloader G2 1/8 samen met Ultrium -5 Tapes en dit op 8 Gb Fibre Channel aansluiting. En daarbij upgraden (Gratis als je Backup Exec 2010 R3 hebt) naar 2012 versie. Sowieso een hele boel bugs eruit van de 2010 R3

. Oude meuk weg en nieuwe meuk erin. 36TB opslag ruimte op disk en full backup op 3 a 4 tapes in plaats op 16 tapes.

[kroegtijger]

Xtr3me4me schreef op woensdag 04 april 2012 @ 10:23:
Wij hadden hier ook een probleem mee. Ultrium 2 Tapes 400GB gecomprimeerde data.
Oude Tape Unit tot 24 Tapes en 12TB Storage works. En dit allemaal op een VmWare Server 2008 R2 met Backup Exec 2010 R3.

Het is waardeloos. Ik heb de oplossing bedacht ermee, omdat de boel te traag gewoon werd. Bedoel incrementals deden tot wel 15 uur. Absurd voor 3 a 4 tapes. En weekends +/- 14 a 16 tapes.

Hier wilde ik er vanaf. Dus heb een nieuwe Storageworks besteld 24TB. (Dit omdat ik langer dan 3 dagen op disk wilde hebben voor backup terug te kunnen halen)
Een nieuwe Autoloader G2 1/8 samen met Ultrium -5 Tapes en dit op 8 Gb Fibre Channel aansluiting. En daarbij upgraden (Gratis als je Backup Exec 2010 R3 hebt) naar 2012 versie. Sowieso een hele boel bugs eruit van de 2010 R3

. Oude meuk weg en nieuwe meuk erin. 36TB opslag ruimte op disk en full backup op 3 a 4 tapes in plaats op 16 tapes.

Trage backups naar tapes worden meestal veroorzaakt door de blocksize die op je de media in BE gewoon kunt aanpassen. Even kleiner zetten kan de doorvoersnelheid aanzienlijk verhogen en daarmee dus ook je performance verbeteren. Uiteraard is de backup zo traag als de langzaamste schakel in het proces dus je zutl ook even moeten monitoren of je schijven niet volop onzinnig staan te draaien, je memory en cpu usage niet absurd hoog zijn et cetera. Als dat gewoon op orde is, is er niets mis met een backup naar LTO3. We hebben hier diverse klanten met dergelijke backup-oplossingen via een tape-library, en werkt prima, mits goed ingeregeld.

Voor TS is dit niet van toepassing omdat de blocksize bij backup-to-disk bij het formateren van de disk wordt gezet en ik neem aan dat TS daar weinig trek in heeft om te gaan doen. Wat we met backup-to-disk wel vaak tegen komen is dat de backup-unit (bijvoorbeeld een RD1000) of de verbinding naar de backup-unit niet de bottleneck is, maar dat de te backuppen data niet snel genoeg aangeleverd kan worden, bijvoorbeeld omdat de disks van de server niet voldoende performen.
Monitor eerst daar eens op en ga pas aan de slag met de backup als je zeker weet dat de servers die het aan moeten leveren aan de backup-server dit snel genoeg kunnen, en dat de backup-server ook voldoende geheugen en vrije ruimte heeft om die binnennkomende data weer te verwerken. CPU enigszins in de gaten houden, want BE houdt een SQL-database bij op de achtergrond en die moet ook bijgewerkt worden. De kans is groot dat je daar al enorme winsten in kunt halen.

[bigfoot1942]

kroegtijger schreef op vrijdag 13 april 2012 @ 16:05:
[...]

Trage backups naar tapes worden meestal veroorzaakt door de blocksize die op je de media in BE gewoon kunt aanpassen. Even kleiner zetten kan de doorvoersnelheid aanzienlijk verhogen en daarmee dus ook je performance verbeteren.

Begrijp ik je goed als ik zeg dat je een kleinere blocksize had gewenst, omdat hiermee de doorvoersnelheid hoger wordt? Wat voor grootte had je in gedachten als 'ideaal'?

Wellicht zou dit soort optimaliseringen een makkelijke ''quick fix'' zijn... Een goede backup van 1TB ergens in een hoekje wegzetten (vrijdagbackup) of op een portable hardddisk ofzo, en je hebt het hele weekeinde om met de clustersize te spelen...

[tc982]

Even wat op mijn topic reageren Was even op vakantie geweest.

Er moet bij de klant inderdaad wat rechtgezet worden. En ze zouden veel beter af zijn zonder BE en met VEEAM. Veel sneller en meer geoptimaliseerd voor backup 2 disk. Een ondergechoven kind bij BE.

Momenteel zijn de Hyper-V agents in BE 2010 R3 zeer traag. Dit is volgens Symantec een normale snelheid, en is te verwachten. Misschien dat de nieuwe versie ( 2012 ) , hier sneller in is.

Ik neem de volgende zaken mee :

- Apart backup netwerk aanleggen
- Verschillende jobs naast elkaar laten lopen
- Weekend Full -- Incremental in de week
- Copy Jobs naar de storage server.

[Ethirty]

Ik heb door de jaren heen met verschillende versies van BE gewerkt, maar het staat of valt vaak met de inrichting van de jobs. Hoe is je B2D ingesteld? Gebruik je meerdere van de iSCSI poorten op de controller? Zitten de snapshots van de 2e server qua looptijd niet in de weg op het iSCSI netwerk?

[kroegtijger]

bigfoot1942 schreef op zondag 15 april 2012 @ 15:28:
[...]


Begrijp ik je goed als ik zeg dat je een kleinere blocksize had gewenst, omdat hiermee de doorvoersnelheid hoger wordt? Wat voor grootte had je in gedachten als 'ideaal'?

Wellicht zou dit soort optimaliseringen een makkelijke ''quick fix'' zijn... Een goede backup van 1TB ergens in een hoekje wegzetten (vrijdagbackup) of op een portable hardddisk ofzo, en je hebt het hele weekeinde om met de clustersize te spelen...

Een "ideaal" heb ik nog niet echt gevonden; het lijkt op elke machine weer anders te zijn. Het hoe en waarom precies is me wat dat betreft nog een raadsel, maar bij traagheid is meestal het verkleinen van de blocksize een manier om snelheidswinst te krijgen. Beetje mee rond spelen en trail and error gebruiken. Na een tijdje kom je vanzelf het meest optimale voor de omgeving tegen. Maar het blijft crappy naar mijn mening dat je met dit soort oplossingen een fatsoenlijke backup moet gaan maken... Na al die jaren is het nog steeds maar behelpen