Backup netwerk

[24hosted BV]

Op dit moment backup wij onze linux webservers via rsync en daarnaast worden er dumps gemaakt van de MySQL DB's. De data loopt op tot ongeveer 100 GB per server. De backups worden opgeslagen op een NAS met 6 TB opslagruimte.

Het bestaande proces werkt goed qua backups alleen duurt het maken van een backup erg lang tot 8 uur. Dit probleem komt voort doordat het proces niet optimaal in elkaar zit op dit moment. Ook zijn er momenten dat de webservers 's nachts minder goed bereikbaar zijn, vermoed zelf op het moment dat het aan de MySQL dumps ligt maar weet dit niet zeker.

Nu de vraag: zit te kijken naar compleet nieuw backup proces. Wat is dan de beste oplossing bestaande optimaliseren of direct over naar een andere oplossing. Belangrijk is ook het controleren of backup proces (goed) loopt, bijv. via Nagios? Lees veel over Bacula maar wat zijn de voor en nadelen. Zeker betreffende performance van de server die gebackuped wordt. Indien nog andere oplossingen die aangeraden worden dan hoor ik het graag.

[t.bloo]

richt je server in met een filesystem dat snapshots ondersteund, vervolgens kun je de snapshot rustig met rsync backuppen

met een --bwlimit kun je de rsync vervolgens minder "zwaar" maken voor de server door de disk IO te beperken

mysql dump kun je omheen werken door eerst te locken, dan te flushen, daarna te snapshotten en vervolgens te rsyncen

[systemdeveloper]

Gebruik je gewoon een 'kale' rsync die bv. over ssh de backup trekt of heb je op de servers zélf een rsync daemon draaien? Dat laatste werkt een stuk sneller is mijn ervaring. Probeer ook te voorkomen dat je backupserver zijn storagespace via nfs oid koppelt. Je knalt dan namelijk je traffic al 2 keer over je nics (en met name de rsync checks van welke bestanden wel/niet gesynched moeten worden duurt een eeuwigheid).
Met de --bwlimit beperkt je het traffic over het net, niet richting disk voor zover ik weet (al is het een wel enigszins gerelateerd aan het ander).

In 9-10 gevallen duurt het gewoon lang omdat je a) maar over 1 nic backups trekt en niet over bv. 2-4 nics in lacp, b) de raidarray van de storage gewoon niet in staat is om paar 100mb/s te schrijven (bij bonds van meerdere nics dus) of dat je remote over een 100mb link je backups trekt ipv over je eigen lokale vlan met de GB speeds.

[24hosted BV]

Paar van jullie punten ben ik al naar aan het kijken geweest. Maar Bacuda of iets anders of toch bij rsync blijven?

[LAMP-host]

misschien een idee, gewoon een vermelding dus... het commando "dump" is in staat om een full , incremental of differential backup te nemen van de data op de HD. Hiermee bedoel ik dus niet zoals het commando 'dd' doet de hele schijf backuppen maar dump doet dat sector voor sector die echt in gebruik is. Met het commando "restore" kan je de data weer terugzetten. 1 nadeel is dat hij de bootsector vergeet maar dat is wel te fixen door ff met knoppix te booten en grub commando te runnen.

[Randy]

Wanneer je veel submappen hebt in bijvoorbeeld de /home, rsync dan per letter, dus /home/a*, /home/b*. Dat scheelt in load. Voor de MySQL backups: deze zou ik zelf van een slave maken. Richt dus een slave-server in en maak hier de dumps, zodat de gewone database-server hier geen last van heeft.

Wil je een compleet nieuw systeem, kijk dan eens naar Retcon. Dit maakt gebruik van ZFS en dus snapshots. Nederlandse ontwikkeling. Een andere optie zijn back-ups op block-leven maar dit gaat je _veel_ ruimte kosten wanner je een behoorlijke retentie wilt opbouwen omdat er (nog) geen goede dedup opties zijn.