La cultura del backup

[danilo_g]

Bisogna anche chiedersi però quanto siano probabili le "corruzioni silenziose dei file" e darsi risposte realistiche, non puramente teoriche o speculative. Forse su un SAN aziendale a più nodi e filesystem distribuito, o su un RAID con molti dischi, c'è una probabilità con rilevanza statistica... Ma non credo su un disco collegato via USB al PC domestico o di lavoro. Perché se no si fa passare il messaggio (sbagliato) che per fare un backup bisogna essere ingegneri o esperti, quando non è così.

Poi, se uno vuol fare un controllo sui file copiati, può benissimo farlo, o tramite script o tramite tool appositi. Francamente io non mi pongo il problema, so che quello che uso funziona bene, ogni tanto verifico il ripristino, stop. Mica ho giorni da dedicare a sta roba.

La verifica del backup funzionante l'ho detto anche io 3 volte senza guardare il video, che poi cita anche quello la soluzione del 3-2-1 quindi boh... ci stiamo ripetendo.

[korda]

Speriamo che l'error-prone nella copia non sia come negli esseri viventi. Lì i meccanismi di proofreading tamponano fino ad 1 errore su 10Gb, ma d'altra parte un minimo di mutagenesi di fondo è necessaria per l'evoluzione

[emanuc]

Bisogna anche chiedersi però quanto siano probabili le "corruzioni silenziose dei file" e darsi risposte realistiche, non puramente teoriche o speculative.

Accade più spesso di quanto si pensi. Se nessuno si accorge di qualche corruzione sporadica, è perché sono diffusi filesystem senza checksumming sui dati. Tuttavia, non è questo il punto. Il punto è che bisogna considerare questo aspetto. Sta qui la differenza tra un buon backup e uno fatto male.

Ma non credo su un disco collegato via USB al PC domestico o di lavoro

Soprattutto quando si usa per il backup un disco USB...
Che sia per lavoro o no, ha poca rilevanza se sono dati importanti per l'utente.

Perché se no si fa passare il messaggio (sbagliato) che per fare un backup bisogna essere ingegneri o esperti, quando non è così.

Come per ogni cosa, ci si deve documentare. Da qui "la cultura del backup". Che poi, ripeto, non ci vedo niente di complesso da configurare un tool da GUI.
Il messaggio sbagliato è dire che, siccome stai facendo il backup nel modo sbagliato, semplice o come sei abituato (una semplice copia trascinando i file), dovresti continuare così, senza migliorarti o rivolgerti a un esperto se non vuoi imparare. Tanto, la corruzione dei dati o la rottura hardware è così rara che non devi preoccupartene...

Poi, se uno vuol fare un controllo sui file copiati, può benissimo farlo, o tramite script o tramite tool appositi.

Se uno vuole le cose semplici, senza creare script da "ingegneri" ci sono tool da GUI che facilitano la vita all'utente.

[Lucio C]

Speriamo che l'error-prone nella copia non sia come negli esseri viventi.

Oppure si potrebbe pensare ai filologi che studiano antichi documenti (manoscritti su papiro o pergamena, o magari pietra o tavolette di terracotta) e all'effetto degli errori dei copisti

[korda]

Non ho capito una cosa.... Sicuri che il checksum operato, dell'opzione relativa di rsync, richiami funzionalità integrate di soli alcuni filesystem?

[danilo_g]

Bisogna anche chiedersi però quanto siano probabili le "corruzioni silenziose dei file" e darsi risposte realistiche, non puramente teoriche o speculative.

Accade più spesso di quanto si pensi. Se nessuno si accorge di qualche corruzione sporadica, è perché sono diffusi filesystem senza checksumming sui dati. Tuttavia, non è questo il punto. Il punto è che bisogna considerare questo aspetto. Sta qui la differenza tra un buon backup e uno fatto male.

Si ma quanto spesso succede?

Ma non credo su un disco collegato via USB al PC domestico o di lavoro

Soprattutto quando si usa per il backup un disco USB...
Che sia per lavoro o no, ha poca rilevanza se sono dati importanti per l'utente.

Ma infatti per le cose importanti si fanno due copie, una offsite, etc. etc.

Hai prove che confermino questa tua teoria? Dati, studi,etc. Altrimenti sono solo tue elucubrazioni, e vabè ormai le abbiamo capite visto che ce le stai martellando in loop. Non è che sarai un pochettino OCD?

Perché se no si fa passare il messaggio (sbagliato) che per fare un backup bisogna essere ingegneri o esperti, quando non è così.

Come per ogni cosa, ci si deve documentare. Da qui "la cultura del backup". Che poi, ripeto, non ci vedo niente di complesso da configurare un tool da GUI.

Ma uno non deve fare niente di quello che non sente il bisogno, o che gli impongano le leggi, punto primo.

Punto secondo, che il backup sia importante penso che ormai sia evidente (a tutti i partecipanti di questa discussione e spero anche a tutti gli utenti di questo forum). Ma quello che tu intendi per backup è la tua intepretazione di backup, che non è detto che coincida con quella di un altro. Quindi sto cercare di non so... "inculcare" nelle menti con delle antifone non serve a molto. Perché non ci sono solo le argomentazioni che hai portato a pesare sulla bilancia, ce ne sono anche altre che possono far propendere per certe soluzioni. Che poi tu le accetti o meno cambia niente a nessuno.

Inoltre quella che tu stesso hai riportato, presa non so da dove, con cui io mi trovo assolutamente d'accordo, è la definizione corretta:
Un backup è una copia di sicurezza dei dati o di un sistema informatico che viene creata per prevenire la perdita di informazioni in caso di guasti, errori, o eventi imprevisti, come attacchi informatici, malfunzionamenti hardware, cancellazioni accidentali, o disastri naturali.
È generica il giusto per intendere quello che va inteso nel modo corretto, senza restringere il campo. Poi ognuno si fa le sue valutazioni ed eventualmente in base alle sue esigenze prende o meno determinate decisioni.

Il messaggio sbagliato è dire che, siccome stai facendo il backup nel modo sbagliato, semplice o come sei abituato (una semplice copia trascinando i file), dovresti continuare così, senza migliorarti o rivolgerti a un esperto se non vuoi imparare. Tanto, la corruzione dei dati o la rottura hardware è così rara che non devi preoccupartene...

Pensa che ho dei dati perfettamente leggibili su CD e DVD degli anni 90 e 2000, non avevo neanche copie di backup.

Ho dati leggibili (anche se pure molti li ho cancellati) di 20 anni fa, copiati non so quante volte da un disco a un altro.

Ho in giro anche numerosi floppy, alcuni sono sicuro che si leggerebbero bene pure oggi. Ho la sfiga di essere abbastanza vecchio da avere interesse per il retrogaming/computing. Un sacco di gente con giochi e programmi addirittura su cassetta. Tutta roba che ha 40 anni ormai, chissà quanti errori di copia... però oh, ci giocano e funzionano ancora.

Quindi in base alle mie esperienze & percezioni, errori di copia o di "corruzione silenziosa" sono molto, molto rari. Forse talmente rari da superare la vita utile di un dispositivo o di un dato (perché sì, a meno di essere degli archivisti, prima o poi le robe vanno al macero, anche in digitale).

[korda]

Non ho capito una cosa.... Sicuri che il checksum operato, dell'opzione relativa di rsync, richiami funzionalità integrate di soli alcuni filesystem?

Riedito qui con un link a riguardo

https://unix.stackexchange.com/question ... emote-file

Si parla di checksum essenzialmente per la sincronizzazione remota, ma nulla vieta di poterlo applicare localmente con un rsync verso un disco esterno. Credo...

[danilo_g]

Si parla di checksum essenzialmente per la sincronizzazione remota, ma nulla vieta di poterlo applicare localmente con un rsync verso un disco esterno. Credo...

Codice: Seleziona tutto

-c, --checksum
    This changes the way rsync checks if the files have been changed and are in need of a transfer. Without this option, rsync uses a lqquick checkrq that (by default) checks if each file's size and time of last modification match between the sender and receiver. This option changes this to compare a 128-bit checksum for each file that has a matching size. Generating the checksums means that both sides will expend a lot of disk I/O reading all the data in the files in the transfer (and this is prior to any reading that will be done to transfer changed files), so this can slow things down significantly. 
The sending side generates its checksums while it is doing the file-system
    scan that builds the list of the available files. The receiver generates its checksums when it is scanning for changed files, and will checksum any file that has the same size as the corresponding sender's file: files with either a changed size or a changed checksum are selected for transfer. 
    
Note that rsync always verifies that each transferred file was
    correctly reconstructed on the receiving side by checking a whole-file checksum that is generated as the file is transferred, but that automatic after-the-transfer verification has nothing to do with this option's before-the-transfer lqDoes this file need to be updated?rq check. 
For protocol 30 and beyond (first supported in 3.0.0), the checksum used is
    MD5. For older protocols, the checksum used is MD4. 

Notare la nota.

[emanuc]

Hai prove che confermino questa tua teoria? Dati, studi,etc. Altrimenti sono solo tue elucubrazioni, e vabè ormai le abbiamo capite visto che ce le stai martellando in loop. Non è che sarai un pochettino OCD?

Queste considerazioni personali tienitele per te, non ho aperto questa discussione per farmi insultare o farmi prendere in giro. Se la tua argomentazione è questa, per me la discussione può essere chiusa, speravo in qualcosa di più costruttivo.
Dati e studi li hai nel mondo reale dove il guasto hardware esiste ed è reale. Esci dalla tua bolla.
Tuttavia, Backblaze pubblica da anni statistiche sui guasti dei dischi.
Poi se dobbiamo basarci sulla tua esperienza personale, allora alzo le mani...

Per me questa discussione può essere chiusa.

[danilo_g]

Hai prove che confermino questa tua teoria? Dati, studi,etc. Altrimenti sono solo tue elucubrazioni, e vabè ormai le abbiamo capite visto che ce le stai martellando in loop. Non è che sarai un pochettino OCD?

Queste considerazioni personali tienitele per te, non ho aperto questa discussione per farmi insultare o farmi prendere in giro. Se la tua argomentazione è questa, per me la discussione può essere chiusa, speravo in qualcosa di più costruttivo.
Dati e studi li hai nel mondo reale dove il guasto hardware esiste ed è reale. Esci dalla tua bolla.
Tuttavia, Backblaze pubblica da anni statistiche sui guasti dei dischi.
Poi se dobbiamo basarci sulla tua esperienza personale, allora alzo le mani...

Per me questa discussione può essere chiusa.

a te. Ma che presa in giro, io volevo solo delle prove che confermassero le tue affermazioni sulla frequenza della "corruzione silenziosa dei dati", visto che "succede più spesso di quanto si pensi" non vuol dire molto (quanto si pensa?). Che i dischi si guastino lo sapevo anche da me. E comunque, sempre nella mia "bolla", l'anno scorso ho buttato via un disco che aveva più di 10 anni. Lo usavo come disco di backup, quindi ovviamente non ho person nulla. Just for saying. Ah si, poi da un'altra parte avrei dei dischi che girano dal 2008 adirittura WD Green, una delle peggiori serie uscite... non so come facciano ma tant'è. E questo per dire che anche i benchmark, per quanto accurati, vanno messi in prospettiva.

Anche in certi ambiti professionali fidati che sono in tanti a non usare backup versionati o verificati, eppure campano ugualmente. Certo, quando uno può poi investe in sistemi di backup più avanzati basati su disco o su nastro. Non per sminuire borg, ma che credi, che sia la soluzione definitiva? In ambito enterprise boh si forse qualche server che fa backup tramite borg con borgmatic c'è anche, ma non è certo la soluzione d'elezione. Ho visto uffici medio-piccoli reggersi su scriptini di copia/sincronizzazione, altri manco avevano un backup in essere... Questo è "La cultura del backup", fuori dalla mia "bolla".

[korda]

Si parla di checksum essenzialmente per la sincronizzazione remota, ma nulla vieta di poterlo applicare localmente con un rsync verso un disco esterno. Credo...

Codice: Seleziona tutto

-c, --checksum
    This changes the way rsync checks if the files have been changed and are in need of a transfer. Without this option, rsync uses a lqquick checkrq that (by default) checks if each file's size and time of last modification match between the sender and receiver. This option changes this to compare a 128-bit checksum for each file that has a matching size. Generating the checksums means that both sides will expend a lot of disk I/O reading all the data in the files in the transfer (and this is prior to any reading that will be done to transfer changed files), so this can slow things down significantly. 
The sending side generates its checksums while it is doing the file-system
    scan that builds the list of the available files. The receiver generates its checksums when it is scanning for changed files, and will checksum any file that has the same size as the corresponding sender's file: files with either a changed size or a changed checksum are selected for transfer. 
    
Note that rsync always verifies that each transferred file was
    correctly reconstructed on the receiving side by checking a whole-file checksum that is generated as the file is transferred, but that automatic after-the-transfer verification has nothing to do with this option's before-the-transfer lqDoes this file need to be updated?rq check. 
For protocol 30 and beyond (first supported in 3.0.0), the checksum used is
    MD5. For older protocols, the checksum used is MD4. 

Notare la nota.

Ok, l'opzione checksum è un metodo di verifica se il file sorgente è cambiato rispetto alla destinazione. Il checksum in fase post copia viene già fatto di suo. Grazie

[OMBRA_Linux]

Prima di tutto bisogna capire di cosa vuoi fare il Backup, dopo di che si procede all'uso dei Software appositi.
Edit: ''Backup e Sincronizzazione dei file '' sono due cose diverse che però possono esse combinate insieme.

Personalmente salvo solo i Dati su di un Disco esterno.

[emanuc]

Non per sminuire borg, ma che credi, che sia la soluzione definitiva? In ambito enterprise boh si forse qualche server che fa backup tramite borg con borgmatic c'è anche, ma non è certo la soluzione d'elezione

La dimostrazione che non leggi ciò che scrivo. Comunque, non sono più interessato a portare avanti questa discussione.

[danilo_g]

Ok, l'opzione checksum è un metodo di verifica se il file sorgente è cambiato rispetto alla destinazione. Il checksum in fase post copia viene già fatto di suo. Grazie

Esatto, il che azzera o quasi la possibilità di errori durante la copia/sincronizzazione, by default.

Non per sminuire borg, ma che credi, che sia la soluzione definitiva? In ambito enterprise boh si forse qualche server che fa backup tramite borg con borgmatic c'è anche, ma non è certo la soluzione d'elezione

La dimostrazione che non leggi ciò che scrivo. Comunque, non sono più interessato a portare avanti questa discussione.

Come vuoi. Però rimane la questione sul piatto a cui non hai fornito i chiarimenti richiesti. ¯\_(ツ)_/¯