Alternative al backup di rete

Nel nostro ambiente abbiamo alcuni server che fanno parte di un gruppo di disponibilità Always On e alcuni che sono autonomi.

Normalmente eseguiamo il backup su una condivisione di rete, ma recentemente abbiamo osservato che, man mano che i database diventano più grandi, il tempo impiegato aumenta, il che rallenta l'intera rete.

Lo script di Ola hallengren viene utilizzato con la compressione e anche la divisione dei file di backup. Eseguo solo backup "completi" giornalieri. I backup stanno andando sull'unità isilon EMC di condivisione di rete.

Non mi trovo mai a mio agio con EMC DD Boost. L'unica alternativa è eseguire un backup locale e quindi copiarlo nella stessa condivisione di rete.

Esiste un modo efficiente diverso da quello sopra?

L'alternativa che hai citato sembra essere la scelta migliore.

Quello che puoi fare è un processo in 2 passaggi:

• Esegui backup nativi del server sql con compressione usando la soluzione di backup di Ola localmente.
• Utilizzare Robocopy per eseguire i trasferimenti su una condivisione di rete. Questo è disaccoppiato e può essere eseguito come attività pianificata di Windows.

In questo modo, i backup sono locali e saranno veloci. Avrai bisogno di più spazio su disco e ovviamente di ridondanza (cosa succede se il disco di backup si guasta - non vuoi perdere tutti i tuoi backup).

In alternativa, come raccomandato da Max Vernon, eseguire Robocopy come passaggio nel processo di backup per assicurarsi che il robocopy si verifichi solo se il backup è stato completato con successo e il più presto possibile al termine del backup. Il backup è allo stesso rischio dei dati, purché rimanga locale.

Inoltre, testa regolarmente i tuoi ripristini poiché, se non riesci a ripristinare un backup, a quale scopo serve!

Inoltre, fai riferimento alla mia risposta all'ottimizzazione di database di grandi dimensioni di backup di SQL

Esistono modi per ottimizzare i backup facendo confusione con diverse manopole come MAXTRANSFERSIZE o BUFFERCOUNT o rimuovendo il file (cosa che hai notato che stai già facendo).

Il problema è che toccando quelle manopole si può comunque verificare il superamento dei limiti della rete e / o dell'archiviazione e non avere alcun impatto reale sui tempi di backup.

Il tuo primo lavoro dovrebbe essere quello di confrontare lo spazio di archiviazione su cui stai eseguendo il backup utilizzando Crystal Disk Mark o DiskSpd . Questo ti darà un'idea di quanto velocemente puoi aspettarti che le scritture siano al meglio.

La prossima cosa che devi testare è leggere dalle unità da cui stai eseguendo il backup. Se si esegue un backup su NUL , è possibile stabilire quanto tempo impiega solo la parte letta del backup, senza doverlo scrivere sul disco.

Con entrambi questi numeri in mente, puoi iniziare a fare scherzi con altre manopole per vedere quali ti avvicinano a loro, indipendentemente dal fatto che la tua destinazione di backup sia locale o in rete.

Un paio di potenziali soluzioni:

1. Passare dal backup solo completo a un backup completo settimanale e il differenziale notturno può essere una soluzione semplice.

2. Esistono numerosi parametri relativi alle prestazioni che puoi modificare negli script di Ola, potresti essere in grado di modificarli per ottenere le prestazioni che desideri:

   • BlockSize
     Specifica la dimensione del blocco fisica in byte.

     L'opzione BlockSize in DatabaseBackup utilizza l' BLOCKSIZEopzione nel comando BACKUP di SQL Server.

   • BufferCount
     Specificare il numero di buffer I / O da utilizzare per l'operazione di backup.

     L'opzione BufferCount in DatabaseBackup utilizza l' BUFFERCOUNTopzione nel BACKUPcomando SQL Server .

   • MaxTransferSize Specifica l'unità di trasferimento più grande, in byte, da utilizzare tra SQL Server e il supporto di backup.

     L'opzione MaxTransferSize in DatabaseBackup utilizza l' MAXTRANSFERSIZEopzione nel BACKUPcomando SQL Server .

Esistono molte opzioni possibili, ma man mano che i database diventano più grandi e i backup completi impiegano più tempo, probabilmente dovrai incorporare backup differenziali , se non lo hai già:

La creazione di un backup differenziale può essere molto veloce rispetto alla creazione di un backup completo. Un backup differenziale registra solo i dati che sono stati modificati da quando si basa il backup completo sul backup differenziale. Ciò facilita l'esecuzione di frequenti backup dei dati, che riducono il rischio di perdita dei dati.

La mia comprensione è che gli script di Ola possono anche essere impostati per decidere tra un backup completo o differenziale in base alla quantità di modifiche nel database utilizzando il parametro ModificationLevel .

Usiamo EMC DD Boost e sei il benvenuto alla tua opinione, ma abbiamo scoperto, grazie ai metodi di de-duplicazione sul lato client che utilizza, che i backup completi anche dei database multi-TB possono essere molto veloci, al punto che non dobbiamo preoccuparci dei backup differenziali di SQL Server. In effetti, utilizzando EMC DD si sta facendo backup differenziali, non solo in SQL Server. L'uso di più file di destinazione migliora anche notevolmente la velocità, anche su DDBoost.