Afdrukvoorbeeld
de schijven liggen ergens anders.
zodra ik ze nodig heb plug ik ze weer in (usb diskjes)
24x7 heb ik ze niet nodig en 75 euro voor een jaarlijkse backup vind ik persoonlijk niet zo duur.
We hebben ze tenminste dat geeft voor de meeste klanten wel een fijn gevoel
de meeste hosters hier hebben nog nooit van backups gehoord.
ohja ze liggen niet thuis of datacenter maar op externe locatie.
just in case er iemand ze wilt jatten.
RAID is natuurlijk geen goede backup. Wat doe je als je bijvoorbeeld gehacked wordt en data weggegooid is? Op de 2e harde schijf is het dan net zo hard weg :]
Dan ben ik 1 dag kwijt, backups worden ook offsite opgeslagen.Citaat:
Oorspronkelijk geplaatst door eMiz0r
dan zet ik even alles terug.
Beetje isp mag toch wel de nodige recenter patches uitvoeren toch ?
up2date blijven is ook iets waar je aan moet denken.
Mocht een schijf gewist worden kan je met de nodige tools de data terug zetten.
maar beste is een clean instal en met je meest recente backups terug zetten.
De oorspronkelijke vraag was hoe backups te maken van 2TB en groter... Ik kan mij niet voorstellen dat er hier ISPs zijn die elke dag 2TB aan data over een netwerklijntje pompen als backup...
Ik ben dus benieuwd naar de oplossing(en) die ISPs gebruiken om backups in deze orde van grootte bij te houden.
Pak een storage met een zooitje raidcontrollers, schijven en extra nics. Zorg dat je netwerk infra voldoende traffic kan aanleveren om die schijven goed aan de gang te houden. Gebruik een lokaal vlan, gb switches (eventueel dedicated voor je backup lan).Citaat:
Oorspronkelijk geplaatst door Paul Z.
Gebruik iets zoals bacula om je backups te schedulen en config dat ding voor gelijktijdige backups. (meerdere bacula storagedaemons definieren). En blazen met die handel.
En goed opletten wat je de klant voor een server levert. Als je weet dat ie 500 gb per dag gaat backuppen, dan weet je ook dat je 2 nics aangesloten moet hebben, dat een dualcore (onder dat proces) het best moeilijk kan krijgen, je moet snellere schijven moet hebben omdat je tijdens een backup zeker 80mb continue over je backup-lan moet kunnen jagen, zonder dat de mysql of http eronder gaan lijden. (500gb duurt uren tenslotte).
Maar met dat soort hoeveelheden per server speek je toch meestal over maatwerk dat per klant/budget kan verschillen.
Meestal volstaat het dat je het gewijzigde backupt. Het lijkt me stug dat op een 2 TB volume meer dan 100 GB aan storage is veranderd, dus dan ben je al snel een stukje sneller klaar. Als je gebruik maakt van een SAN/NAS ben je al stukken sneller klaar, en als je 'real time' dupliceert naar een mirror server (SANinRaid dus =P) kan je 1 van de SAN's laten backuppen, terwijl de klant er geen last van hoeft te hebben. (die roept san 1 de hele tijd aan)
RSYNC of een van de andere differentiele / incrementele tools gebruikenCitaat:
Oorspronkelijk geplaatst door Paul Z.
Er zijn net zoveel oplossingen als de weg naar rome.. de een backupt zijn 10 GB naar een opslagserver over het frontend interface, de ander doet er 200 GB overheen, weer een ander zet een apart backup netwerk op en gebruikt dat voor backups en weer een ander schrijft alles naar tapes.
Ik ben van mening dat elke hoeveelheid te backuppen valt, zolang je storage maar voldoende schrijfsnelheid heeft om het 1 gbit/10gbit netwerk bij te houden.. budget is dan ook een belangrijke factor :)
Wij: apart backup netwerk met storage server (4x 500 GB raid 5)
Wij draaien dit zelf op een lokale backup server welke iedere nacht 1 backup maakt van alle andere servers (12x 1 TB RAID6) en op een een externe backup server draaien wij de archieven van maximaal 5 dagen (voor alle servers). Deze bak is een 24 x 750 GB server. We draaien incremental backups zodat we niet constant de volle knal traffic hebben :D
Ja, die zijn er zeker.Citaat:
Oorspronkelijk geplaatst door Paul Z.
Wij hebben aan backup opslag in totaal 19TB aan opslag (verdeeld over 4 servers).
Per dag genereren we ongeveer 4TB aan dataverkeer met de backups maken.
Dit gebeurd allemaal met Bacula, werkt prima!
Waar je alleen op moet letten, wanneer je 2TB opslag hebt, dan kunnen je IOps wel eens een probleem worden bij de verschillen vinden, dus let vooral daar op, want als je onderliggende storage te traag is kan dat je flink gaan nekken bij het backuppen er van.
Wido,Citaat:
Oorspronkelijk geplaatst door Wido
Die 4TB aan verkeer is verdeeld over de 4 servers neem ik aan? Anders zit je minimaal vast aan een enkele 10GB lijn naar de server die de backups verwerkt. Immers over een 1GB lijn geeft je max ~400GB/uur, met andere woorden 10 uur voor 4TB.. Zelfs verdeeld over 4 servers heb je nog min 2.5uur nodig. (Even geen netwerk overhead en disk overhead meegerekent...)
Ik heb eens rondgezocht op internet naar de verschillende filesystems om te zien of er een filesystem is wat geoptimaliseerd is voor backups. Ik zat zelf te denken aan een filesystem met een extra attribuut zoals op (jawel!) FAT. Daar heb je immers het "a" attribuut wat wordt gebruikt om de backup status aan te geven. Ik kan echter niets vinden voor *nix filesystems.... Want alleen een atribuut controleren zal een grote snelheidswinst kunnen opleveren tijdens het maken van een diff backup...
Na veel lezen op internet en hier lezen wat jullie doen denk ik er zeer hard over na om gewoon naar een iSCSI oplossing te gaan met een taperobot eraan vast. Dit is denk ik toch wel de "eenvoudigste" oplossing voor grotere capaciteiten. Uiteraard zal de iSCSI alleen maar userfiles bevatten en een backup van de backup files. OS lekker lokaal laten staan... :)
Onze backups starten om 23:00 en draaien door tot ongeveer 6 uur in de ochtend en die 4TB is inderdaad verdeeld over 4 servers.Citaat:
Oorspronkelijk geplaatst door Paul Z.
Verder is een iSCSI oplossing leuk, maar je kan alleen snapshots van iSCSI backuppen, een live LUN kan je niet backuppen.
Kan je niet op de iSCSI doos de LUN's via de loopback lokaal mounten en dan zo backuppen?Citaat:
Oorspronkelijk geplaatst door Wido
Ik zit te kijken naar de Open-E oplossingen, en het lijkt er zeer sterk op dat die zijn gebasseerd op een Linux variant... Dus console access zou mogelijk moeten wezen om eventueel lokaal te mounten en de backup te laten draaien...
Ik blijf zoeken... :)