Local backup i.p.v cloud backup

[DirkJan]

Ik maak gebruik van een Synology NAS en de bijbehorende Synology Drive client voor het maken van een backup. Voor het brandrisico wordt er van mijn NAS weer een backup gemaakt op de Synology NAS van mijn zwager. Zijn backup staat dan weer op mijn NAS. Synology heeft daar een tool voor die er voor zorgt dat we niet over en weer bij elkaars data kunnen.

[markba]

Nog wat spam over syncthing (ST)....

ST is in de eerste plaats een synchronisatie-tool, dus bi-directioneel. Zelf gebruik ik ST ook als een soort van DropBox, om bestanden met derden te delen. Voordeel van ST boven DropBox is, dat je geen centrale server nodig hebt waar je altijd maar een beperkte opslag hebt (afhankelijk van hoeveel je betaalt); met ST maakt het dus niet uit dat je meerdere gig's aan data te syncen hebt, de capaciteit is 'oneindig'. Qua syncen is ST de beste tool die ik ooit heb gebruikt, het is bijna instantaan , supersnel en foutloos, moet het eerste conflict nog meemaken....

ST is volledig platform-onafhankelijk, op de desktop (Linux, Windows, macOS) maar ook mobiel (Android, iOS), dus je kunt op al deze apparaten syncen, bv foto's van je foon naar je NAS. Op Linux kun je ST ook makkelijk op een headless server draaien (via docker is het eenvoudigst), de interface gaat via een browser.

Zoals gezegd is ST een sync-tool, maar met een iets andere configuratie is ST ook prima als backup te gebruiken. Zelf speel ik met het idee om een Raspberry Pi met ST erop bij een vriend achter de router neer te zetten, om daar dan de backup van mijn NAS naartoe te maken. Een backup is immers pas goed als je er meerdere hebt, en als er minimaal eentje buitenshuis wordt opgeslagen.

[vanadium]

Qua syncen is ST de beste tool die ik ooit heb gebruikt, het is bijna instant aan , supersnel en foutloos, moet het eerste conflict nog meemaken....

Ik gebruik syncthing vooral voor het synchroniseren van notabestanden tussen PC (laptop) en telefoon. En daar is het risico op conflicten tamelijk groot: je moet als gebruiker heel zorgvuldig checken of alles synchroon is vooraleer je naar het andere toestel overstapt.

Als er dan een conflict is - je hebt een bestand op je telefoon geopend die bijgewerkt was met de laatste versie op PC - , dan wordt het heel weinig transparant hoe je een conflict kan oplossen. Het lijkt niet mogelijk om aan te geven "deze versie moet behouden worden". Dikwijls is het advies dan één van de schijven wissen en de synchronization weer van nul af opnieuw instellen.

Ook naar snelheid heb ik mijn bedenkingen. Ik ben toen ook beginnen foto' s op de telefoon synchroniseren met de laptop om ze niet periodiek via USB te moeten overschrijven (dat is tegenwoordig slakketraag - dat noemen ze vooruitgang). Als je al eens een tijd weg bent van de PC en je komt terug met enkele honderden foto's, dan duurt het vaak uren vooraleer die enkele honderd megabytes overgebracht zijn. Via een netwerkschijf zou dergelijke transfer niet meer dan tien minuten duren.

[markba]

Zowat alles hierboven heeft te maken met syncen. Bidirectioneel kopiëren heeft nu eenmaal inherente problemen. Problemen die niet of nauwelijks van toepassing zijn bij een backup, omdat je maar naar 1 kant op kopieert.

Als er dan een conflict is - je hebt een bestand op je telefoon geopend die bijgewerkt was met de laatste versie op PC - , dan wordt het heel weinig transparant hoe je een conflict kan oplossen. Het lijkt niet mogelijk om aan te geven "deze versie moet behouden worden". Dikwijls is het advies dan één van de schijven wissen en de synchronization weer van nul af opnieuw instellen.

Een conflict komt naar eigen ervaring nauwelijks voor (kan me 1x herinneren in de paar jaar dat ik ST nu gebruik). Over het algemeen gaat ST daar naar mijn ervaring met andere tools niet beter of slechter mee om, het is gewoon technisch complex. Denk dat ik zo weinig conflicten zie omdat ST zo instantaan werkt.

Ook naar snelheid heb ik mijn bedenkingen.

Soms hapert ST wel eens, dat of de snelheid terugloopt, of dat bepaalde bestanden in de wacht staan. In alle gevallen wordt dit door ST opgelost, als je maar even wacht. Soms niet meteen, maar de staat van 'eventual consistency' wordt altijd bereikt. Let er ook op dat op sommige apparaten volgens het standaard profiel zelf aangezet moet worden, ivm bandbreedte en zo. Kun je naar believen aanpassen. Op desktops/servers speelt dit niet.

Heb veel sync-tools versleten: Ubuntu One (wie kent m nog?), DropBox, NextCloud, maar altijd was er wel wat, geen enkele werkte zo betrouwbaar dat je altijd het gevoel had dat je het proces moet monitoren. Dat gevoel heb ik met ST totaal niet.

[MKe]

Ik heb ook syncthing jarenlang gebruikt en bij mij was het redelijk betrouwbaar mits je niet achter een corporate firewall zit, omdat die meestal syncthing blokt. Een punt van aandacht is dat er wel een discovery server is die niet van jou is, maar waar je device wel op aanmeldt. Je zou dit kunnen zien als een (klein) privacy risico. Bij iets als dropbox is dat natuurlijk veel erger.

Ik heb wel eens conflicten gehad die lastig op te lossen waren en als je veel kleinere bestanden hebt kan syncthing behoorlijk traag zijn. Verder zorgt het wel voor iets meer stroom gebruik, wat een probleem kan zijn op een telefoon.

Dit is allemaal niet om syncthing af te kraken. Het is een prima tool. Ik gebruik het op dit moment ff niet meer omdat ik er nu geen usecase voor heb.

[markba]

Ik heb ook syncthing jarenlang gebruikt en bij mij was het redelijk betrouwbaar mits je niet achter een corporate firewall zit, omdat die meestal syncthing blokt.

Er werkt wel meer niet op een bedrijfsnetwerk: FTP, SSH, etc. dus dat ST niet werkt, is geen nieuws. Kan me ook geen enkele toepassing bedenken vanuit de privé-sfeer die zou moeten kunnen werken via een bedrijfsnetwerk. Mocht ST bedrijfsmatig worden toegepast, dan wordt die poort uiteraard opengezet door systeembeheer en dan werkt ST zoals bedoeld. Dit argument lijkt met dus niet relevant.

Het bijzondere (unieke?) eigenschap van ST is en blijft dat het netwerk-agnostisch is, het past zichzelf aan aan de omgeving. Heb je bv een sync  opgezet vanaf je laptop naar je NAS op je interne netwerk, dan werkt het net zo goed als je die laptop extern gebruikt (via wifi of zo bij een ander), dwars door alle routers heen over internet,  zonder dat je daar iets voor hoeft te doen (port forwarding of zo).  Dit stukje is pure magie.

als je veel kleinere bestanden hebt kan syncthing behoorlijk traag zijn.

Het verwerken van veel kleine bestanden is voor iedere tool een ding. Ook of zelfs bij rsync zie je dat de snelheid terugloopt met (veel) kleine bestanden. Moet zeggen dat ik niet eens weet heb van een mogelijke vertraging binnen ST omdat het proces autonoom, automatisch en in de achtergrond gebeurt. M.a.w. je hoeft er niet op te wachten. Dat is natuurlijk anders bij een backup die je handmatig dient te starten, dan is iedere vertraging een crime, want je moet wachten tot het proces klaar is.

Verder zorgt het wel voor iets meer stroom gebruik, wat een probleem kan zijn op een telefoon.

In theorie is dat zo, in de praktijk merk ik daar niets van. Mijn toepassing is dat ik (van flac naar ogg) getranscodeerde muziekbestanden  (20.000 stuks, 50GB) vanaf mijn muziekserver/NAS laat syncen naar mijn mobiel.  Werkt feilloos.

[vanadium]

Jou vurig pleidooi geeft me meer vertrouwen in Syncthing, bedankt! Het probleem met conflicten riskeer ik met een programma voor nota's: een laptop gooi je al snel eens plots dicht, en als dan een wijziging nog niet doorgeduwd is naar de telefoon, riskeer je een synchronisatieconflict als je daarna op de telefoon verdergaat.

[markba]

Geen enkele offline sync-tool is immuun voor conflicten, dat is nu eenmaal de aard van het beestje. Dat gezegd hebbende, heb ik de indruk dat ik met ST veel minder last van heb daarvan. Ben benieuwd naar jouw ervaring met ST.

En ontopic, voor een *backup* speelt het hele conflictverhaal überhaupt geen rol. Dus met dat element hoef je geen rekening te houden met de keuze van je backup-tool, waar ST slechts 1 van de vele is.

[henkoegema]

Als je bij ST een document weghaalt op je pc, gaat die dan ook bij de backup (syncfolder) ook weg ?

[aartje]

Ik neem aan dat deze discussie gaat over privé-backup waarbij het niet echt
belangrijk is dat er iets fout is gegaan met je bestanden. Opgeslagen muziek-en
film-bestanden zijn niet echt van levensbelang, die zijn altijd wel elders te krijgen.
Maar  voor bedrijven is het andere koek, waarbij het heel veel geld kan kosten als er
iets fout gaat, of als er per ongeluk bestanden verloren gaan of worden overschreven.

 Als dat wel zo is moet er  voor een backupstrategie gekozen worden zoals
bv beschreven staat in https://www.digitaltrustcenter.nl/back-up/geavanceerde-informatie-over-back-ups

Maar ik neem aan dat dat hier niet geldt.

[markba]

Als je bij ST een document weghaalt op je pc, gaat die dan ook bij de backup (syncfolder) ook weg ?

Ja, want ST is in eerste instantie een sync-tool waar je een een-op-een kopie maakt. Maar je kunt ST ook eenvoudig instellen zodat je deze kunt gebruiken als backup-tool met zelfs een soort van versiebeheer.

Je kunt ST bv zo instellen dat een bestand niet (meteen) weggegooid wordt. Onder Instellingen, Versiebeheer kun je de retentietijd instellen (0 = oneindig), het aantal bewaarde versies en de locatie waar die versies worden opgeslagen (zodat die bestanden niet samen bij de laatst gemaakte backup staan).

ST is dus als een Zwitsers zakmes, waar je veel mee kan (sync, backup) en die de lijn tussen lokale en cloud-backup kan laten verdwijnen. Met ST kun je een cloud-backup maken (over internet) maar naar een eigen machine die 'ergens' staat.

Opgeslagen muziek-en film-bestanden zijn niet echt van levensbelang, die zijn altijd wel elders te krijgen.

Voor mij vormen mijn muziekbestanden *juist* de belangrijkste data die ik heb, omdat het een collectie betreft waar ik jaren aan gewerkt heb (en continu uitbreid en verbeter) en die samengesteld is uit vele bronnen waar het nog maar de vraag is of deze op exact dezelfde manier hersteld kan worden. Voor jou geen ding, voor mij wel, vandaar dat ik daarvan ook *meerdere* backups heb 

[aartje]

ST is dus als een Zwitsers zakmes, waar je veel mee kan (sync, backup) en die de lijn tussen lokale en cloud-backup kan laten verdwijnen. Met ST kun je een cloud-backup maken (over internet) maar naar een eigen machine die 'ergens' staat.

Opgeslagen muziek-en film-bestanden zijn niet echt van levensbelang, die zijn altijd wel elders te krijgen.

Voor mij vormen mijn muziekbestanden *juist* de belangrijkste data die ik heb, omdat het een collectie betreft waar ik jaren aan gewerkt heb (en continu uitbreid en verbeter) en die samengesteld is uit vele bronnen waar het nog maar de vraag is of deze op exact dezelfde manier hersteld kan worden. Voor jou geen ding, voor mij wel, vandaar dat ik daarvan ook *meerdere* backups heb 

Ik wil de belangrijkheid van je muziekbestanden niet in twijfel trekken, maar voor de meeste mensen die allerlei
muziek en video (film) opgeslagen hebben is die data die zo elders weer te verkrijgen .  Het is wel data die veruit de meeste
ruimte in beslag neemt (gigabytes) en daar voldoet het clonen van de data naar elders en/of éénmaal op een extern
medium zetten (ik doe dat met DVD's)
Voor cruciale data van bv een bedrijf is dit niet voldoende, daar kan het verlies van data of het niet meer toegankelijk
zijn van data heel veel geld kosten, het kan je zelfs je bedrijf kosten....
Daar is het eenvoudig clonen  of data naar een extern medium toesturen niet voldoende maar is het echt
wel nodig om een goede backup-strategie te hebben en het uitvogelen daarvan is een echt vak....
Deze link bv  is een waarschuwing : https://www.bechtle.com/nl/it-solutions/it-security/backup-recovery?utm_source=google&utm_medium=cpc&utm_campaign=17278583740&utm_content=back%20up%20strategie&gad_source=1&gclid=EAIaIQobChMIpo_PiJiehgMVvKuDBx05XzivEAAYASAAEgJKOvD_BwE

[bart85]

Ook al kun je de data van verloren muziek opnieuw downloaden. Je moet wel een lijst hebben van de nummers die je hebt verloren.

[markba]

Opgeslagen muziek-en film-bestanden zijn niet echt van levensbelang, die zijn altijd wel elders te krijgen.

Voor mij vormen mijn muziekbestanden *juist* de belangrijkste data die ik heb, omdat het een collectie betreft waar ik jaren aan gewerkt heb (en continu uitbreid en verbeter) en die samengesteld is uit vele bronnen waar het nog maar de vraag is of deze op exact dezelfde manier hersteld kan worden. Voor jou geen ding, voor mij wel, vandaar dat ik daarvan ook *meerdere* backups heb 

Ik wil de belangrijkheid van je muziekbestanden niet in twijfel trekken,

Dat doe je wel. Voorts is het niet relevant wat *jij* vindt over *mijn* data, maar wat *ik* ervan vind, toch? Maar los van dat, iedereen heeft dus andere dingen die hij/zij belangrijk vindt dus graag in een backup terug wil zien. Discussie daarover is nogal zinloos.

Voor cruciale data van bv een bedrijf is dit niet voldoende, daar kan het verlies van data of het niet meer toegankelijk
zijn van data heel veel geld kosten, het kan je zelfs je bedrijf kosten....

Verbeter me als het niet zo is, maar de TS heeft het over een niet-bedrijfsmatige oplossing. Van privé-data dus. Daar gelden andere normen voor zoals je begrijpt. Vaak is een een-op-een kopie al meer dan genoeg, om bv een harddisk-crash te overleven.

Ook al kun je de data van verloren muziek opnieuw downloaden. Je moet wel een lijst hebben van de nummers die je hebt verloren.

Nee dus. Mijn collectie heeft zeer veel bronnen (originele CD's, geleende CD's, downloads, uitwisseling met anderen, etc.), bronnen die vaak niet meer toegankelijk zijn. En niet de vergeten het nooit ophoudende onderhoud op tags en cover-art. Alsmede handmatige aanpassingen aan de muziekbestanden zelf.  Maw er zit veel, heel veel werk in.

Maar zoals gezegd, discussie wat iemand vindt over de data van een ander en de wenselijkheid om die te backuppen valt buiten het bestek van deze draad lijkt me zo.

[aartje]

Verbeter me als het niet zo is, maar de TS heeft het over een niet-bedrijfsmatige oplossing. Van privé-data dus. Daar gelden andere normen voor zoals je begrijpt. Vaak is een een-op-een kopie al meer dan genoeg, om bv een harddisk-crash te overleven.

Nogmaals, ik wil de belangrijkheid van je muziek-data voor jou niet in twijfel trekken, en je hebt gelijk dat de TS het
over niet-professionele backups heeft, ik waarschuw alleen maar dat je bedrijfsmatig wel risico's neemt als je denkt
dat je op de beschreven manieren veilige backups maakt.
Maar ja, we blijven natuurlijk hobby-isten 

[henkoegema]

In deze youtube video : https://www.youtube.com/watch?v=cREJHcu5G80&ab_channel=EF-LinuxMadeSimple
op tijdstip 6:00 wordt rsync -azz -e ssh ...... gebruikt.

Vraag: Wat is het verschil tussen rsync -az ...... en rsync -azz....... ?
Heeft 2 keer dezelfde parameter wel effect?

[markba]

Technisch gezien staat er drie (!) keer de z-parameter (= compressie) en 2x de a-parameter (= archive). 1x een parameter noemen is meer dan genoeg.

Compressie gebruik ik niet, zie daar in mijn situatie geen voordeel in. Hangt sterk af van de soort data wat je gaat syncen, de snelheid van je processor en je netwerk-snelheid. Mocht je een snelle processor hebben met maar zeer weinig netwerk-bandbreedte, dan zou je er een voordeel mee hebben.
https://unix.stackexchange.com/questions/188737/does-compression-option-z-with-rsync-speed-up-backup

[henkoegema]

Gisteren gebruikte ik dit :

Code: [Selecteer]

rsync -az -e ssh ~/Pictures 192.168.2.43:/media/henkoegema/469215E90B211BDB10om de folder Pictures van m'n laptop te backuppen naar m'n USB harddisk op m'n desktop

Vandaag:

Code: [Selecteer]

henkoegema@HP-Laptop:~/Pictures$ rsync -az -e ssh ~/Pictures 192.168.2.43:/media/henkoegema/469215E90B211BDB10
rsync: [Receiver] change_dir#1 "/media/henkoegema/469215E90B211BDB10" failed: Permission denied (13)
Gisteren was ik de eigenaar van 469215E90B211BDB10
Vandaag ben ik de eigenaar van 469215E90B211BDB11     

Hoe kan dat?
Wat zijn al die (lege ?) mappen?

Code: [Selecteer]

4 drwx------   2 root       root       4096 jan 14  2023 469215E90B211BDB
4 drwx------   2 root       root       4096 mei 24  2023 469215E90B211BDB1
4 drwx------   2 root       root       4096 mei 23 08:51 469215E90B211BDB10
4 drwxr-xr-x   1 henkoegema henkoegema 4096 mei 22 16:59 469215E90B211BDB11
4 drwx------   2 root       root       4096 mei 24  2023 469215E90B211BDB2
4 drwx------   2 root       root       4096 jun  5  2023 469215E90B211BDB3
4 drwx------   2 root       root       4096 jul 15  2023 469215E90B211BDB4
4 drwx------   2 root       root       4096 aug 11  2023 469215E90B211BDB5
4 drwx------   2 root       root       4096 okt 14  2023 469215E90B211BDB6
4 drwx------   2 root       root       4096 jan  2 09:00 469215E90B211BDB7
4 drwx------   2 root       root       4096 mei  4 09:22 469215E90B211BDB8
4 drwx------   2 root       root       4096 mei 21 16:34 469215E90B211BDB9


[henkoegema]

Vandaag:

Code: [Selecteer]

4 drwx------   2 root       root       4096 jan 14  2023 469215E90B211BDB
4 drwx------   2 root       root       4096 mei 24  2023 469215E90B211BDB1
4 drwx------   2 root       root       4096 mei 23 08:51 469215E90B211BDB10       <--------- eergisteren
4 drwx------   2 root       root       4096 mei 24 09:28 469215E90B211BDB11       <--------- gisteren
4 drwxr-xr-x   1 henkoegema henkoegema 4096 mei 22 16:59 469215E90B211BDB12       <--------- vandaag
4 drwx------   2 root       root       4096 mei 24  2023 469215E90B211BDB2
4 drwx------   2 root       root       4096 jun  5  2023 469215E90B211BDB3
4 drwx------   2 root       root       4096 jul 15  2023 469215E90B211BDB4
4 drwx------   2 root       root       4096 aug 11  2023 469215E90B211BDB5
4 drwx------   2 root       root       4096 okt 14  2023 469215E90B211BDB6
4 drwx------   2 root       root       4096 jan  2 09:00 469215E90B211BDB7
4 drwx------   2 root       root       4096 mei  4 09:22 469215E90B211BDB8
4 drwx------   2 root       root       4096 mei 21 16:34 469215E90B211BDB9

Welke logica zit hier achter?
Hoe kan ik dit voorkomen, zodat rsync altijd dezelfde 'entry' gebruikt?