Come implementare i backup differenziali senza conservare copie dei file originali su disco?

Question

Come implementare i backup differenziali senza conservare copie dei file originali su disco?

#1 da (3 voti)

0

Sono responsabile della progettazione e dello sviluppo di un'applicazione di backup cloud. Attualmente stiamo usando xDelta per fare il backup differenziale in modo che vengano caricate solo le parti modificate dei file. Questo riduce i costi sia per noi che per l'utente. Un problema che stiamo affrontando con questo approccio è che per fare un backup differenziale il file modificato deve essere confrontato con il file originale. Per risolvere questo abbiamo optato per una soluzione rapida e cioè per memorizzare i file originali sul computer degli utenti per un rapido riferimento.

Ora questa soluzione funziona brillantemente per utenti desktop / home in cui le dimensioni dei file sono relativamente piccole. Il problema sorge quando si dice che un amministratore del server tenta di eseguire il backup di un database SQL, ad esempio che ha una dimensione di 100 GB. Anche se al momento memorizziamo il file sul disco, questo non è sicuramente apprezzato dagli amministratori del server poiché stiamo riempiendo i loro dischi con i file memorizzati nella cache.

Mi chiedo se ci sia un altro approccio per fare backup differenziali senza la necessità di avere i file originali sul disco in modo permanente.

design difference backups

posta Zaid Amir 01.04.2014 - 10:28

fonte

1 risposta

Leggi altre domande sui tag design difference backups

Memorizzazione di token durante la fase di lexing Riconoscimento di parole in una stringa senza spazi o segni di punteggiatura

score 3 · Answer 1

È molto importante quando si implementa una soluzione di backup che l'attenzione non è sul processo di backup, ma sul processo di ripristino. È la possibilità di riportare i dati in un ambiente di lavoro che conta, non il riempimento di dischi rigidi e nastri LTO.

Da questo punto di vista, quando esegui il backup di database, directory del SO, MS Exchange ecc., l'approccio 'afferrare i file' è solo una soluzione per i problemi successivi.

Con i database se si esegue una copia byte per byte dei file di lavoro su un database in uso, è probabile che il risultato sia un database corrotto quando si tenta il ripristino. Se si esegue una copia shadow dei file di lavoro (e si ottiene di ottenere un set coerente con la creazione dell'ombra che si verifica simultaneamente su tutti i file di dati per quel database), si fornisce un'opzione di ripristino equivalente al ripristino dopo un evento di spegnimento. Nella maggior parte dei casi il software del database si ripristinerà, ma si avrà comunque un tasso di errore dell'1-10%.

L'unico modo sicuro per eseguire il backup del database è di attivare un backup del database nel software del database. Esistono API specifiche per l'attivazione, che possono essere eseguite come parte del processo di backup che variano da un database all'altro, ma genereranno un file di backup che consentirà di ricreare nuovamente il database. Questi sono i dati che devono essere salvati. Saranno nuovi dati ogni volta quindi non ha molto senso fare analisi differenziali.

Detto questo, le aziende che utilizzano i tuoi servizi per questo, probabilmente andrebbero meglio con una SAN che fornisce dischi ai server di virtualizzazione come iSCSI e implementando la loro infrastruttura in questo modo. Per quanto riguarda il ripristino, il tasso di successo del ripristino di un ambiente operativo virtuale è molto più elevato rispetto al bare metal, considerando che è molto probabile che venga ripristinato su hardware diverso con esigenze diverse del driver di periferica.