Omdat, zelfs als u vasthoudt aan LTS-releases (Long Term Support), Linux-distributies vaak fundamenteel meer risico lopen dan Windows-machines om - plotseling en spectaculair - failliet te gaan.
Waarom is dit in zoveel gevallen zo??
- Hardwarecompatibiliteit, ook voor essentiële componenten zoals GPU's, blijft een grote uitdaging, aangezien veel leveranciers nog steeds geen Linux-distributies ondersteunen, waardoor het aan de gemeenschap wordt overgelaten om tijdelijke oplossingen te bedenken;
- Het financiële model van open source stimuleert, laat staan vereist, grondige QA-processen;
- En voor degenen die de nieuwste releases bijhouden, hebben fundamentele veranderingen in pakketbeheertools de nare gewoonte om het systeem soms te blokkeren door een onherstelbare Pandora's Box met afhankelijkheidsfouten te openen. Om deze te repareren, zelfs als dat mogelijk is, kan het inhouden van dagenlange konijnenholen. Wat een goede leerervaring lijkt voor een nieuwe gebruiker, kan een dealbrekende frustratie worden voor een ervaren gebruiker die op het punt staat om naar Windows te springen.
En het stabiliteitsprobleem van Linux heeft veel gebruikers woedend gemaakt. Blader door veel gebruikers-in-nood-threads op AskUbuntu.com en je zult veel gefrustreerde posters tegenkomen die alles hebben geprobeerd en uiteindelijk hebben besloten dat de enige manier om vooruit te komen is om helemaal opnieuw te installeren.
Hoewel dit in eerste instantie een soort leerproces kan zijn, waarbij gebruikers worden aangemoedigd om periodiek te heroverwegen hoe ze hun systeem slanker kunnen maken en het herstelproces kunnen stroomlijnen, wordt het na een tijdje niets beter dan een grote, tijdrovende overlast. Vroeg of laat zullen zelfs de meest geavanceerde power users naar stabiliteit hunkeren.
Ik gebruik Linux al meer dan 10 jaar als mijn dagelijkse besturingssysteem en heb een groot aantal ongewenste schone installaties doorgemaakt. Zoveel zelfs dat ik beloofde dat mijn laatste herinstallatie mijn laatste zou zijn. Sindsdien heb ik de volgende methodiek ontwikkeld:. En het heeft gewerkt om mijn Lubuntu-systeem zo goed te laten werken als de dag dat ik het installeerde zonder een herinstallatie sinds. Dit is wat ik doe.
Overwegingen: wat heb je nodig om een back-up te maken??
Voordat u een back-upstrategie kiest, moet u enkele basisprincipes achterhalen:
- Wat heb je nodig om een back-up te maken?? Moet u een back-up maken van de volledige partitie/het volume of alleen de thuisgebruikersmap??
- Is een incrementele back-upstrategie voldoende voor uw gebruik?? Of moet u volledige back-ups maken??
- Moet de back-up worden versleuteld??
- Hoe gemakkelijk moet het herstelproces zijn??
Mijn back-upsysteem is gebaseerd op een mix van methodieken.
Ik gebruik Timeshift als mijn primaire back-upsysteem, dat incrementele snapshots maakt. En ik bewaar een volledige schijfback-up op de site die mappen uitsluit die geen gebruikersgegevens bevatten. Ten opzichte van de systeemroot zijn dit:
- /dev
- /proc
- /sys
- /tmp
- /rennen
- / mnt
- /media
- /verloren+gevonden
Ten slotte bewaar ik nog twee back-ups. Een daarvan is een (echte) volledige systeempartitie naar imageback-up met behulp van a Clonezilla live-USB. Clonezilla verpakt een reeks low-level tools voor het repliceren van installaties. En de tweede is een offsite volledige systeemback-up die ik ongeveer een keer per jaar upload naar AWS S3 wanneer ik een geweldige data-uplink tot mijn beschikking heb.
Opties voor back-uptools
Tegenwoordig is de selectie van tools die je kunt gebruiken groot.
Het bevat:
- Bekende CLI's zoals rsync die handmatig als cron-taak kunnen worden gescript en aangeroepen
- Programma's zoals Déjà Dup, Duplicity, Bacula die GUI's bieden voor het maken en automatiseren van back-upplannen naar lokale of off-site bestemmingsservers, inclusief servers die worden beheerd door gewone cloudproviders
- En tools die samenwerken met betaalde cloudservices zoals CrashPlan, SpiderOak One en CloudBerry. De laatste categorie omvat services die zelf goedkope cloudopslagruimte bieden, dus het aanbod is volledig end-to-end.
De 3-2-1-regel
Ik ga een snel overzicht geven van de tools die ik momenteel gebruik op mijn hoofdmachine.
Hoewel ik een aantal Bash-scripts heb geschreven om essentiële configuratiebestanden in mijn belangrijkste cloudopslag te krijgen, die ik gebruik voor dagelijkse bestanden, maakt dit (de essentiële) onderdeel van mijn back-upplan gewoon een back-up van de hele machine, inclusief virtuele machines en systeem bestanden die moeten worden weggelaten of apart moeten worden geback-upt in meer genuanceerde benaderingen.
Het centrale uitgangspunt is de naleving van de 3-2-1 back-upregel. Deze aanpak zou uw gegevens - inclusief uw belangrijkste besturingssysteem - in bijna elk storingsscenario moeten beschermen.
In de Regel staat dat u zich moet houden aan:
- 3 kopieën van uw gegevens. Ik zeg altijd dat dit een beetje een verkeerde benaming is, omdat het eigenlijk betekent dat je je primaire gegevensbron en twee back-ups moet bewaren. Ik zou dit eenvoudigweg "twee back-ups" noemen
- Deze twee reservekopieën moeten op verschillende opslagmedia worden bewaard. Laten we dit terugbrengen naar eenvoudige termen voor thuiscomputeren. Je zou een eenvoudig rsync-script kunnen schrijven dat (incrementeel) je hoofd-SSD kopieert naar een ander aangesloten opslagmedium - laten we zeggen een HDD die is aangesloten op de volgende SATA-poort op je moederbord. Maar wat gebeurt er als uw computer in brand vliegt of uw huis wordt overvallen?? U zou zonder uw primaire gegevensbron zitten en geen back-up hebben. In plaats daarvan kunt u een back-up van uw primaire schijf maken naar een Network Attached Storage (NAS) of eenvoudig Clonezilla gebruiken om deze naar een externe harde schijf te schrijven.
- Een van de twee back-ups moet offsite worden opgeslagen. Offsite back-ups zijn van vitaal belang omdat, in het geval van een catastrofale natuurlijke gebeurtenis zoals bijvoorbeeld overstromingen, uw hele huis kan worden vernietigd. Minder dramatisch, een grote overschrijding kan alle aangesloten elektronica in een huis of al die op een bepaald circuit doen frituren (daarom is het logisch om een van de onsite back-ups los te laten van een voeding - een voorbeeld zou een eenvoudige externe HDD/SDD ).Technisch gezien is "offsite" overal op een afgelegen locatie. U kunt Clonezilla dus gebruiken om op afstand via internet een afbeelding van uw besturingssysteem naar uw werk-pc of een daaraan gekoppelde schijf te schrijven. Tegenwoordig is cloudopslag goedkoop genoeg om zelfs volledige schijfimages betaalbaar te installeren. Om die reden maak ik een keer per jaar een volledige back-up van mijn systeem naar een Amazon S3-bucket. Het gebruik van AWS geeft je ook enorme extra redundantie.
Mijn back-upimplementatie
Mijn benadering van back-ups is gebaseerd op een paar eenvoudige beleidsregels:
- Ik wil het zo eenvoudig mogelijk houden;
- Ik wil mezelf de meeste redundantie geven die ik redelijkerwijs kan bereiken;
- Ik wil minimaal de 3-2-1 regel volgen
Dus ik doe het als volgt:.
- Ik bewaar een extra schijf op mijn bureaublad die alleen voor huisvesting wordt gebruikt Tijdzift herstel punten. Omdat ik er een hele schijf aan wijd, heb ik behoorlijk wat ruimte om mee te spelen. Ik bewaar een dagelijkse, maandelijkse en wekelijkse back-up. Tot nu toe is Timeshift alles wat ik nodig heb om het systeem een paar dagen terug te draaien tot een punt voordat iets, zoals een nieuw pakket, een nadelig effect had op andere delen van het systeem. Zelfs als je GRUB niet kunt passeren, kan Timeshift worden gebruikt als een CLI met rootrechten om het systeem te repareren. Het is een verbazingwekkend veelzijdig en handig hulpmiddel. Dit is een eerste exemplaar ter plaatse.
- Ik bewaar een extra schijf op mijn bureaublad die uitsluitend wordt gebruikt voor het onderbrengen van Clonezilla-afbeeldingen van mijn hoofdschijf. Omdat deze beelden mij pas echt van pas komen in het geval dat Timeshift mislukt, maak ik deze maar eens in de drie tot zes maanden. Dit is een tweede exemplaar op locatie.
- Met Clonezilla maak ik een extra harde schijf die ik thuis buiten de pc bewaar. Behalve dat ik voor deze harde schijf een apparaat-apparaatback-up gebruik in plaats van een apparaat-image-back-up zoals in de vorige afbeelding - zodat het goed zou zijn om onmiddellijk te gaan als mijn primaire schijf dichtgemetseld zou zijn. Als ik bijvoorbeeld zou herstellen van de interne Clonezilla-back-upschijf, zou ik eerst een herstelproces moeten volgen. Ervan uitgaande dat de andere systeemcomponenten in goede staat verkeren na een storing in de harde schijf, zou ik in theorie alleen deze schijf op het moederbord hoeven aan te sluiten om hem te gaan gebruiken. Dit is een derde exemplaar op locatie.
- Ten slotte upload ik ongeveer eens in de zes maanden een door Clonezilla gegenereerde afbeelding van mijn systeem naar AWS S3. Onnodig te zeggen dat dit een lange meerdelige upload is en moet worden uitgevoerd vanaf een internetverbinding met een goede uploadlink.
In totaal omvat mijn systeem drie on-site kopieën en één off-site kopie van mijn hoofddesktop.
Belangrijkste afhaalrestaurants
- Alle Linux-gebruikers moeten over robuuste back-upstrategieën beschikken
- De 3-2-1 back-upregel is een goede maatstaf om ervoor te zorgen dat uw gegevens onder vrijwel alle omstandigheden veilig zijn.
- Ik gebruik een combinatie van Timeshift en Cloudzilla om mijn back-ups te maken, hoewel er tal van andere opties, waaronder betaalde, op de markt zijn. Voor cloudopslag gebruik ik een eenvoudige AWS S3-bucket, hoewel er nogmaals geïntegreerde services zijn die zowel software als opslagtools bevatten.