Teveel bestanden om binnen backup window te backuppen*

[Ghibli]

Hoi

Om het kort te beschrijven: ik beheer een win2k server met +- 58Gb aan worddocumenten erop
Het gaat dus om meer dan een miljoen bestanden.

Verder bevinden er op die schijf ook nog eens +-10Gb aan databases.
Thuiswerkers mogen in het systeem werken tot middernacht, dan start de backup.

Probleem: backuppen duurt nu tot na 7u 's ochtends met een LTO2 tapedrive, dus tot na dat mensen al aan het werken zijn. De hoeveelheid worddocumenten word alleen maar groter.

Als ik de backup bekijk als hij draait doet hij die 10Gb aan databases (mostly 100mb+ files) in no-time (20 minuten). Gewoonlijk tussen de 10 en 12 mb/sec.

Zodra hij aan de worddocumenten begint (90kb files ofzo) zakt de backupsnelheid ENORM. Ik vermoed dat dat ligt aan de tijd die nodig is om de verschillende bestanden te openen, aanmaken, opvullen en sluiten. Grote bestanden = snel, kleine bestanden = supertraag.

Om nu tot een oplossing te komen dacht ik, misschien bestaat er wel een soort virtual filesystem. Denk daemon-Tools-achtig. Als ik alle documenten kan bundelen tot 1 groot bestand, en dat bestand kan mounten als schijf, waar zowel realtime van gelezen als naar geschreven kan worden, dan zou het probleem van de baan zijn. Read en write performance van die worddocumenten is van ondergeschikt belang, pak dat er op piekmomenten op een minuut een bestandje of 20 bijkomt, en een bestandje of 6 gelezen word.

Bestaat zo'n virtual filesystem? Zijn er risico's? Weten jullie misschien een betere oplossing?

Heel erg bedankt
Ghibli

[AcoLyte!]

Backup to disc? *hoest* Data *proest* Domain *kuch*

[ Voor 54% gewijzigd door AcoLyte! op 08-10-2007 19:20 ]

[Ghibli]

@Acolyte
Je bedoelt de volledige schijfinhoud gewoon kopiëren naar een andere schijf, als backupsysteem?

Ik vrees dat het probleem blijft bestaan hoor. De LTO2 drive kan makkelijk 10mb/sec streamen, het probleem ligt eerder bij het inlezen van de bestandjes dan bij het wegschrijven.

Heb een tijdje geleden nog een aantal "oude" documenten (van voor 2001) gearchiveerd en permanent van de server gehaald, en het kopieren van die bestandjes ging ook tergend langzaam, en dat was wegschrijven van een U320 SCSI disk naar een U320 SCSI disk, dus aan het medium zal het ook niet liggen

[Ghibli]

Ik heb even het DataDomain verhaal bekeken, en dat zou misschien wel een oplossing kunnen zijn, maar ik vind nergens prijzen terug. Ik heb een vermoeden dat we hier spreken over een zeer veel geld.
Prijzen vind ik nergens terug
Ik wil gerust investeren in de redundancy van ons systeem (wat moet, dat moet), maar het mag natuurlijk niet buiten proporties....

Enig idee?

PS: Feit blijft ook dat al die kleine bestandjes niet lekker werken. Een simpele CHKDSK duurt 3 uur, zeer vervelend...

[ Voor 13% gewijzigd door Ghibli op 08-10-2007 19:44 ]

[hstuivenberg]

Waarom doe je niet 1x per week een full backup en de rest van de week alleen maar gewijzigde files?

En anders iets als Continues Protection van BackupExec of Data Protection Manager van Microsoft.

[Ghibli]

Die Data Protection Manager lijkt me heel interessant, zal ik eens verder onderzoeken, bedankt!

Neemt natuurlijk nog altijd niet weg dat die gigantische directorytree enorm log is en niet lekker werkt. Als er toch iemand een "1 big file" oplossing kent, feel free to share the knowledge, ik google ondertussen lustig verder

Ghibli

[McMiGHtY]

Dit heb ik ook gehad een tijdje terug bij een klant van ons waar ik gedetacheerd zit, alleen dan met ongeveer 300Gb aan kleinere bestanden, hiervan begon de backup om 18:30 en was de volgende ochtend nog niet klaar.

Wij hebben toen gekozen voor een Backup2Disk2Tape oplossing. Hiermee kwamen we niet in de problemen met onze timewindow en hadden we overdag genoeg tijd om de backup naar tape te gooien. Bijkomend voordeel was dat de restoren op de dag zelf een stuk vlotter ging. (zeker als je bedenkt dat de 300Gb backup 3 tot 4 dagen op disk kon blijven staan)

[Ghibli]

Welke software gebruikte je daar? Er is blijkbaar veel keuze in B2D2T oplossingen, en ik wil natuurlijk vermijden dat het B2D gedeelte nog steeds oertraag gaat

Ghibli

[Xiphalon]

Het wordt waarschijnlijk zo langzaam omdat de MFT (FAT van NTFS) enorm groot is.

Is het splitsen van het volume en dan losse stukken mounten niet iets voor je?

Zo kan je bijvoorbeeld splitsen op datum, zodat je per jaar (of kwartaal of maand) een aparte NTFS volume krijgt, welke niet vaak meer geschreven wordt zodat het e.e.a. binnen de perken blijft.

Problemen zijn wel dat vrije ruimte managen lastig kan worden, en dat de directorystructuur aangepast moet kunnen worden/al goed is.

[edit]
Is een Document Management Systeem anders niets voor je? Moet je wel gebruikers opleiden, maar worden de doucmenten in een database opgeslagen, welke dus wel uit grote files bestaat.

Een voorbeeld is Microsoft Office Sharepoint Server, maar gezien de grootte zou ik die niet gebruiken.

[ Voor 23% gewijzigd door Xiphalon op 09-10-2007 08:32 ]

[SkyStreaker]

offtopic:
Je hoeft niet constant "Ghibli" neer te zetten, we weten wie je bent

[Ghibli]

@SkyStreaker : Sorry, macht der gewoonte

@Darkmage : Dat zou inderdaad wat makkelijker zijn in veel opzichten, maar of het echt sneller gaat backuppen betwijfel ik.
We gebruiken trouwens reeds een Document Management System (vrij uitgebreid pakket dat geschreven is in Magic), en alle documenten worden van daar uit opgebouwd en aangeroepen, dus voor de eindgebruiker is de gigantische directorystructuur helemaal geen punt, het is eerder voor mij.

Een tijdje geleden hadden we bijvoorbeeld problemen met die schijf, de logical disk (RAID-1) met alle documenten erop ging offline (geen idee waarom, die PERC4 controllers van Dell zijn blijkbaar rommel) en 1 van de schijven was dus defect. Schijf eruit gehaald maar intussen bleek dus dat er op de andere mirrorschijf een aantal filesystem beschadigingen waren. Gevolg: 3 uur chkdsk en iedereen naar huis mogen sturen.

Akkoord, als er problemen zijn dan kan dat gepaard gaan met downtime, maar 3 uur voor een beetje scandisken is nogal belachelijk. Elk worddocument dat we hebben kan in principe opnieuw opgebouwd worden vanuit de applicatie, dus als we een dag aan documenten kwijt zijn dan is dat geen ramp. Daarom dat ik dus dacht van "zou er geen virtual filesystem bestaan dat alle worddocs bundelt in 1 bestand". Dat bestand kan dagelijks gebackuped worden, dus moest er een corruption ontstaan binnen dat bestand, dan kunnen we gewoon makkelijk de backup terugzetten en zijn we eigenlijk niets belangrijks kwijt. Een Microsoft Virtual PC harddrive klinkt bijvoorbeeld als iets dat perfect zou kunnen dienen als je zo'n harddrive zou kunnen mounten buiten de eigenlijke virtual machine

[remco_k]

Heb je soms mappen waar erg veel files in staan?
Wij hebben voor onszelf richtlijnen opgesteld dat we niet meer dan 15000 files in 1 map zetten.
Dan gaan we verder in een andere map.
Aangezien er bij 10000 of meer (dacht ik uit het hoofd) al meetbaar vertraging onstaat, alleen al om te kijken of een file bestaat b.v.

Om even een praktijkvoorbeeld aan te halen:
1 map met 90000 files, kopieer een 1kB file naar een lokale disc. Dat duurt meer dan 10 sec.
Zelfde machines, zelfde netwerk, zelfde map maar nu met 1000 files. Kopieer een 1kB file naar een lokale disc. Meteen klaar.

Misschien is er zoiets ook bij jouw aan de hand, en dat kan je dan voorkomen door wat meer in mappen op te splitsen.

[Verwijderd]

Ik gebruik 7-zip als test op dit moment en dan via de compressiesetting die de streamsnelheid van de tape aardig bij kan benen. De 7-zip leest geen EXIF en Metadata en het gaat zo een groot archief in. Solid als je wenst.

Onze back-up op tape 18,77 GB
7-zip doet het 3x vlugger en houdt 4,12 GB over

Wil je het bestand eenmaal bijwerken op regelamtige basis, kies dan voor de .TAR indeling.

Ik heb weinig kennis over de WIM indeling, maar daar moet jij eens naar gaan kijken. Het is de imagesetting van Vista die volgens mij ook werkt op XP. Het schijnd een heel fijne methode te wezen? Van horen zeggen.

[ Voor 33% gewijzigd door Verwijderd op 09-10-2007 09:18 ]

[Xiphalon]

Als je de boel opsplitst gaat het chkdsk'en ook nog sneller.

NTFS wordt buitenproportioneel traag als de MFT niet meer goed te cachen valt. Bovendien wordt de MFT veel te groot door lees en schrijfbewerkingen, en dat ondervang je een stuk met een bak volumes.

Maar als alles te hergenereren is waarom backup je dan?

[Verwijderd]

darkmage schreef op dinsdag 09 oktober 2007 @ 09:18:
Als je de boel opsplitst gaat het chkdsk'en ook nog sneller.

NTFS wordt buitenproportioneel traag als de MFT niet meer goed te cachen valt. Bovendien wordt de MFT veel te groot door lees en schrijfbewerkingen, en dat ondervang je een stuk met een bak volumes.

Maar als alles te hergenereren is waarom backup je dan?

Denk eens na...

Onze back-up lijst is 27,92 GB en bestaat uit 281.455 bestanden. 7-zip heeft met de zwakste compressiesetting ongeveer 3 uur nodig om het geheel op tape te persen in tegenstelling tot een hele nacht. Én het stomme punt wat mijn baas het meeste aansprak was niet mijn idee, maar het feit dat de tapes doordat ze minder lang in bedrijf zijn minder snel slijten. Het is en blijft een figuur, die baas van mij

[ Voor 16% gewijzigd door Verwijderd op 09-10-2007 09:33 ]

[Koffie]

Toch zou ik ook voor ZIP/RAR/TAR arxhivering kiezen.
Het is een bekend feit dat de meeste backup jobs gigantisch vertragen op directorys met heel veel kleine files.

Ik heb ooit een soortgelijke situatie gehad, en daar heb ik een script gemaakt wat eerst alle te backuppen files in een (dacht ik) TAR zet.
Vervolgens alleen die TAR backuppen.

Je hoeft niet perse te compressen, dat kun je ook aan je unit/backup software overlaten.
Gewoon archiveren zonder compressie en dat bestand in de backup meenemen.

[Verwijderd]

Koffie schreef op dinsdag 09 oktober 2007 @ 09:32:
Toch zou ik ook voor ZIP/RAR/TAR arxhivering kiezen.
Het is een bekend feit dat de meeste backup jobs gigantisch vertragen op directorys met heel veel kleine files.

Ik heb ooit een soortgelijke situatie gehad, en daar heb ik een script gemaakt wat eerst alle te backuppen files in een (dacht ik) TAR zet.
Vervolgens alleen die TAR backuppen.

Je hoeft niet perse te compressen, dat kun je ook aan je unit/backup software overlaten.
Gewoon archiveren zonder compressie en dat bestand in de backup meenemen.

Net zogoed punt en dat zei ik al verkapt door het TAR formaat te kiezen. TAR is een bulkarchief dat niet gecomprimeerd is, maar 7-zip op de zwakste LZMA compressie gaat veel dieper als de software van de streamer om de volgende redenen:
1. het woordenboekgrootte van LZMA kan 96 MB zijn in tegenstelling tot de 4 KB van MSbackup!
2. Voor veel worddocumenten en databases kun je het beste PPMd gebruiken met een woordenboekgroote van 1024 MB+.

code:

Dictionairy size:
woordenboekgroote 1024 MB. Stel dat er na 900 MB weer een datastream komt die
voor 99% lijkt op de eerste stream van 900 MB terug. Dan kan 7-zip alsnog deze
streams muxen zodat je maar 2% van de 2 bestanden overhoudt, dus 1% per
bestand. Aangezien veel documenten het GGZ logo als macro hebben komt dat
GGZ logo zovaak voor dat 7-zip over een lengte van 1024 MB alle logo's als één
logo kan opslaan, snap je. Neem je een grootte van 64 MB dan kan dat maar over
de laatste 64 MB en dat hakt erin

Met jouw idee zijn streamers nog steeds lang in bedrijf. 7-zip doet het zo en die kun je direct naar de back-up software voeren en je kunt je 7-zip archief ook spannen in 64 MB chunks.
Heb je dus 180 GB te back-uppen dan kun je elke 1000 chuncks een set maken terwijl de 2e 1000 chuncks beginnen zodat je synchroon blijft, snap je? Dat bespaard 1/3 aan tijd.
7-zip kent bij het comprimeren de mogelijk dit in de achtergrond te doen zodat je kunt gaan streamen.

Zo ben ik aan het testen op het werk en de reacties zijn aardig positief. Het hoofd automatisering van heet het GGZ had wel intresse En toch ben ik er nog niet.

Met PPMd haal ik een ratio van 47,6 op 1 met word documenten en soms nog hoger. Ik heb ooit 1900 documenten op één diskette weten te krijgen met 7-zip. (dit is géén grootspraak)

PS: Omdat we Vista hebben sindskort hoef ik alleen nog maar te zoeken op de wijzigingen in alle bestanden voor de incrementale ronde. Dat gaat zo handig.

[ Voor 27% gewijzigd door Verwijderd op 09-10-2007 09:54 ]

[Koffie]

Op zich wel een punt, maar als je de backup tijd terug weet te dringen tot een acceptabele tijd (laat zeggen 4 uur ?) maakt het mij weinig uit of het nu 3.5 of 4 uur is

Maar idd, er zijn legio oplossingen waarbij archiveren (al dan niet met compressie) volgens mij de beste oplossing is.

[elevator]

Ik pas even je topic titel aan zodat het wat duidelijker is wat je precies bedoelde

[Verwijderd]

Een Microsoft Virtual PC harddrive klinkt bijvoorbeeld als iets dat perfect zou kunnen dienen als je zo'n harddrive zou kunnen mounten buiten de eigenlijke virtual machine

VHDmount uit Virtual Server zou je kunnen gebruiken:
http://blogs.msdn.com/vir...ount-with-virtual-pc.aspx

[Verwijderd]

Het zou voor een groot bedrijf de ideale oplossing zijn om een on-line back-up dienst te nemen of om de back-ups bij elkaar op te slaan dus de back-up van Oss gaat bijvoorbeeld naar Berghem op Zoom en deze gaat weer naar Rozendaal en noem maar op. Dat plan probeer ik ook door te drukken. Dan zou ik mijn idee nog beter kunnen implementeren. Het zal dan wel prutsen worden met batch files. Gelukkig is 7-zip ook te syntaxen met een commandoprompt, dus .bat files.
Het leuke is dat 7-zip gewoon gratis voor dit soort doeleinden gebruikt mag worden.

Een waarschuwing is op zijn plaats. PPMd neemt een danige hoeveelheid RAM in beslag dat je beter af bent met de 64-bit versie van 7-zip. Hiermee kun je ziekelijk hoge ratios bereiken.
Onze server is 64-bits en de PPMd die ik gebruik is 1536 MB (2 GB grens probleem per thread). Zou ik een woordenboekgrootte kunnen gebruiken zo groot als de hele back-up dan zit je echt gebakken, maar onze server heeft maar 4 GB aan RAM en moet operationeel blijven.
Overwegen dus om een zwakke compressiezwaarte in te stellen anders gaan users klagen.

[ Voor 33% gewijzigd door Verwijderd op 09-10-2007 10:05 ]

[Ghibli]

@Remco_k: niet zozeer veel bestanden binnen 1 map, eerder veel mappen binnen 1 map.
Op de schijf bevind zich een map "Documenten", met daarin een map voor elk van de 224000 dossiers die we hebben. Ieder dossier heeft tussen de 1 en 25 worddocumenten in zijn map.

@Exuimtum: ik zal 7-zip en TAR archiving eens bekijken, vanavond testen hoe snel die hun werk kunnen doen.

darkmage schreef op dinsdag 09 oktober 2007 @ 09:18:
Maar als alles te hergenereren is waarom backup je dan?

Niet alles, maar 1 dagje worddocs kwijt kan geen kwaad. De databases zijn veel belangrijker.

[Verwijderd]

*Weet niet of dot TAR metabestanden ondersteund of NTFS streams. Van 7-zip en het WIM formaat weet ik het wel.

Verder is het onwaarschijnlijk dat werknemers streams gebruiken. Daar hoef je niet vanuit te gaan, maar voor de server zelf nóóit een utility van derde gebruiken en vertrouwen op de eigen kracht van recovery zoals Guardian Angel of dergelijke. 7-zip bedoel ik dus voor user data en niet statische systeemdata, pas op voordat men dadelijk ineens roept dat ze wat missen.

[ Voor 71% gewijzigd door Verwijderd op 09-10-2007 21:02 ]

[Verwijderd]

Een hele primitieve oplossing die ik nog wel eens gebruik voor scholen die echt geen geld hebben is het freeware Imageburner. Daarmee maak ik per klas/leerjaar of wat ook voor elke klasse een eigen ISO aan. Elke ISO brand ik dubbel of triple. Zo hoef je niet de hele set af als je data uit een schoolsegment moet bijwerken mits je intelligent gesorteerd hebt en dat is mijn werk.

De ISO bestanden kopieer en trouwens ook op de schijf van de server, gaat sneller als het mis gaat per set, snap je? Zorg ook de ze volledig gedefragmenteerd zijn zodat een eventuele echt nood recovery zo snel en goedkoop mogelijk verloopt, dat is onze taak.

Falen is geen optie, dus je moet altijd je kop er voor 100% bijhouden en dat met 2 man per server, zo secuur is dat. We moeten elkaart checken willekeurig. Het gaat om erg belangrijke data.

[ Voor 38% gewijzigd door Verwijderd op 09-10-2007 22:22 ]

[Rolfie]

+-58Gb, het gaat dus om meer dan een miljoen bestanden

Offtopic:
Daar lacht Rolfie om. Momenteel heb ik een server draaien met 10,5 Miljoen bestanden op 160Gb. Dit bestaat uit een root directorie en daarin 53000 directories. Das pas een uitdaging, letterlijk. Een Incr backup duurt al iets van 5,5 uur en dan zijn er maar 10.000 bestanden gewijzigd. Ik durf over een chkdsk niet eens te denken.

Om je chkdsk tijd te verlagen kijk dan eens naar mountpoints. Zo behouden we bij ons ook de disken klein. Je zou zelf kunnen kijken of je backup applicatie meerdere streams tegelijkertijd aan kan. Dan backup je meerdere disken (mountpoints) te gelijkertijd.
Kijk eventueel eens naar je virusscanner, zit die niet tussen de backup applicatie. Dit kan je veel, heel veel IO kosten. Database files zijn vaak al uitgesloten door de virusscanner, office files niet.
Zijn je disken wel goed gealigned gezet [googel=exchange diskpar]. Bij een verkeerde alignment verlies je hier zeer veel IO’s mee .

Maar ik denk dat de beste mogelijkheid is om inderdaad een backup to disk oplossing te nemen. Gewoon een grote disk er bij plaatsen (liefst een andere server), en hier eerst je backup naar toe laten schrijven. Gewoon incrementals/differentials daaien door de weeks en in het weekend een full van je office data. De rest (exchange, AD, database files altijd Full nemen).

Je bent nu met een backup oplossing bezig, maar denk ook eens na over je restore mogelijkheden en vooral je snelheden. Want dit gaat altijd langzamer dan de backup.

[Verwijderd]

Heel goed punt Rolfy!

Disk uitlijning! of beter gezecht; partitionalignment
Wat Windows XP goed doet en Windows Vista ook is de clusters van NTFS en haar structuren uitlijnen zodat ze precies in een track passen en niet 2 sectoren eroverheen want dan kost je het 2 omwentelingen om 1 track te lezen dus performanceloss.
Partion Magic kijkt nergens naar en zet je bootsector al meteeen op de eerst beschikbare sector, trieste zaak want dat scheeld inderdaad 16-40%.

Op mijn post van Vista's defrag is nooit gereageert, maar dat is onkennis want laat die kale saaie defragmenter die zo wordt afgezeken nu zijn bestanden perfect uitlijnen! Dus je hebt wel fragmenten over, maar nooit kleiner dan 64MB en dan heb je geen loss, maar dit wordt wel moeilijk denk ik nu. het scheeld ook in werktijd terwijl je een gezonde afweging maakt tussen 0,02% performance loss en 2x zo snel klaar zijn of voor 100% gaan en uren bezig zijn terwijl na een half uur je weer fragmenten hebt, ik weet het niet hoor

De software die jij aanhaalt gebruiken wij ook en dan zie je dat de bootsectyor niet op sector 33 staat maar ineens op sector 64. vergelijk het met een autoband die niet recht loopt. dat kost onnodig energie, hij is nog steeds snel, maar het kan toch nog beter.

Ik weet niet of jonge tweakers hier het probleem nog kennen van het converteren van FAT32 naar NTFS [Windows 2000] waar je 512 bytes clusters overhield wat verre van optimaal was en je systeem cripple maakt!

[ Voor 20% gewijzigd door Verwijderd op 10-10-2007 16:03 ]

[elevator]

Standaard lijnt XP en 2003 ook niet goed uit hoor (van Vista weet ik het niet): Disk performance may be slower than expected when you use multiple disks in Windows Server 2003, in Windows XP, and in Windows 2000

[Rolfie]

Disk uitlijning! of beter gezecht; partitionalignment

Om het nog mooier te maken. Zorg er voor dat de alignement ook met de Cache van de Array controller (mits je er 1 in hebt zitten) goed staat. Hier is alleen zeer weinig over te vinden..... Helaas