De I in RAID staat niet voor niet op Inexpensive, maar voor independent .
Wikipedia: RAID
Oorspronkelijk ging het inderdaad om (relatief) goedkope disks en stond de I voor Inexpensive, maar dat is al heel lang niet meer zo. RAID word juist ook toegepast in situaties waar high-end disks worden ingezet. De betekenis van de I is dus veranderd en daarmee klopt jouw argument van "goedkope disks" niet meer.
Qua snapshots, zoals gezegd, die zijn inherent immutable. Je kunt niet een bestand in een eerder gemaakt snapshot aanpassen, ook niet als dat bestand op hetzelfde systeem staat. Het enige wat malware zou kunnen doen, is het complete onderliggende filesystem corrumperen maar dat zie je voor zover ik weet eigenlijk nooit gebeuren. De focus ligt op de actuele bestanden.
In de meeste gevallen zet je na lokalisatie, isolatie en stoppen van de malware, je snapshots terug en gaat verder tot de orde van de dag. (Evengoed een flink karwij, maar juist als je je snapshot strategie goed op orde hebt, hoef je niet terug naar je tape backups.)
[...]
Dat ontken ik ook niet, en wellicht zijn deze scenario's wat je bedenkt onder andere de
- falende disk
- F*ck up van een upgrade
ja dan kan een snapshot en RAID erg prettig zijn omdat je dan niet met downtime zit of minder .. downtime.
Maar zonder goeie backup:
- kan een raid plat gaan (bij het insert-en van disk)
- snapshot corruptie introduceren ipv weghalen/ontwijken.
Dan ben je blij dat een je vooraf in je procedure hebt staan dat een een FULL backup is geweest van je systeem
Je ziet mij toch nergens bewerend dat het niet aan te raden is offsite backups te maken? Die beschermen tegen al het bovenstaande, inclusief andere ellende als brand en diefstal. Ofwel, alle scenario's waarbij compleet verlies van je opslag het geval is en precies dat heb ik al benoemd.
EDIT:
Overigens kun je snapshots op meerdere niveau's maken en ieder heeft zijn eigen toepassingsgebied. Je kunt ze al dan niet combineren. In een bedrijfssituatie heb je heel snel te maken met 3 lagen. Van beneden naar "boven":
Storagelaag (NAS, SAN)
Virtualisatielaag (Hypervisor)
OSlaag (binnen de vm)
Snapshots op de storagelaag werken niet altijd of niet altijd volledig op bestandsniveau en zijn vooral voor het restoren van complete volumes. Voordeel: ze liggen heel erg ver af van de eventuele malware en datacorruptie waar ze tegen moeten beschermen.
Snapshots op de hypervisor laag zijn handig bij upgrades of als je grote wijzigingen aan een systeem gaat doorvoeren. Je maakt een snapshot, voert de upgrade door. Gaat dat goed, verwijder je het snapshot. Gaat het niet goed, doe je een rollback en heb je exact de situatie waar je mee begon. (Ook dit beschermt overigens prima tegen malware, die kan er totaal niet bij.)
Snapshots binnen de vm zijn op hun eigen manier weer handig. Dit is bijvoorbeeld hoe, als je een Windows vm als fileshare hebt, dit praktisch in te zetten is. Mensen zien snapshots in hun "previous versions" tab en kunnen zelf eenvoudig terug naar een vorige versie. Kan ook handig zijn bijvoorbeeld wijzigingen op databases. Databases op een apart filesystem, snapshot maken, grote wijziging doorvoeren en gaat dat niet goed, snapshot terug rollen. Het nadeel is dat dit nu net een scenario is waarbij malware in principe bij het filesystem kan en op dit niveau data kan corrumperen.
Welke van die 3 je moet gebruiken en wanneer is niet echt een wet van meden en perzen en nogal situatie afhankelijk. Wel beschermt de bovenste (snapshots op je storagelaag), het beste tegen malware. (Het grappige is dan wel weer dat een beetje NAS, zelf SMB kan aanbieden en zijn snapshots ook weer als "previous versions" kan tonen aan een client. Handig bij een snelle restore en malware kan d'r helemaal niets mee. Dat kan hooguit een actief bestand corrumperen, nooit het snapshot.)
[...]
Dit is gewoon te sneu voor woorden .. ik zou je digitale mond moeten spoelen met zeep voor deze belediging
Wat jij verward is uptime en downtime stratigie-en
Een Disaster Recovery (DR) en dus downtime betekend dat je voorbij het punt bent dat je kan herstellen, in het geval van RAID betekend dit dat je hele Array eruit geklapt is. EN/OF je snapshot zodannig onbruikbaar is dat je systeem niet bruikbaar is voor het bedoelde doeleinde.
Maar ja een snapshot restore van een productie financiele administratie is ook niet erg wenselijk of wel ??
stel dat men net met jou salaris aan het "knoeien' waren .. tja ..
RAID is onderdeel van je uptime stratigie, en zorgt ervoor dat je niet uit je bedrijf door kan draaien terwijl een disk defect raakt,
Wikipedia: Disaster recoveryIn addition to preparing for the need to recover systems, organizations also implement precautionary measures with the objective of preventing a disaster in the first place. These may include:
- local mirrors of systems and/or data and use of disk protection technology such as RAID
Dat maakt dingen als snapshot en RAID toch gewoon onderdeel van je totale DR strategie? Je wil namelijk in eerste instantie een "disaster" voorkomen en dus gebruik je technieken die dat doen.
Snapshots stellen je in staat mits goed toegepast dingen te testen bv upgrade van software.
maar op een productie fileserver een 2 weken oude snapshot restoren ??? waarbij een groeie van 1gb per week aan data is ?? nee dankje ik kijk 100x uit dat betekend effectief dat je 2gb vernietigd.
Een snapshot van 2 weken restoren vind je geen goed idee, maar een backup van tape van 2 weken geleden wel?
[...]
juist "kunnen" ,,, dat is het sleutelwoord, ik ga liever op veilig dan "het kan'
De tijdswinst met snapshot bij een DR is marginaal, maar de kans van corruptie is enorm. en backup is een geverifeerd proces daarom duurt het ook langer. Het kan enorm lang duren bij restores van snapshots voordat de corruptie opduikt.
De kans op corruptie bij backup naar tape is net zo groot. Je hebt namelijk vrijwel altijd te maken met actieve bestanden. Je kunt niet even een database volledig offline gooien om een uur lang een kopie van dat ding te maken voordat je 'm weer op start. Hooguit wil je even kort de activiteit bevriezen.
Een snapshot heb je in de regel in een paar minuten tot een paar uur wel terug gezet (het maken duurt hooguit seconden), afhankelijk van de hoeveelheid data. Tape is inherent traag dus duurt per te restoren T veel langer. Ook offsite oplossingen zijn over het algemeen relatief traag. Niet iedereen heeft de beschikking over een offsite lokatie verbonden met een 1GBit of hogere datalink. (Ook bedrijven niet. Die lijnen kunnen akelig duur zijn en lang niet altijd nuttig/nodig.)
Kortom, je tijdwinst met lokale snapshots is gigantisch ten opzichte van offsite oplossingen zoals offsite replicatie of tape. In de gevallen waar je gebruik kunt maken van een snapshot, moet je dat doen. Het minimaliseert downtime.
Voor mkb/thuisgebruik
hoe waardevol is je informatie ? ik brand van tijd tot tijd de data gewoon op een dvd of ander medium
Precies dat zou ik dus afraden.
Een DVD heeft een zeer beperkte capaciteit en het is foutgevoelig (je vergeet het). Handmatig moeten wisselen van media is in bedrijfssituaties prima te doen (daar is het immers gewoon onderdeel van je reguliere werk), privé is het veel te omslachtig. Natuurlijk zijn er mensen die het doen, maar unattended werkt veel fijner. (Ook bedrijfsmatig trouwens. Je wil zo veel mogelijk zaken unattended doen. Een tapewissel word alleen wat lastig tenzij je gaat werken met grote offsite tape robots.)
Er is geen discussie nodig voor tape vs disk, beide hebben unieke voordelen alleen voor consument zou ik gewoon een online disk/backup provider zoeken die aan versioning doet.
Voor de consument is de discussie eenvoudig: Tape is geen zinvol medium want kosten en handwerk om tape te wisselen. Voor bedrijven is die discussie anders. In principe heeft tape altijd voordelen en zou je ook altijd je data op tape willen hebben. Ik snap alleen dat kleinere bedrijven consessies daarin doen en kiezen voor een backup vorm naar disk.
Je spreekt jezelf overigens een beetje tegen. Je vind snapshots geen goed idee, maar raad wel een backup provider aan die aan versioning doet. Met databases word dat sowieso wat lastig. Met de losse bestanden waar jij het waarschijnlijk over hebt heeft het nagenoeg hetzelfde effect.
Sowieso wil je dat er aan de onderkant deduplicatie en compressie word toegepast en hoewel het technisch heel andere oplossingen zijn, is het effect vrijwel hetzelfde.
Of je nu met BackupPC incrementals (versioning) doet of met ZFS snapshots, in beide gevallen kun je terug in de tijd met je bestand. Maar in beide gevallen worden alleen de wijzigingen opgeslagen. In geval van BackupPC zijn dat wijzigingen op bestandsniveau (word een bestand gewijzigd, word het opnieuw opgeslagen maar de deduplicatie zorgt er wel voor dat als je dat bestand 3x hebt, het maar 1x word opgeslagen), in geval van snapshots zoals ZFS die gebruikt is de delta bit-wise.
In beide gevallen heb je een uitdaging als het onderliggende filesystem corrupt raakt.
Bestandscorruptie niet. Je kunt een snapshot maken op maandag, op woensdag en op vrijdag. Op zaterdag raakt je bestand bit-wise beschadigd (corrupt). Je zet het snapshot van woensdag of maandag terug en je bestand is 100% hersteld naar de situatie van dat moment.
Kortom, in de praktijk zijn beide oplossingen prima bruikbaar. Zowel in bedrijfssituaties als in privé situaties.
Snapshots zijn wel veel efficiënter. Ze zijn sneller te maken (zo goed als instant) en nemen veel minder ruimte in omdat het alleen bit-wise delta's zijn.
[
Voor 11% gewijzigd door
unezra op 30-07-2017 07:09
. Reden: Sectie "snapsht niveau's" toegevoegd. Alinea's onder "EDIT" ]
Ná Scaoll. - Don’t Panic.
:strip_icc():strip_exif()/u/289675/crop6401bf2c85501_cropped.jpg?f=community)
/u/417613/crop5df91c60a28d2.png?f=community)
:strip_exif()/u/299377/DEXTER2.gif?f=community)
