La cultura del backup

[emanuc]

Ma quello è il TUO parere.

Copiare un file in un altro dispositivo significa già fare una copia di backup di quel file.
Tu puoi farti il backup come preferisci.

Non capisco perché voler creare delle Regole che non avrebbero valore per tutti.

Non intendo stabilire regole né imporre alcun metodo. Ho aperto questa discussione per favorire un confronto costruttivo e per chi desidera approfondire e migliorare le proprie pratiche di backup. Si chiama condivisione, dovrebbe essere una delle basi principali in una comunità di informatica.
Se il tuo metodo di backup ti soddisfa e preferisci non partecipare al confronto, va benissimo così. Continua pure con il tuo approccio, non è un problema per me.
PS: Io cerco sempre nuove soluzioni, migliorare le mie competenze, esplorare metodi alternativi e ascoltare gli utenti più esperti di me. In passato, ho utilizzato DejaDup (preinstallato su Ubuntu), ma ho riscontrato problemi di corruzione degli archivi a causa di qualche bug del software. Successivamente, ho esplorato varie soluzioni con interfaccia grafica che utilizzano rsync, come LuckyBackup e BackInTime. Poi, confrontandomi con vari utenti della comunità, ho scoperto software di backup più efficienti.

[jeremie2]

Riporto la mia esperienza, che premetto essere molto tera tera e chiaramente in certi contesti non è assolutamente da prendere in considerazione.

Per i file si è sempre trattato di salvataggi manuali, anche per il fatto che tutto sommato non ho mai avuto a che fare con grandi quantità di dati. Le accortezze che ho adottato sono di avere una partizione dati sul disco, meglio ancora se il computer consente un doppio disco da dedicare ai soli dati. E poi dischi esterni.
C'è poi un ordine di importanza dei dati. Quando ho a che fare con documenti importanti, quelli vengono subito salvati sia su partizione dati che su disco esterno.

Per quanto riguarda il sistema operativo, beh la mia difesa è sempre stata avere molti sistemi operativi.
Non è stata cosa pianificata, però da quando ho iniziato a utilizzare Linux in automatico mi sono trovato a eseguire moltiboot data la mia curiosità di provare le diverse distribuzioni e la semplicità con cui si creano multiboot. Col tempo ho notato che questo era anche un modo decisamente efficiente per ovviare a eventuali problemi con il sistema operativo o anche solo con uno uno dei software, amen... avvio un altro sistema e vado avanti lo stesso.
Oltre il fatto che data la velocità di installazione di Linux, supponendo un disastro che spazzasse via la "ridondanza" di sistemi, non mi ha mai terrorizzato l'eventualità di una nuova installazione come estremo rimedio. Anche questo ha contribuito a farmi montare una certa spavalderia.

Come ho premesso all'inizio un'impostazione del genere in certi ambiti non potrebbe essere accettabile. È chiaro che se ti ritrovi con una macchina che deve fornire in modo continuativo dei servizi, che in un'eventuale re-installazione comporta un grande lavoro per riconfigurare i software, oppure se per lavoro (ma anche hobby) si ha a che fare con grandi moli di dati dove i singoli salvataggi diventano una grossa perdita di tempo.... benvengano snapshot e quant'altro!

[Darren]

Ma quello è il TUO parere.

Copiare un file in un altro dispositivo significa già fare una copia di backup di quel file.
Tu puoi farti il backup come preferisci.

Non capisco perché voler creare delle Regole che non avrebbero valore per tutti.

Non intendo stabilire regole né imporre alcun metodo. Ho aperto questa discussione per favorire un confronto costruttivo e per chi desidera approfondire e migliorare le proprie pratiche di backup. Si chiama condivisione, dovrebbe essere una delle basi principali in una comunità di informatica.
Se il tuo metodo di backup ti soddisfa e preferisci non partecipare al confronto, va benissimo così. Continua pure con il tuo approccio, non è un problema per me.
PS: Io cerco sempre nuove soluzioni, migliorare le mie competenze, esplorare metodi alternativi e ascoltare gli utenti più esperti di me. In passato, ho utilizzato DejaDup (preinstallato su Ubuntu), ma ho riscontrato problemi di corruzione degli archivi a causa di qualche bug del software. Successivamente, ho esplorato varie soluzioni con interfaccia grafica che utilizzano rsync, come LuckyBackup e BackInTime. Poi, confrontandomi con vari utenti della comunità, ho scoperto software di backup più efficienti.

Perdonami, ma nn sembrava così, almeno dalle tue risposte.

Io ho partecipato al confronto, come altri, ma le tue risposte erano del tipo “quello non è un backup…” “quel software è vecchio…” “quello è solo copiare i file…”

A me sembra di vedere che esistono svariati metodi per fare (farsi) il backup dei dati

C è anche chi tiene tutto sincronizzato su Drive/iCloud e anche quello è un tipo di backup

Tu evidentemente hai bisogno o sei alla ricerca di software dedicato e preferisci qualcosa di più complesso, non nell utilizzo ma nel suo funzionamento, perché non ti accontenti di semplici “copie” dei tuoi files.
E ci sta.

[caturen]

https://www.youtube.com/watch?v=DxEt0iHS4N0
https://kopia.io/docs/features/

[emanuc]

https://www.youtube.com/watch?v=DxEt0iHS4N0
https://kopia.io/docs/features/

Esatto, è proprio ciò che sto cercando di dire, racchiuso in un video. Sto seguendo Restic molto da vicino, ma purtroppo non ci sono client GUI ben mantenuti, e a me piace la comodità della GUI. Rispetto a Borg, Restic ha una flessibilità maggiore sulle destinazioni remote come servizi di cloud ecc
Non conosco Kopia, ma sembra molto interessante!
Ho trovato un client da GUI su flathub: https://flathub.org/apps/io.kopia.KopiaUI

[emanuc]

Perdonami, ma nn sembrava così, almeno dalle tue risposte.

Io ho partecipato al confronto, come altri, ma le tue risposte erano del tipo “quello non è un backup…” “quel software è vecchio…” “quello è solo copiare i file…”

A me sembra di vedere che esistono svariati metodi per fare (farsi) il backup dei dati

C è anche chi tiene tutto sincronizzato su Drive/iCloud e anche quello è un tipo di backup

Tu evidentemente hai bisogno o sei alla ricerca di software dedicato e preferisci qualcosa di più complesso, non nell utilizzo ma nel suo funzionamento, perché non ti accontenti di semplici “copie” dei tuoi files.
E ci sta.

Penso che il backup complesso lo fai usando software non dedicati, perché devi preoccuparti di molti aspetti del backup. Io non sono un amante degli script e dalla CLI, li evito quando posso, sono un amante della comodità delle GUI, dove con 3 click configuro tutto.
La motivazione della mia risposta al "non è un backup" o "non è un buon backup" la puoi ascoltare nel video di Morro (link sopra). Esprime ciò che intendo dire: "Backup artigianali con script... rinunciando però a importanti funzionalità come il pruning automatico e il controllo di integrità dei dati sottoposti a backup. Se vi accorgete che i backup sono corrotti solo quando vi servono, è ormai troppo tardi."

[emanuc]

Riporto la mia esperienza, che premetto essere molto tera tera e chiaramente in certi contesti non è assolutamente da prendere in considerazione.

Per i file si è sempre trattato di salvataggi manuali, anche per il fatto che tutto sommato non ho mai avuto a che fare con grandi quantità di dati. Le accortezze che ho adottato sono di avere una partizione dati sul disco, meglio ancora se il computer consente un doppio disco da dedicare ai soli dati. E poi dischi esterni.
C'è poi un ordine di importanza dei dati. Quando ho a che fare con documenti importanti, quelli vengono subito salvati sia su partizione dati che su disco esterno.

Per quanto riguarda il sistema operativo, beh la mia difesa è sempre stata avere molti sistemi operativi.
Non è stata cosa pianificata, però da quando ho iniziato a utilizzare Linux in automatico mi sono trovato a eseguire moltiboot data la mia curiosità di provare le diverse distribuzioni e la semplicità con cui si creano multiboot. Col tempo ho notato che questo era anche un modo decisamente efficiente per ovviare a eventuali problemi con il sistema operativo o anche solo con uno uno dei software, amen... avvio un altro sistema e vado avanti lo stesso.
Oltre il fatto che data la velocità di installazione di Linux, supponendo un disastro che spazzasse via la "ridondanza" di sistemi, non mi ha mai terrorizzato l'eventualità di una nuova installazione come estremo rimedio. Anche questo ha contribuito a farmi montare una certa spavalderia.

Come ho premesso all'inizio un'impostazione del genere in certi ambiti non potrebbe essere accettabile. È chiaro che se ti ritrovi con una macchina che deve fornire in modo continuativo dei servizi, che in un'eventuale re-installazione comporta un grande lavoro per riconfigurare i software, oppure se per lavoro (ma anche hobby) si ha a che fare con grandi moli di dati dove i singoli salvataggi diventano una grossa perdita di tempo.... benvengano snapshot e quant'altro!

Io faccio una distinzione tra il backup dei dati e gli snapshot/backup di sistema. Per il backup dei dati uso Borg con la GUI Pika, mentre per gli snapshot di sistema, al momento, sto usando Btrfs Assistant. Ogni tanto invio anche gli snapshot di sistema al backup; purtroppo, per questo ho dovuto scrivere uno scriptino perché non esistono GUI per btrfs send|receive

Ma è uno script semplice

Codice: Seleziona tutto

#!/bin/bash
echo "Invio al backup degli snap presenti dentro la cartella: <$1> | al percorso esterno: <$2>"
for i in `ls "$1"`;
do
    echo "Invio al backup dello snapshot: $i, al percorso esterno $2"         
    btrfs send --compressed-data "$1$i" | btrfs receive "$2"
    echo "backup dello snapshot $i completato"
done
echo "Backup completato."

Codice: Seleziona tutto

emanu@fedora ~> sudo btrfs subvolume list -t /media/emanu/backup2T/
[sudo] password di emanu:
ID	gen	top level	path	
--	---	---------	----	
308	5547	5		OS_Backup/Notebook_Fedora38-gnome/@
309	5538	5		OS_Backup/Notebook_Fedora38-gnome/@home
310	2297	5		OS_Backup/Notebook_Fedora38-gnome/var_cache
311	2313	5		OS_Backup/Notebook_Fedora38-gnome/var_lib_flatpak
312	2315	5		OS_Backup/Notebook_Fedora38-gnome/var_lib_machines
313	2320	5		OS_Backup/Notebook_Fedora38-gnome/var_log
314	2324	5		OS_Backup/Notebook_Fedora38-gnome/var_tmp
315	4182	5		OS_Backup/Fedora38-KDE-27Giugno2023/@
316	5509	5		OS_Backup/Fedora38-KDE-27Giugno2023/@home
317	5538	5		OS_Backup/Fedora38-KDE-27Giugno2023/home.var
318	2831	5		OS_Backup/Fedora38-KDE-27Giugno2023/var_cache
319	2838	5		OS_Backup/Fedora38-KDE-27Giugno2023/var_lib_flatpak
320	2842	5		OS_Backup/Fedora38-KDE-27Giugno2023/var_lib_libvirt
321	2846	5		OS_Backup/Fedora38-KDE-27Giugno2023/var_log
322	2849	5		OS_Backup/Fedora38-KDE-27Giugno2023/var_tmp
328	5547	5		OS_Backup/Fedora38-KDE-26Agosto2023/@
329	5547	5		OS_Backup/Fedora38-KDE-26Agosto2023/@home
331	5538	5		OS_Backup/Fedora38-KDE-26Agosto2023/var_cache
334	2946	5		OS_Backup/Fedora38-KDE-26Agosto2023/var_lib_machines
335	2954	5		OS_Backup/Fedora38-KDE-26Agosto2023/var_log
336	2954	5		OS_Backup/Fedora38-KDE-26Agosto2023/var_tmp
338	5547	5		OS_Backup/Fedora38-KDE-26Agosto2023/emanu_var
340	3115	5		OS_Backup/Fedora38-KDE-26Agosto2023/var_lib_libvirt
341	5538	5		OS_Backup/Fedora38-KDE-26Agosto2023/opt
342	5547	5		OS_Backup/IdeaPad-flex_DebianTestingKDE-26Settembre2023/@
343	5520	5		OS_Backup/IdeaPad-flex_DebianTestingKDE-26Settembre2023/@home
344	3353	5		OS_Backup/IdeaPad-flex_DebianTestingKDE-26Settembre2023/@opt
345	3357	5		OS_Backup/IdeaPad-flex_DebianTestingKDE-26Settembre2023/@var_cache
346	5482	5		OS_Backup/IdeaPad-flex_DebianTestingKDE-26Settembre2023/var_lib_flatpak
347	3365	5		OS_Backup/IdeaPad-flex_DebianTestingKDE-26Settembre2023/@var_log
348	3366	5		OS_Backup/IdeaPad-flex_DebianTestingKDE-26Settembre2023/@var_tmp
349	3821	5		OS_Backup/Fedora 39 KDE/@
350	5471	5		OS_Backup/Fedora 39 KDE/home_emanu_.var
351	3831	5		OS_Backup/Fedora 39 KDE/opt
352	3831	5		OS_Backup/Fedora 39 KDE/var_cache
353	5444	5		OS_Backup/Fedora 39 KDE/var_lib_flatpak
354	3836	5		OS_Backup/Fedora 39 KDE/var_lib_libvirt
355	3837	5		OS_Backup/Fedora 39 KDE/var_lib_machines
356	3843	5		OS_Backup/Fedora 39 KDE/var_log
357	3843	5		OS_Backup/Fedora 39 KDE/var_tmp

[caturen]

Esatto, è proprio ciò che sto cercando di dire, racchiuso in un video.

si, ma tutto questo discorso ha un suo "senso" se indirizzato ad un "amministratore di sistema" che ha a che fare con "cose complicate". Il 99,99% delle persone che ha un computer non se ne fa nulla di queste cose. Certo che se vai a contare quello 0,01% sono in numeri effettivi molti ed hanno a che fare con sistemi molto complessi che devono essere salvaguardati in ogni evenienza. Certamente questi devono salvaguardare ogni piccolo bit di ciò che amministrano.

[caturen]

Ho trovato un client da GUI su flathub: https://flathub.org/apps/io.kopia.KopiaUI

che bisogno c'è di flatpack quando puoi avere la gui direttamente dai repository

Two Variants of Kopia

Kopia is a standalone binary and can be used through a command-line interface (CLI) or a graphical user interface (GUI).

If you want to use Kopia via CLI, you will install the kopia binary; when you want to use Kopia, you will call the kopia binary (along with Kopia commands) in a terminal/command prompt window or within a script.

If you want to use Kopia via GUI, you will install KopiaUI, the name of the Kopia GUI. The installer for KopiaUI comes with the kopia binary and a graphical user interface called KopiaUI - a wrapper for the kopia binary. KopiaUI runs the kopia binary and associated commands as necessary, so you do not need to use the command-line interface.

Linux installation using APT (Debian, Ubuntu)

Kopia offers APT repository compatible with Debian, Ubuntu and other similar distributions.

To begin, install the GPG signing key to verify authenticity of the releases.

curl -s https://kopia.io/signing-key | sudo gpg --dearmor -o /etc/apt/keyrings/kopia-keyring.gpg

Register APT source:

echo "deb [signed-by=/etc/apt/keyrings/kopia-keyring.gpg] http://packages.kopia.io/apt/ stable main" | sudo tee /etc/apt/sources.list.d/kopia.list
sudo apt update

By default, the stable channel provides official stable releases. If you prefer you can also select testing channel (which also provides release candidates and is generally stable) or unstable which includes all latest changes, but may not be stable.

Finally, install Kopia or KopiaUI:

sudo apt install kopia
sudo apt install kopia-ui

[danilo_g]

Se vi accorgete che i backup sono corrotti solo quando vi servono, è ormai troppo tardi."

E indovina un po' come fai a sapere se un backup non è corrotto / è valido??
Prima pagina:

L'integrità dei dati la verifichi facendo una prova di ripristino e verificando che i dati siano disponibili e leggibili.

Certo il backup dev'essere valido e allora, come dicevo sopra, l'importante è accertarne la validità con un test di ripristino ogni tanto. E lo puoi fare con qualsiasi programma.

Stiamo ripetendo le stesse cose da 4 pagine, ne hai contezza? Capisci che questo metodo di indottrinamento non funziona e non porta da nessuna parte, sopratutto con persone che hanno esperienza?

Qui, com'è evidente, ognuno ha in atto una sua strategia di backup valida per sé, e finché funziona e si trova bene...Non c'è altro da dire o da commentare.

Anche in questo Forum di recente abbiamo avuto un utente con un problema hardware (rilevabile perché stava usando un FS con checksumming): viewtopic.php?p=5354783#p5354783

Sono andato a vedere uno degli esempi portati. Lì semplicemente si tratta di un problema legato al caddy-adattatore difettoso, che risulta dai log (quindi anche il discorso Filesystem c'entra niente, qualsiasi filesystem logga errori ATA), ed è bastato sostituirlo per risolvere. Insomma, un esempio che non dimostra la teoria della corruzione silenziosa "frequente".

[Stealth]

... Cosa c'è di cosi complicato nel configurare un client da GUI? ...

Non c'è niente di complicato in quello, ma parlavo d'altro. Per minimalismo io intendevo quello del sistema, non installo software, non installo gui, non installo niente.
E siccome mi piace aiutare, anche a screditarmi come passatista, ecco la mia filosofia. Io se potessi tornerei a CentOs 5 (anche debian lenny) per quanto erano piccoli e leggeri, sono sistemi che ho amato sopratutto per questo motivo. Ovviamente avevano bugs e difetti come ogni sistema antico o moderno, ma io sono rimasto ai vecchi ingegneri aeronautici, tutto quello che non ci metti non ti farà mai precipitare.

[emanuc]

E indovina un po' come fai a sapere se un backup non è corrotto / è valido??
Certo il backup dev'essere valido e allora, come dicevo sopra, l'importante è accertarne la validità con un test di ripristino ogni tanto. E lo puoi fare con qualsiasi programma.

Buongiorno...

È un controllo che ha qualsiasi software di backup serio. Ed è indipendente dal filesystem!

Stiamo ripetendo le stesse cose da 4 pagine, ne hai contezza? Capisci che questo metodo di indottrinamento non funziona e non porta da nessuna parte, sopratutto con persone che hanno esperienza?
Qui, com'è evidente, ognuno ha in atto una sua strategia di backup valida per sé, e finché funziona e si trova bene...Non c'è altro da dire o da commentare.

Perché ripeti sempre in loop le stesse cose ed ho spiegato che non mi interessa ciò che usi tu, o usano gli altri. Se non ti interessa questa discussione non rispondere. Le persone con esperienza spesso sono troppo sicure di sé per guardare oltre e migliorarsi.

Sono andato a vedere uno degli esempi portati. Lì semplicemente si tratta di un problema legato al caddy-adattatore difettoso, che risulta dai log (quindi anche il discorso Filesystem c'entra niente, qualsiasi filesystem logga errori ATA), ed è bastato sostituirlo per risolvere. Insomma, un esempio che non dimostra la teoria della corruzione silenziosa "frequente".

Continui a non capire e a ignorare ciò che scrivo.

[danilo_g]

E indovina un po' come fai a sapere se un backup non è corrotto / è valido??
Certo il backup dev'essere valido e allora, come dicevo sopra, l'importante è accertarne la validità con un test di ripristino ogni tanto. E lo puoi fare con qualsiasi programma.

Buongiorno...

È un controllo che ha qualsiasi software di backup serio. Ed è indipendente dal filesystem!

Ma non è una prova di ripristino quella, non prova che il backup sia ripristinabile. Se passa, quel controllo prova solo che l'"archivio" di borg|restic|duplicity|etc. è coerente. Ti proponi come esperto della materia, e fai confusione su concetti così importanti...

E comunque io lo faccio una volta a settimana, il check, non una ogni 4 mesi.

Le persone con esperienza spesso sono troppo sicure di sé per guardare oltre e migliorarsi.

C'è anche chi non riesce a guardare oltre il proprio naso.

Continui a non capire e a ignorare ciò che scrivo.

E certo, "sono stata fraintesa".

Mi spiace non sei riuscito a dimostrare che la corruzione silenziosa sia "frequente" in generale, hai addotto esempi non pertinenti, hai citato studi che confermano che è un problema rilevante solo in contesti enterprise.

Perché ripeti sempre in loop le stesse cose ed ho spiegato che non mi interessa ciò che usi tu, o usano gli altri.

Io per lo meno ho usato il plurale, tu accusi solo me che mi ripeto? Adesso mi metto a contarle.
Non ti interessa quello che usano gli altri ma appena uno entra a dire la sua lo critichi.

Sei di una disonestà intellettuale pazzesca.

[emanuc]

Ma non è una prova di ripristino quella, non prova che il backup sia ripristinabile. Se passa, quel controllo prova solo che l'"archivio" di borg|restic|duplicity|etc. è coerente.

Ti proponi come esperto della materia, e fai confusione su concetti così importanti...

Visto che non leggi?

Un buon backup, per essere considerato tale, deve essere versionato, verificato e ottimizzato per risparmiare banda e tempo nei backup successivi. Con Rsync è possibile verificare l'integrità dei dati? Perché è la parte più importante di un backup.

viewtopic.php?p=5370547#p5370547
Ho sempre scritto riguardo all'importanza della verifica dell'integrità dei dati e alla prova di ripristino, due aspetti strettamente legati: se l'archivio è corrotto, non hai la garanzia di poter ripristinare i dati.
Per il resto non meriti risposta.

[danilo_g]

Ma non è una prova di ripristino quella, non prova che il backup sia ripristinabile. Se passa, quel controllo prova solo che l'"archivio" di borg|restic|duplicity|etc. è coerente.

Ti proponi come esperto della materia, e fai confusione su concetti così importanti...

Visto che non leggi?

Un buon backup, per essere considerato tale, deve essere versionato, verificato e ottimizzato per risparmiare banda e tempo nei backup successivi. Con Rsync è possibile verificare l'integrità dei dati? Perché è la parte più importante di un backup.

viewtopic.php?p=5370547#p5370547
Ho sempre scritto riguardo all'importanza della verifica dell'integrità dei dati e alla prova di ripristino, due aspetti strettamente legati: se l'archivio è corrotto, non hai la garanzia di poter ripristinare i dati.
Per il resto non meriti risposta.

La colpa è sempre degli altri che non ti leggono, anche questo l'hai già detto più volte, ma aspè... dov'è che avresti affermato l'importanza della prova di ripristino?! Perché ok la coerenza dell'archivio, ma la prova di ripristino non la vedo menzionata da te neanche una volta. Strano eh? O forse no. Non che mi importi più di tanto a questo punto, ma giusto per verificare...

[emanuc]

Non sono l'unico a dire che "rsync" non è il software migliore per il backup dei dati

Which tools should I use to do the backups ?
rsync/syncthing are just for synchronization, you need btrfs/zfs snapshots if you want to save efficiently a state

proper backup tools like kopia, restic and borg are the correct software specially if your filesystem do not support snapshots, the target disk is an untrusted space like the cloud where is better to use the encryption to access the data.

[danilo_g]

Ho sempre scritto riguardo all'importanza della verifica dell'integrità dei dati e alla prova di ripristino

Non l'hai scritto nemmeno una volta della prova di ripristino, ho controllato. Ti inventi di aver detto cose e poi accusi gli altri di non leggerti.

Ricapitolando:

Se vi accorgete che i backup sono corrotti solo quando vi servono, è ormai troppo tardi.

(citando il video di morro linux)

E indovina un po' come fai a sapere se un backup non è corrotto / è valido??
Prima pagina:

danilo_g ha scritto: ↑
giovedì 8 agosto 2024, 19:57
L'integrità dei dati la verifichi facendo una prova di ripristino e verificando che i dati siano disponibili e leggibili.

danilo_g ha scritto: ↑
venerdì 9 agosto 2024, 21:52
Certo il backup dev'essere valido e allora, come dicevo sopra, l'importante è accertarne la validità con un test di ripristino ogni tanto. E lo puoi fare con qualsiasi programma.

(cose dette anche da morrolinux nel video, ma vabè dettagli)

Allora qui, non pago, cambia discorso, tirando in ballo il controllo dell'integrità dell'archivio:

È un controllo che ha qualsiasi software di backup serio. Ed è indipendente dal filesystem!

Glielo faccio notare:

Ma non è una prova di ripristino quella, non prova che il backup sia ripristinabile. Se passa, quel controllo prova solo che l'"archivio" di borg|restic|duplicity|etc. è coerente.

E allora qui, finiti gli argomenti validi si passa al "non leggi", "non capisci" (e certo, capisce e legge tutto lui):

Visto che non leggi?

Un buon backup, per essere considerato tale, deve essere versionato, verificato e ottimizzato per risparmiare banda e tempo nei backup successivi. Con Rsync è possibile verificare l'integrità dei dati? Perché è la parte più importante di un backup.

viewtopic.php?p=5370547#p5370547

con rsync puoi fare di più. Puoi andare a guardare direttamente nella destinazione che i dati siano leggibili, visto che vengono copiati in chiaro. Non ti serve neanche fare una prova di ripristino. inoltre rsync controlla il cheskum dopo la copia dei file, come dicevo con @korda, ergo sì, un "controllo di integrità" viene fatto in automatico alla fine di ogni copia, su ogni singolo file.

[emanuc]

Ricordo che i dati possono corropersi anche a freddo (per vari motivi), non solo quando si copia/scrive. In questi casi ti serve un controlo di integrità, per confermare che i dati/archivi siano ok.

[korda]

Ricordo che i dati possono corropersi anche a freddo (per vari motivi), non solo quando si copia/scrive. In questi casi ti serve un controlo di integrità, per confermare che i dati/archivi siano ok.

...e una volta che hai conferma della corruzione a freddo che ci puoi fare? Backup o non backup quei dati rimangono irrimediabilmente fottuti su quella risorsa.

Sembra come in quei NAS in cui quando salta un disco la catastrofe è imminente (perché magari si tratta di un difetto di fabbrica e i dischi di quel NAS provengono dallo stesso lotto di produzione, ed è capitato)

A meno che non sia come alcuni controlli SMART, che ti potrebbero anche fornire un campanello d'allarme poco prima che la frittata è fatta.

[emanuc]

Ricordo che i dati possono corropersi anche a freddo (per vari motivi), non solo quando si copia/scrive. In questi casi ti serve un controlo di integrità, per confermare che i dati/archivi siano ok.

...e una volta che hai conferma della corruzione a freddo che ci puoi fare? Backup o non backup quei dati rimangono irrimediabilmente fottuti su quella risorsa.

Che ci fai? Non continui a fare backup su quel dispositivo e perdere ulteriori dati. Controlli la causa e la sistemi.

Sembra come in quei NAS in cui quando salta un disco la catastrofe è imminente (perché magari si tratta di un difetto di fabbrica e i dischi di quel NAS provengono dallo stesso lotto di produzione)

A meno che non sia come alcuni controlli SMART, che ti potrebbero anche fornire un campanello d'allarme poco prima che la frittata è fatta.

Ma i NAS non dovrebbero essere utilizzati come dispositivi di backup, e il RAID non è una soluzione di backup. Inoltre, quando si utilizza un RAID, è consigliabile avere della RAM ECC.
La sicurezza dei dati importanti si basa sul tenerli su più dispositivi (il famoso 3-2-1) per evitare problemi come la perdita totale dei dati a causa della rottura improvvisa di un dispositivo.