Come posso eseguire il backup di un repository SVN da 13 GB? Il dump è 100+ GB

Question

Ho una dozzina di repository che sul file system hanno dimensioni da 1 GB a 10 GB e ho bisogno di configurare backup automatici per tutti (i nostri vecchi script di backup si sono persi quando un computer andato giù) con le nostre macchine XP a 64 bit.

Dopo aver letto this question sul modo migliore per eseguire il backup dei repository SVN, ho iniziato a scaricare il repository più grande che abbiamo, che è di circa 13 GB. Questo comando è in esecuzione da ~ 2.5 ore e attualmente sta scaricando la revisione ~ 200 su 300+.

svnadmin --deltas \\path\to\repo\folder > \\path\to\backup\folder\dump.svn 

Il file di dump è di oltre 100 GB e il conteggio. So che posso 7-zip questo pollone, ma 100 GB ?! ... o_O

I repository contengono una grande quantità di dati binari, che potrebbero essere parte del problema, ma al momento, passare a un sistema di controllo di versione più efficiente (supponendo che ce ne sia uno) non è realistico; SVN è una parte della vita qui.

Ho preso in considerazione l'utilizzo di hotcopy, che occupa molto meno spazio, ma ho provato a utilizzare uno dei nostri vecchi backup hotcopy, e subversion 1.7 non è riuscito a trovare un gruppo di file necessari. Sembra che dovrei installare la versione di SVN che originariamente hotcopy-ed il repository e scaricare quel repository per inserirlo in un SVN più recente. Questa affermazione sembra verificare il problema che sto avendo con hotcopy: http://svn.haxx.se/users/archive-2005-05/0842.shtml

Mi sento come se avessi solo ottenuto mancare qualcosa. Forse c'è qualche bandiera per discarica che magicamente rende la discarica 1/5 delle dimensioni ...

Ho altre opzioni?

---

AGGIORNAMENTO: l'ultima revisione, # 327, è stata appena scaricata. La dimensione finale del file di dump è 127 GB. Quello è da un repo 13,5 GB. Probabilmente ho combinato all'incirca 3 volte in tutti i miei repository.

Answer 1

Per il backup giornaliero, direi che non è necessario eseguire uno svnadmin dump. Vorrei usare il metodo dump se stessimo per trasferire il repository su un nuovo server che potrebbe essere in esecuzione su una versione SVN e OS diversi in quanto è il modo più portatile per scaricare il repository, ma non è molto efficiente in termini di spazio.

Si consiglia di utilizzare i metodi hotcopy riferiti a tale collegamento. Ciò garantirà che lo stato del filesystem sia coerente e copierà anche i file di configurazione e gli script di hook (incidentalmente il dump svnadmin non li copia, così finirai con un backup incompleto). Perché è solo una copia diretta del repository, ha le stesse dimensioni, quindi il backup dovrebbe essere molto più gestibile.

In caso di emergenza, se è necessario ripristinare un backup eseguito da un hotcopy, tutto ciò di cui si ha bisogno è una macchina con la stessa versione principale di SVN (ad esempio 1.6 o 1.7) e per essere sicuri, lo stesso sistema operativo. Si dovrebbe essere quindi in grado di utilizzare direttamente questo repository oppure è possibile eseguire un svnadmin dump a questo punto per il trasferimento su un nuovo server.

EDIT: confronto tra svnsync e hotcopy:

aspetti comuni:

• si occupa in modo sicuro con i repository scrive durante il backup
• Dimensione di backup = dimensioni del repository

Vantaggi di hotcopy:

• più facile da configurare
• Esegue il backup ganci e file di configurazione

Vantaggi di svnsync:

• consente a Backup su una macchina diversa
• Solo nuove revisioni dall'ultima sincronizzazione sono scritti in modo che il la sincronizzazione è molto veloce e ciò significa che è possibile eseguire backup incrementali molto compatti

Answer 2

Grazie a i suggerimenti di bahrep e the_mandrill, ho deciso di andare con svnsync per questi repository. Sono stato in grado di installarlo abbastanza facilmente, e dato che non abbiamo ganci o file di configurazione, non c'è altro da fare. A causa dei problemi che ho avuto con hotcopy (grazie a the_mandrill per aver proposto una soluzione a questi problemi) ho deciso che svnsync sarebbe stata la soluzione più semplice per noi.

Oltre a quanto the_mandrill rilevare, svnsync ha altri vantaggi:

• Nel caso in cui il repository principale va giù, gli utenti possono scaricare dal repository di backup finché hanno il collegamento.
• I backup sono completamente controllati in versione. Il mio capo mi ha chiesto di fare backup notturni, ma di conservare solo quei backup di una settimana. Per farlo con hotcopy, dovrei scrivere uno script. Con svnsync, non devo preoccuparmi di nulla di tutto ciò.

Per impostare svnsync, ho dovuto completare i seguenti passaggi. Scusa eventuali errori di battitura. Tutti i nostri repository sono ospitati utilizzando VisualSVN Server.

1. Creare un nuovo repository vuoto:

   svnadmin create \\computerB\C$\repositories\mirror

2. creare il file, \mirror\hooks\pre-revprop-change.bat.E 'solo il contenuto è presente una sola riga:

   exit 0

3. inizializzare la sincronizzazione

   svnsync init https://computerB.domain.net/svn/mirror https://computerA.domain.net/svn/repo

4. sincronizzare i due pronti contro termine

   svnsync synchronize https://computerB.domain.net/svn/mirror https://computerA.domain.net/svn/repo

Answer 3

A partire da VisualSVN Server 3.6, è possibile utilizzare il cmdlet di PowerShell Backup-SvnRepository per eseguire un backup del repository Subversion. Per ripristinare il repository dal backup, utilizzare il cmdlet Restore-SvnRepository.

Inoltre, l'Enterprise Edition del server offre un scheduled backup feature. Il backup programmato integrato supports several backup types including incremental backups efficiente in termini di spazio di archiviazione e tempo richiesto per il backup.