È sicuro usare un HDD mentre rsync è in esecuzione?


27

Ho in programma di eseguire il backup dei miei grandi HDD rsynce prevedo che ci vorranno alcuni giorni. È sicuro usare l'HDD originale (aggiungendo file) mentre rsyncsta funzionando? O è meglio lasciare intatti gli HDD fino al rsynctermine?


1
Nota che "usare" può essere semplice come avere un browser aperto senza fare nulla. I browser tendono a scrivere molte cose casuali nelle loro directory dei dati. Nel peggiore dei casi, quello che ottieni è un backup incoerente, ad esempio quando ripristini, potresti non essere in grado di ripristinare le tue schede, i tuoi segnalibri potrebbero essere spariti (perché il database è danneggiato) o qualcosa in quell'ordine di grandezza.
Jonas Schäfer,

Se si dispone di molti dati per il backup, è possibile prendere in considerazione la suddivisione del backup in parti più piccole (sotto-alberi). Quindi, solo la parte attualmente in esecuzione deve essere mantenuta il più statica possibile - e puoi vedere quale parte sta seguendo l'avanzamento del tuo script (con un registro, ecc.). Dal momento che non si tratta di un grosso backup, alcuni pezzi potrebbero essere poco sincronizzati con gli altri, ma se si esegue un grosso backup su un sistema live, ciò accadrà comunque.
Joe,

Risposte:


34

Come altri hanno già sottolineato, è sicuro leggere dal disco di origine o utilizzare il disco di destinazione all'esterno della directory di destinazione, mentre rsync è in esecuzione. È anche sicuro leggere nella directory di destinazione, specialmente se la directory di destinazione viene popolata esclusivamente dall'esecuzione di rsync.

Ciò che non è generalmente sicuro è scrivere nella directory dei sorgenti mentre rsync è in esecuzione. "Scrive" è tutto ciò che modifica il contenuto della directory di origine o di qualsiasi sua sottodirectory, quindi include aggiornamenti di file, eliminazioni, creazione, ecc.

In questo modo non si romperà nulla, ma la modifica potrebbe o meno essere effettivamente raccolta da rsync per la copia nella posizione di destinazione. Ciò dipende dal tipo di modifica, dal fatto che rsync abbia già scansionato quella particolare directory e che rsync abbia già copiato il file o la directory in questione.

Tuttavia, c'è un modo semplice per aggirare questo: una volta terminato, esegui di nuovo rsync, con gli stessi parametri. (A meno che tu non abbia qualche parametro funky di eliminazione; in tal caso, fai un po 'più attenzione.) In questo modo, eseguirà di nuovo la scansione della fonte e trasferirà eventuali differenze che non sono state rilevate durante l'esecuzione originale.

La seconda esecuzione dovrebbe trasferire solo le differenze che si sono verificate durante la precedente esecuzione rsync e come tale completerà molto più velocemente. Pertanto, puoi sentirti libero di usare il computer normalmente durante la prima esecuzione, ma dovresti evitare il più possibile di apportare modifiche alla sorgente durante la seconda esecuzione. Se è possibile, si consiglia vivamente di reinstallare il file system di origine in sola lettura prima di avviare la seconda esecuzione di rsync. (Qualcosa del genere mount -o ro,remount /media/sourcedovrebbe fare.)


7
Si può anche fare una terza corsa dopo una seconda corsa: potrebbe volerci anche meno tempo ... ;-)
gerlos

5
@gerlos Sembra emergere uno schema. Sembra quasi che si possa semplicemente continuare a eseguire il comando rsync alla fine di ogni sessione di utilizzo, e in pochi giorni sarebbe fatto in pochissimo tempo.
Monty Harder,

5
@gerlos Se rimontate di sola lettura prima di eseguire rsync la seconda volta, ciò non sarà necessario e il backup sarà quasi sempre coerente, riducendo al minimo il tempo durante il quale non è possibile scrivere nel file system di origine.
un CVn

1
@gerlos A parte questo, è per questo che ho una voce molto simile @reboot root find / -print &>/dev/nullnel mio crontab di sistema, per popolare la cache. (La voce effettiva è più complessa per tenere conto di alcuni casi speciali sul mio sistema particolare.) Utilizza un po 'di RAM e un po' di tempo di blocco della parete subito dopo l'avvio per migliorare la scansione dell'albero delle directory un po 'IME.
un CVn

1
@ MichaelKjörling: idea interessante per memorizzare nella cache la gerarchia. Ma forse dovresti eseguire updatedb(costruendo il database di Locate) o slocate -u(lo stesso, se hai slocate) invece? In questo modo continui a memorizzare nella cache la gerarchia ma crei anche i database di Locate o Slocate, permettendoti di usare quei comandi per trovare rapidamente molti file?
Olivier Dulac,

22

Questo dipende dal sistema di backup che si utilizza, ma in generale è una cattiva idea modificare il contenuto di un dispositivo durante il backup. Tuttavia, puoi leggere il suo contenuto; è un'operazione sicura, anche se rallenterà il processo.

Nel tuo caso, rsynccreerà un elenco di file e quindi avvierà il backup. Pertanto, qualsiasi file aggiunto all'HDD di origine dopo l'avvio del backup non verrà copiato.

Quello che faccio non è usare affatto un dispositivo durante un backup. Questo è il modo più sicuro per ottenere un backup rapido e coerente.


14
Di solito lo lascio correre e poi eseguo una seconda esecuzione rsyncche termina in pochi secondi perché verranno copiati solo i file che ho modificato durante la corsa. Tutto sarà nella cache, quindi è molto più facile astenersi dalle modifiche durante quel periodo.
Martin Ueding,

15

È sicuro leggere i dati dalle aree di origine mentre rsyncè in funzione, ma se aggiorni qualcosa la copia che rsynccrea / aggiorna rischia di essere incoerente:

  1. Se aggiorni un file che rsync ha già scansionato, non vedrà l'aggiornamento fino a una futura esecuzione. Se aggiorni un file che deve ancora scansionare, la modifica verrà rispettata nella destinazione. Se aggiorni i file che hanno entrambi e non sono stati scansionati, finirai con un mix di versioni vecchie e nuove nella destinazione.

  2. Se aggiungi un file a una directory che è già stata scansionata, questa volta verrà perso dalla copia di destinazione. Se rimuovi un file da una directory che è già stata scansionata, questa volta verrà lasciato nella copia di destinazione. A seconda di come si richiama, rsyncl'intero albero può essere scansionato all'inizio o può essere scansionato in modo incrementale quando si verifica il processo di sincronizzazione.

  3. In alcune circostanze rsyncvedrà l'incoerenza e ti avvertirà. Se si rimuove un file o una sottodirectory da una directory che è già stata scansionata da sola ma non è stata sottoposta a scansione il suo contenuto, verrà visualizzato un messaggio di errore relativo alla mancanza dell'oggetto. In circostanze simili, a volte (se le dimensioni e / o il timestamp sono cambiati) può anche avvisare che i file cambiano durante la scansione.

Per alcuni backup questa incoerenza potrebbe non essere un grosso problema, ma per la maggior parte lo sarà, quindi si consiglia di non provare a sincronizzare una fonte che cambia attivamente.

Se si utilizza LVM per suddividere in porzioni il proprio sistema di archiviazione, è possibile utilizzare un'istantanea temporanea per eseguire un backup temporizzato. Ciò richiede che si disponga di spazio sufficiente sul gruppo di volumi per creare un volume di istantanea abbastanza grande da contenere tutte le modifiche che si verificheranno nella durata necessaria per l'istantanea. Consultare la documentazione LVM (o uno dei tanti esempi online: cercare "Backup snapshot LVM" o simile) per maggiori dettagli.

Anche senza LVM alcuni filesystem supportano gli snapshot stessi, quindi potresti voler esaminare anche questa opzione.

Se si desidera eseguire il backup di grandi volumi attivi senza lunghi tempi di inattività e non è possibile utilizzare gli snapshot, potrebbe essere sufficiente eseguire la scansione "live" fino al completamento, quindi interrompere l'accesso al volume ed eseguire un altro processo rsync che potrebbe richiedere molto meno tempo (se molto poco è cambiato, scansionerà solo l'albero delle directory e poi i pochi file aggiornati). In questo modo la durata in cui dovresti evitare le modifiche potrebbe essere molto più breve.


Mi piace molto la tua risposta perché vai nei dettagli su cosa succede se i file vengono modificati. Non solo fornisci un'alternativa, ma risolvi anche le incoerenze che può causare (mancanza di un aggiornamento, avviso su un file mancante, ecc.). Nella mia situazione, usare rsync per eseguire il seeding di un lungo backup e quindi aggiornarlo giorni dopo non è un grosso problema, e sembra anche la situazione del PO. Non sembra che stia richiedendo un backup a livello aziendale la prima volta, ma vuole solo usare il computer nel frattempo. Dico solo eseguire rsync una seconda volta per catturare i file aggiornati.
ibennetch,

11
  • L'HDD di origine può leggere qualsiasi cosa mentre rsync.

  • L'HDD di origine può scrivere qualsiasi contenuto non correlato al contenuto rsync.

  • L'HDD di destinazione può leggere qualsiasi cosa mentre rsync.

  • L'HDD di destinazione può scrivere qualsiasi cosa durante la sincronizzazione con la condizione di avere spazio sufficiente riservato per il contenuto sincronizzato.

Naturalmente, in ogni caso, ci sarà una riduzione delle prestazioni.


0

Tutte le risposte attuali parlano della sicurezza dei dati in termini di coerenza e presuppongono hardware perfetto.

Un'altra cosa da considerare è la sicurezza hardware stessa. Se si dispone di dischi rigidi di cui non è stato eseguito il backup che potrebbe essere sul punto di guastarsi (potresti non saperlo ancora) e stai effettuando un backup completo iniziale , non utilizzarlo. Non montarlo nemmeno se i dati sono critici. È possibile utilizzare uno strumento come ddclonare il disco come dispositivo a blocchi. Quello che non vuoi che la testa del disco cerchi e possibilmente scriva mentre stai provando a fare un backup. Inoltre, dddovrebbe essere più veloce per il backup iniziale poiché copia semplicemente i bit in ordine (se l'unità non è per lo più piena suppongo che rsync vincerebbe anche nel caso iniziale).

Per i successivi backup incrementali rsync è un'ottima scelta e sono d'accordo con le altre risposte al 100%.


1
Se il supporto è marginale o anche potenzialmente marginale, ddnon è la scelta migliore. Usa ddrescueinvece; gestisce molto meglio i guasti parziali. Ma quella non era una considerazione nella domanda originale.
un CVn

@ MichaelKjörling Questo è un buon punto.
Zak,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.