Backup-strategie, do's and dont's

[Good_Lord]

Hi,

Aangezien ik zakelijk steeds afhankelijker wordt van mijn IT, ben ik serieus mijn beveiliging aan het herzien om te kijken waar het beter kan.

Uiteraard moeten de systemen zelf beveiligt zijn, nagedacht worden over encryptie, maar er moet natuurlijk ook een goede backup-strategie zijn voor als het onverhoopt toch mis gaat. Ik kom veel informatie tegen over de verschillende manieren van backuppen, en vooral de software daarvoor, maar ik mis vooral informatie over het hoe en waarom achter een backup-plan. Wazige adviezen als "gebruik versioning" is leuk, maar hoe richt je dat in?

In dit topic wil ik graag bespreken / van jullie horen wat de verschillende adviezen zijn, en waarom. Ik gebruik hiervoor mijn eigen situatie als startpunt, als dit een vraag-topic zou moeten zijn hoor ik dat graag. In eerste instantie gaat het mij vooral om de bestanden. De Windows-installatie moet uiteraard ook gebackupped worden, maar dat is - voor mij - van mindere prioriteit.

---

Situatieschets:
Alle systemen:
- draaien Windows 7 of Windows 10
- Administrator account + los User account
- ESET NOD32 AV
- Adobe software (dus Windows is verplicht voor de werkstations)
Alle software is officieel gelicenceerd en met originele installatiemedia geïnstalleerd.

Plan
Wat ik in wil richten is een echt backup plan met versioning en encryptie, om fysieke problemen (diefstal / brand) en software problemen (virussen / malware / ransomware) het hoofd te kunnen bieden.

Huidige activiteit
Op dit moment synchroniseer ik de dagelijkse werkbestanden tussen Desktop en ext. HDD FreeFileSync (deze externe HDD is voor aan mijn laptop als ik op locatie werk ivm de schijfruimte op mijn laptop).

Voor de backups gebruik ik Cobian Backup 11, die de backups in een encrypted zip-bestand opslaat. Hierdoor maakt het niet meer uit waar ik de backup opsla (bijv. in de cloud), het is encrypted. Ook kan Cobian verschil maken tussen Full en Incrementele backups, met gebruik van versioning

Beschikbare hardware
Naast mijn Desktop en 2TB Externe HDD voor het dagelijkse gebruik heb ik de beschikking over:
- NAS (3TB zelfbouw met NAS4Free)
- Externe HDD (2TB)
- Online cloud-opslag (1TB) (Webdav en website only, geen ftp)
- Raspberry Pi 3
Eventele overige hardware kan in geïnvesteerd worden, maar liever niet uiteraard.

Mogelijke plannen
Op mijn Desktop kan ik uiteraard de dataschijf met het netwerk delen.

Ik kan de backup vanaf de desktop pushen naar de NAS. Cobian kan een FTP account gebruiken om de backup naar te uploaden. Op deze manier zijn de bestanden netjes in een encrypted zip-bestand verpakt en hoef ik niet verder na te denken over encryptie van de NAS. De NAS kan dan de backups doorzetten naar de cloud, waarbij ik ook daar niet meer na hoef te denken over encryptie. Hierbij wordt de backup vanaf de desktop geïnitieerd.

Ik kan de backup ook pullen vanaf de NAS. Hiervoor zou ik (denk ik?) op mijn Desktop de dataschijf moeten delen met het netwerk, verder weet ik niet goed hoe ik dit in zou moeten richten. Ik weet wel dat hierbij de backup vanaf de NAS wordt geïnitieerd.

Eigenlijk heb ik 3 vragen:
- Hoe zouden jullie de backups opzetten mbh een NAS, cloud en ext, HDD?
- Is de beschreven push-methode veilig genoeg om ook ransomware buiten te houden?
- Hoe kan ik het beste de backup bestanden beveiligen tegen ongeautoriseerde ogen, zowel op de NAS als in de cloud, als ik de backups vanaf de NAS pull?

Ter info: De backups kan ik het makkelijkst wekelijks en maandelijks, per kwartaal en/of jaarlijks inrichten.

[ Voor 29% gewijzigd door Good_Lord op 01-06-2016 12:59 . Reden: voorbarige publicatie ]

[Zeehond]

Eerste wat in mij opkomt is:
één back-up = geen back-up.

Ik zou ook denken aan zaken als bijv. brand. Mischien een back-up op een andere locatie leggen?

zelf heb ik het liefst al mijn back-ups offline en gebruik ik dus geen NAS maar alleen externe hardeschijven.

[GemengdeDrop]

Ik heb een ProLiant MicroServer Gen8 ingericht als een NAS met wat extra pit

Daarop FreeBSD stable.
ZFS filesystem, met grote redundate harddisks
Een kleine goedkope SSD voor de OS installatie.

Voor bestandstoegang draai ik vooral een samba server. Dus ik heb bulk opslag op de NAS via de normale windows bestandssharing, waarbij elke gebruiker apart aanmeld en z'n eigen ruimte heeft.
Daarnaast draai ik ook een rsync server en ik gebruik CWRsync om een backup te maken van de gebruikersdata op mijn laptop.
Via OpenVPN heb ik toegang tot al die data, ook van buitenaf. OpenVPN mét certificaten en ook een TA-key is de enige toegang vanaf buiten.

Ik heb een scriptje gebakken dat elke week een snapshot doet van al die data - en die ze ook na een bepaalde tijd (vele maanden) weer weg gooit. Je maakt dan gebruik van de ZFS copy-on-write, dus heel veel extra ruimte neemt zo'n snapshot IHA niet in. ZFS laat je ook de toestand van elk filesystem zien zoals het gesnapshot was op enig moment - en dat read-only. Dus als ik een cryptolocker pak, dan vermoord die in theorie ook alle files op mijn samba shares, maar die worden wel elke week gesnapshot. Mijn windows pc's hebben op het interne netwerk geen andere manier van toegang dan samba, rsync en SSH. Zoals ik het zie kan een cryptolocker niet veel, tenzij die zo goed is dat 'ie ook een lopende SSH sessie weet te kapen - en dan moet je nog ROOT hebben ook, wat bij mij standaard niet zo is.

Het allergrootste gevaar is dat ik bij onheil iets doms doe. Zoals bijvoorbeeld per ongeluk al je snapshots weggooien . Of tijdens een root-sessie per ongeluk je zpool de nek om draaien En dat brengt mij bij het grote nadeel van mijn eigen oplossing: Je moet het allemaal zelf een beetje in elkaar bakken/scripten - en het is niet bepaald fool-proof. Maar mocht je daar zelf affiniteit mee hebben, dan kan je er erg leuke dingen mee doen.

ZFS laat je bijvoorbeeld ook een één op één snapshot van een heel filesystem als een stream wegschrijven, eventueel gecomprimeerd. De allerbelangrijkste data (die dan wel in een apart filesystem moet staan) kan je dan op gezette tijden ergens op een webdav account zetten. Maar dat heb ik nog niet geimplementeerd, dus bij bliksem ben ik de sigaar

Maar: disclaimer: Dit is hoe ik het doe. Dus puur ter kennisgeving over één van de vele opties. Vanwege het handmatige karakter ervan is het kwetsbaar en ik ben dus wat huiverig om mensen te gaan zeggen hoe het moet. Want een echt goede backup maken is namelijk helemaal niet simpel. Het allerbelangrijkste is dat er scheiding is tussen wie waar op welk moment bij kan, zodat je niet al te makkelijk je eigen backups om zeep helpt. Maar succes!

[Good_Lord]

Tweakers!

Bedankt voor de reacties! Ik had helemaal niet meer in de gaten dat er gereageerd was op mijn topic. Ik dacht dat ik daar een notificatie van zou zien maar die heb ik zeker gemist.

Zeehond schreef op zondag 05 juni 2016 @ 18:55:
Eerste wat in mij opkomt is:
één back-up = geen back-up.

Ik zou ook denken aan zaken als bijv. brand. Mischien een back-up op een andere locatie leggen?

zelf heb ik het liefst al mijn back-ups offline en gebruik ik dus geen NAS maar alleen externe hardeschijven.

Dat is idd een van de dingen waar ik aan denk. Ik leg periodiek een externe hdd op de locatie van mijn klant (ik heb daar een opslagruimte met eigen sleutel), maar dat vind ik te onbetrouwbaar / handmatig, vandaar de cloud-optie.

GemengdeDrop schreef op zondag 05 juni 2016 @ 19:34:
Ik heb een ProLiant MicroServer Gen8 ingericht als een NAS met wat extra pit

[...]

Via OpenVPN heb ik toegang tot al die data, ook van buitenaf. OpenVPN mét certificaten en ook een TA-key is de enige toegang vanaf buiten.

Voor toegang van buiten houd ik het voorlopig op SSH (zie dit topic). Op termijn is een echte VPN een optie, maar omdat ik dat op dit moment nog niet gebruik is SSH toegang voor nu voldoende voor mij.

GemengdeDrop schreef op zondag 05 juni 2016 @ 19:34:
[..]

Maar: disclaimer: Dit is hoe ik het doe. Dus puur ter kennisgeving over één van de vele opties. Vanwege het handmatige karakter ervan is het kwetsbaar en ik ben dus wat huiverig om mensen te gaan zeggen hoe het moet. Want een echt goede backup maken is namelijk helemaal niet simpel. Het allerbelangrijkste is dat er scheiding is tussen wie waar op welk moment bij kan, zodat je niet al te makkelijk je eigen backups om zeep helpt. Maar succes!

Ik merk dat ik niet te veel meer wil rommelen. Ik heb het al druk genoeg, en als ik wil spelen met hardware dan liever niet met iets belangrijks als Backups. Ook is jouw gebruikte hardware erg zwaar. Ik hoef geen andere diensten dan file-server op m'n NAS (Samba/FTP, SSH)

---

Update sinds de topicstart:

Ik zit nu een tijdje te werken met een cloud-oplossing (tijdelijk) maar dit is wel erg traag bij het draaien van een dagelijkse / wekelijkse backup. Daarnaast gebruik ik een externe hdd om mijn bestanden te synchroniseren met m'n laptop voor gebruik onderweg.

De encryptie-eis kan ik laten vallen. Als ik backup vanaf m'n desktop kan ik Cobian Backup 11 gebruiken, die voor de encryptie kan zorgen middels password protected zip-bestanden.

Mijn plan na de afgelopen maand:

Dagelijks
De dagelijkse backup wil ik intern houden. De upload is te traag om dit naar de cloud te zetten. Ik zat te denken aan Desktop -> RaspberryPi. Dit kan via Samba of FTP. Ik denk dat ik eerst Samba zal gaan gebruiken. De RasPi zal later vervangen worden door een wat krachtiger samba/ftp-servertje met o.a. Gigabit-RJ45. Dit is een tijdelijke (trage) oplossing, makkelijk voor het opzetten van het hele gebeuren, zodat ik later kan kijken waar ik het beste in kan investeren.

Daarnaast sync ik een Externe HDD, welke ik ook sync met m'n laptop. (laptop en ext. HDD gaan mee op pad) Dit is voor mij geen backup, hooguit handig.

Wekelijks
Wekelijks wil ik de backups van de Raspi verplaatsen naar de NAS, welke alle backups zal bewaren. Dit kan eventueel door een script wat met rsync pulled vanaf de NAS. Hierdoor zou ik alleen de NAS aan hoeven te zetten om de backup te laten draaien. Deze NAS zal dan via Samba / FTP bereikbaar gemaakt kunnen worden met een ander inlog / password wat alleen gebruikt wordt op dit account (dus niet op de desktops). Hierdoor zal Crypto-malware geen vat kunnen krijgen op de NAS (denk ik).

De RasPI wil ik always-on houden. Hierdoor zou alles op kunnen schuiven (wekelijks wordt dagelijks, maandelijks wordt wekelijks) maar dat is even kijken wat de praktijk uitwijst.

Externe backup

De beschikbare ruimte:
Sync HDD: 1 TB
Raspi: 1 TB
NAS: 3 TB
Cloud: 2 accounts met 1 TB elk.

Aangezien de cloud alleen per webdav en browser te bereiken zijn kan ik deze niet mounten op m'n NAS (NAS4Free is FreeBSD based). Ik zal dit dus vanaf de Pi moeten regelen. (De Pi draait Raspbian, Debian 8 based)

Vraag: Hoe zouden jullie de backup naar de cloud regelen?

[ebia]

Audio-Lover schreef op vrijdag 08 juli 2016 @ 15:09:
Vraag: Hoe zouden jullie de backup naar de cloud regelen?

Dat blijft een lastig issue. Maar een paar tips:
- Beperkt de omvang van de backup: je dagelijkse/belangrijkste data files wil je natuurlijk wel dagelijks up to date hebben in de backup, maar een backup van je Windows installatie (als je dat uberhaupt al wilt) maak je over het algemeen veel minder. Sterker, er zijn mensen die ervoor kiezen zoiets slechts éénmalig te doen (bijvoorbeeld net na een verse installatie een image maken), en dan daarop terugvallen mocht er onverhoopt iets fout gaan. (Er komt wel weer een nadeel om de hoek kijken: want je moet immers nu twee of meerdere back-up systemen gaan aanhouden voor verschillende toepassingen).
- Zorg voor maximale uploadbandbreedte. Een beetje een inkoppertje, en soms kan het nu eenmaal niet harder dan je op je adres beschikbaar hebt, maar soms zijn er nog alternatieven. Bijvoorbeeld als je de data al reeds in een datacentrum hebt staan met goede uplinks naar de rest van de wereld. Dan is een snelle cloud backup een relatief eenvoudig iets.
- In sommige gevallen (bijvoorbeeld als je het zelf regelt) zou je een eerste grote bulk aan data via een andere manier (lees: harde schijf) kunnen brengen naar de locatie waar de back-ups plaatsvinden. Daarna blijft het een kwestie van de back-up bijwerken.
- Ondanks veel goede intenties van veel partijen die in dit gat zijn gesprongen hoor je soms enorme drama's van back-up clouddiensten als het aankomt op recovery. Bijvoorbeeld bijzonder trage recovery, of gewoon bestanden die er plots toch niet meer zijn. Als je hiermee geen risico's wilt (of beter: kunt) lopen, regel het dan zelf. Wordt niet afhankelijk van een derde partij. Testen, testen, testen...

Zelf maak ik back-ups met Robocopy en rsync scripts. Dat mag je misschien officieel dan wel geen back-up noemen, in mijn situatie waar ik de enige gebruiker ben van mijn eigen data werkt het prima. Ik weet immers zelf of ik de oude kopie kan syncen met de huidige data of niet.

[GemengdeDrop]

Audio-Lover schreef op vrijdag 08 juli 2016 @ 15:09:
Aangezien de cloud alleen per webdav en browser te bereiken zijn kan ik deze niet mounten op m'n NAS (NAS4Free is FreeBSD based). Ik zal dit dus vanaf de Pi moeten regelen. (De Pi draait Raspbian, Debian 8 based)

Vraag: Hoe zouden jullie de backup naar de cloud regelen?

Als die nas FreeBSD gebaseerd is , kan 'ie dan misschien zoiets als dit draaien?
http://www.freshports.org/sysutils/fusefs-wdfs
Hier loopt een soortgelijke vraag.

Ik heb het zelf niet geprobeerd, maar je zou kunnen denken dat je dan een simpel scriptje maakt dat iets met rsync doet. Er zijn vast soortgelijke oplossingen voor linux/debian. Een ander idee is om gewoon domweg een hele directory boom door tar en gz heen te halen en de output direct weg te schrijven richting webdav.

Maar wat betreft dat idee, het grootste probleem is denk ik dat je tegen je upload aanloopt, als je gewoon een consumentenlijntje hebt. Dat gaat gewoon dagen duren, dus je *moet* een soort differentiele backup a-la-rsync gaan verzinnen, anders gaat het gewoon niet werken. En als je hele grote bestanden er tussen hebt zitten dan is het misschien zelfs niet voldoende om op file-datum niveau differentieel te werken, dus dan moet je ook een cloud provider hebben die je rsync aanbied. In dit topic werd dit al eens besproken, maar er is verder niet veel uitgekomen.

Ik heb zelf een paar zeer grote VM's die ik met rsync differentieel aan het backuppen ben.

Twee opmerkingen nog:
1. Vergis je niet in hoeveel tijd het overpompen van ~1 TB kost, zelfs op gigabit (en je mag blij zijn als je drive controllers of je hdd's dat trekken)
2. Als je echt bang bent voor cryptolockers, dan moet je ook uitkijken met samba. De typische backup-backlog moet dus langer zijn dan de gemiddelde sluimertijd van die ransomware.


Sommige mensen zouden zeggen dat dit alles wat overdreven is, maar, om even voor mijzelf te spreken: ik heb 5 jaar van m'n leven in die data zitten - en de economische schade van verlies is een bedrag met héél veel nullen. Dus ach ja, 0.5k€ uitgeven aan wat backup en storage is lang niet gek.

Oh. En : please.... wees voorzichtig met tools als rsync/robocopy. Die tools zijn in staat om al je data te vernachelen in ongeveer dezelfde hoeveelheid tijd als het kost om dat foute commando in te tikken .

[ebia]

GemengdeDrop schreef op zaterdag 09 juli 2016 @ 19:32:

Oh. En : please.... wees voorzichtig met tools als rsync/robocopy. Die tools zijn in staat om al je data te vernachelen in ongeveer dezelfde hoeveelheid tijd als het kost om dat foute commando in te tikken .

Als je dergelijke tools in een 'backup systeem' gaat gebruiken, dan ga ik er vanuit dat je het gaat automatiseren. Met andere woorden je bakt alles in één of meerdere scripts zodat je er zeker van bent dat je geen typo's maakt bij het invoeren van individuele commando's. Als je dat maar doet, en natuurlijk vooraf uitgebreid test met testdata, dan kan er in de praktijk bijzonder weinig fout gaan.

[The Eagle]

Wij gebruiken op onze zakelijke laptops MozyPro voor de backups. Gaat rechtstreeks per werkstation de cloud in en zij doen de rest. Werkt prima

[Good_Lord]

ebia schreef op vrijdag 08 juli 2016 @ 23:01:
[...]
Dat blijft een lastig issue. Maar een paar tips:
[...]
Zelf maak ik back-ups met Robocopy en rsync scripts. Dat mag je misschien officieel dan wel geen back-up noemen, in mijn situatie waar ik de enige gebruiker ben van mijn eigen data werkt het prima. Ik weet immers zelf of ik de oude kopie kan syncen met de huidige data of niet.

Mijn situatie lijkt erg op die van jou. Ik werk alleen, vanuit huis met een desktop, en op locatie met een laptop. Voorlopig staat mijn data lokaal, het enigste wat ik in een datacentrum heb is mijn website-hosting en de "domme" cloud-schijf.

Mijn backups moet ik zelf regelen, ik zit dus vooral met de opslag van deze backups. De backups draai ik met Cobian Backup 11 (password-beveiligde zip-bestanden), welke ook incrementeel aangemaakt kunnen worden. Vanaf Linux kan ik idd met een rsync werken.

Omvang blijft beperkt: alleen bestanden, geen windows/programma-backups. 1 keer een full backup, dan incrementele backups. 1x per kwartaal een full-backup ten tijde van de BTW-aangifte, daarna incrementele backups tot de eerstvolgende full backup. Incrementele backups ouder dan het laatste seizoen kunnen verwijderd worden (waardoor ik max. 6 maanden aan incrementele backups heb).

Recovery-procedure is simpel: zip-bestand opzoeken -> wachtwoord inkloppen -> unzippen.

GemengdeDrop schreef op zaterdag 09 juli 2016 @ 19:32:
Als die nas FreeBSD gebaseerd is , kan 'ie dan misschien zoiets als dit draaien?
http://www.freshports.org/sysutils/fusefs-wdfs
Hier loopt een soortgelijke vraag.

Ik heb het zelf niet geprobeerd, maar je zou kunnen denken dat je dan een simpel scriptje maakt dat iets met rsync doet. Er zijn vast soortgelijke oplossingen voor linux/debian. Een ander idee is om gewoon domweg een hele directory boom door tar en gz heen te halen en de output direct weg te schrijven richting webdav.

Maar wat betreft dat idee, het grootste probleem is denk ik dat je tegen je upload aanloopt, als je gewoon een consumentenlijntje hebt. Dat gaat gewoon dagen duren, dus je *moet* een soort differentiele backup a-la-rsync gaan verzinnen, anders gaat het gewoon niet werken. En als je hele grote bestanden er tussen hebt zitten dan is het misschien zelfs niet voldoende om op file-datum niveau differentieel te werken, dus dan moet je ook een cloud provider hebben die je rsync aanbied. In dit topic werd dit al eens besproken, maar er is verder niet veel uitgekomen.

Ik heb zelf een paar zeer grote VM's die ik met rsync differentieel aan het backuppen ben.

Twee opmerkingen nog:
1. Vergis je niet in hoeveel tijd het overpompen van ~1 TB kost, zelfs op gigabit (en je mag blij zijn als je drive controllers of je hdd's dat trekken)
2. Als je echt bang bent voor cryptolockers, dan moet je ook uitkijken met samba. De typische backup-backlog moet dus langer zijn dan de gemiddelde sluimertijd van die ransomware.


Sommige mensen zouden zeggen dat dit alles wat overdreven is, maar, om even voor mijzelf te spreken: ik heb 5 jaar van m'n leven in die data zitten - en de economische schade van verlies is een bedrag met héél veel nullen. Dus ach ja, 0.5k€ uitgeven aan wat backup en storage is lang niet gek.

Oh. En : please.... wees voorzichtig met tools als rsync/robocopy. Die tools zijn in staat om al je data te vernachelen in ongeveer dezelfde hoeveelheid tijd als het kost om dat foute commando in te tikken .

Dank voor de waarschuwing op het eind Ik test inderdaad alles voordat ik het implementeer. En ik wil het idd automatiseren mbv scripts om typevouten te voorkomen.

N.a.v. opmerking 1:
De drive is 1 TB groot. De data zelf is dat bij lange na nog niet. De full-backups kan ik onder de 100 GB houden (bijv. 2 losse backups, ipv 1 grote)

N.a.v. opmerking 2:
mbt Cryptolocker voulnerability:

• Desktop --push--> NAS 1 --push--> cloud-drive
• NAS 2 <--pull-- NAS 1

Voordelen van deze opzet

• NAS 2 is niet te benaderen van buitenaf. NAS 1 bevat geen inloggegevens van NAS 2. NAS 2 is dus veilig van ransomware (als ik het goed begrepen heb)
• NAS 1 & 2 liggen allebij in het lokale LAN = maximale snelheid
• De backups staan zowel op NAS 2 als in de cloud. In geval van inbraak of brand zijn mijn bestanden dus veilig

Volgens mij heb ik zo alle scenario's gecovered.

fusefs-wdfs: is een optie. Ik zat later te denken dat NAS4Free eruit gooien ook een optie is. NAS4Free is FreeBSD met een webbased-GUI, die ik eigenlijk niet eens nodig heb. Als ik gewoon een linux-distro gebruik kan ik gebruik maken van de native tools (webdav mounten, Samba, Rsync, FTP). Zoals het er naar uitziet is webdav op *BSD niet een standaard-oplossing, en ik weet liever wat ik doe.


Mijn vragen:

• Vraag 1: Heb ik mijn aanname juist, m.b.t. ransomware?
• Vraag 2:Als ik inderdaad NAS 2 ook op linux laat draaien, kan ik kiezen welke van de 2 naar de cloud upload. Welke van de 2 nassen zouden jullie dan laten uploaden naar de cloud?
  • NAS 1, dus alle dagelijkse backups
  • NAS 2, de wekelijkse backups

[ebia]

Audio-Lover schreef op zondag 10 juli 2016 @ 15:39:

Mijn vragen:

• Vraag 1: Heb ik mijn aanname juist, m.b.t. ransomware?
• Vraag 2:Als ik inderdaad NAS 2 ook op linux laat draaien, kan ik kiezen welke van de 2 naar de cloud upload. Welke van de 2 nassen zouden jullie dan laten uploaden naar de cloud?
  • NAS 1, dus alle dagelijkse backups
  • NAS 2, de wekelijkse backups

Ja, je aanname lijkt me juist. Ransomware kan alleen toegang krijgen tot data waarmee je met een normaal account ook toegang tot kan krijgen (in je normale Windows omgeving). Ransomware (niet eens alle) kan dus lokale bestanden benaderen, of bijvoorbeeld een gemounte disk. Als je NAS 2 dus niet mount vanaf het geïnfecteerde systeem, dan lijkt me dat verder veilig... Wat je overigens niet wilt hebben is dat als je NAS1 toch met door ramsonware versleutelde bestanden komt te zitten, hij deze naar de NAS2 schrijft. Althans dat is nog niet eens zo erg, maar in worst case dat ie een oude kopie wegkiepert daardoor.

Welke van de twee je wegschrijft naar de cloud is maar net wat je wil. Stel je moet echt terugvallen op die cloud back-up (stel diefstal of brand) dan ben je dus worst-case een week aan (nieuwe) data kwijt. Als je niet zoveel nieuwe data maakt, dan boeit dat niet.

BTW ik zou oppassen met comprimeren van je back-up data. Ja, het klinkt als handig om te doen, maar met de toenemende disk capaciteit is de kans dat er bitjes omvallen ook groter. Windows's NTFS doet hier weinig aan, vandaar de stijgende populariteit van bijvoorbeeld ZFS dat hier wel iets tegen kan doen (en veel meer). Anyway, als je dus gaat zippen en één bitje gaat stuk, dan heb je grote kans dat je die data nooit meer kan benaderen. (Probeer maar, zip wat files, gooi één bitje eruit of verander deze, en je kunt daarna die hele file niet meer uitpakken). Als dat bij één van je 'gewone' bestanden zijn de gevolgen vaak iets beter te overzien (worst case: alleen dat ene bestand is corrupt). Overigens is hier wel iets aan te doen, bijvoorbeeld door PAR2 bestanden (jawel, zoals op het usenet gebruikelijk is) toe te voegen aan je archief...

[ Voor 23% gewijzigd door ebia op 10-07-2016 16:37 . Reden: toevoeging mbt pariteit ]