Komt eerder als je met zulke grote data werkt je niet zo snel meer spreekt over het woord "backup"
Waarom niet dan?

Ik snap niet zo goed vanuit welk oogpunt je dat zegt. Let me elaborate:
Of ik nou 1KB, 500TB of heel archive.org back-up: het blijft een back-up... Ja toch?

Dat is wat ik meteen al heb gezegd: de hoeveelheid data die je back-upt is niet relevant voor de terminologie die je moet gebruiken. Dat is voornamelijk relevant voor de opslagmethode of de frequentie van wijzigingen aan de data.
Dat het door de hoeveelheid data lastig is om een back-up te maken en er specifieke opslag technieken nodig zijn om de back-up op te slaan, o.a. met distributie en/of replicatie als extra laag - verdeeld over meerdere nodes, verandert niets aan het feit dat je een back-up kan maken en ook nog altijd zal spreken van een back-up als je er eentje maakt.
Nogmaals: als ik jou gedachtengang volg, dan is een backup geen backup meer als ik de backup opsla op een storage systeem dat gebruik maakt van distributie en/of replicatie... Dat slaat toch nergens op?

Als ik dus een backup maak en die over vijf tapes moet verdelen omdat ie te groot is voor een enkele tape, ik distribueer de data dus over meerdere tapes, dan is het opeens geen backup meer?

Dat is toch een even kromme redenatie?
De
opslagmethode, eg: distributed + replicated, zegt niets over het
datatype; in dit geval een statische back-up.
Wat boeit de hoeveelheid data nou? Replicatie is replicatie, distributie is distributie, en een backup is een backup - ongeacht de hoeveelheid data.
Het woord backup is niks meer dan het veilig stellen van de data mocht er een failure ontstaan. Dat jij het nu hebt over het terug halen van een bestand en versiebeheer ging het bij mij inderdaad oorspronkelijk niet over.
Afhankelijk van de context klopt dat ja... En misschien toch ook niet helemaal, dat ligt ook weer aan de context en hoe je dit bedoeld...
Ik wil absoluut niet vervelend doen, maar als je bedoelt in de zin van "als een harde schijf kapot gaat, dan heeft een ander schijf nog exact dezelfde data omdat ze naar elkaar repliceerden": eigenlijk spreek je dan van redundantie in plaats van een back-up (in de zin van (semi-)statische gegevens).

Als we puur naar datamanagement kijken dan he, niet naar spreektaal of andere betekenissen; want daar ging het niet over.
Pas in het geval dat je na dataloss, corruptie of onbedoelde/foute wijzigingen aan de data de boel kan herstellen naar een ander punt in de tijd, spreek je van het terugzetten van een back-up. (Vandaar dat het ook een back-up heet... Een stap terug doen naar een andere situatie

)
Als een hardware onderdeel kapot gaat en dat maakt niets uit omdat een tweede hardware onderdeel de taken stug door blijft zetten - dan ben je redundant. (Of als een tweede cluster de boel direct overneemt, zoals bij Disaster Recovery.)
... Maar nog niet perse geback-upt. Dan komt inderdaad het kunnen terughalen van bestanden en/of versiebeheer om de hoek kijken, en *dat* is wat een back-up daadwerkelijk is als we het over datamanagement hebben.

Veel moderne DR software kan trouwens versiebeheer toepassen op replicatie, oa via snapshots. Dat zijn wel vormen van back-ups.
Een RAID1, om weer even naar die voorbeelden terug te gaan, biedt je niet perse een back-up: het is redundant opgeslagen (dankzij replicatie) waardoor een failure niet meteen dataloss als resultaat heeft...
Soms zegt men dan "I'm glad the back-up drive is still working!", maar eigenlijk was het geen back-up drive omdat hij altijd al onderdeel was van je array met de bedoelde functies om redundantie te verkrijgen via replicatie... Dat het dan toch geen back-up is, is vanwege de nature van replicatie in die opzet. Een verwijderd bestand dat replicated is, is immers overal weg - en dus niet back-upped.
Je hebt hier dan een beetje het probleem dat een back-up multi-interpretabel is met een dubbele betekenis in de spreektaal - maar als we er goed naar kijken in de context van datamanagement en kritisch kijken naar de terminologie en de betekenis: dan zijn er subtiele, maar hele duidelijke, verschillen... Wat ze in spreektaal zeggen zal me dan een rotzorg zijn eigenlijk.
Ik denk dat jij hier nu ook de spreektaal gebruikt/een andere context pakt voor het woordje "back-up", dan de term die je eigenlijk zou moeten gebruiken als we er technisch naar kijken.
Iets waar ik me, niets persoonlijks trouwens

, flink aan kan ergeren. Wil iemand nou frequente backups (met retentie, hopelijk), of willen ze realtime replicatie? Nogal een verschil! (Het liefst doen ze beiden

)
Ik bedoel, ik heb niet ontkend en zal ook niet ontkennen dat replicatie als een vorm van back-uppen te zien is (redundant maken) als je dat woord in een andere context gebruikt - puur vanwege het feit dat je mogelijk toegang zal hebben tot de gerepliceerde gegevens als de bron offline gaat om wat voor reden dan ook.

Je "backup location", zullen we dan maar zeggen - want dan wordt backup gebruikt in de zin van redundantie ipv de optie om terug te gaan naar een eerder tijdstip, in spreektaal. Al vind ik dan "the redundant location" accurater, maar dat zal allemaal wel.

Maar daar hadden we het niet over! Dus niet relevant.
Over het algemeen is replicatie real-time of near-real-time zolang zowel bron als mirror online zijn, terwijl over het algemeen een back-up een statisch gegeven is die aldanniet periodiek bijgewerkt wordt: maar over het algemeen niet real-time. Eens per dag, week of maand is het meest gangbare - en dan het liefst met een zekere retentie ipv slechts één backup te maken en die steeds te overschrijven. Of vaker, maar dan moet je inderdaad een goed versiebeheer hebben met een behoorlijke retentie voor file changes; anders doe je wederom niets anders dan repliceren... Koppijn materiaal.
TimeMachine van Apple bijvoorbeeld is daar een leuk voorbeeld van.
Misschien dat ik aan het mierenneuken ben hoor, maar ik vind het wel belangrijk om de verschillen duidelijk neer te pennen en te onthouden.
[Reactie gewijzigd door WhatsappHack op 22 juli 2024 15:33]