Backup di SQL DB più frequentemente


10

Attualmente ho un'attività pianificata che si avvia ogni notte alle 2 del mattino che chiama SQLCMD.exe e gli passa uno script .sql per l'esecuzione per il backup (mostrato di seguito). Siamo una società piuttosto piccola con esigenze crescenti a causa della grande crescita sul lato commerciale. Perdere 1 giorno di dati a questo punto costerebbe decine di migliaia di dollari contro un paio di centinaia questa volta l'anno scorso. Fino a quando non riesco a migrare questa piattaforma DB su una diversa soluzione in cui si verifica il mirroring dei dati con ridondanza maggiore come SQL Azure, qual è la cosa migliore che posso fare per ottenere backup più frequenti? Questo script di seguito forza il DB a essere offline? Posso eseguire questo script con gli utenti che interagiscono con il DB?

USE CompanyCRM;
GO
BACKUP DATABASE CompanyCRM
TO DISK = 'D:\CRMBackups\CompanyCRMCRM.Bak'
   WITH FORMAT,
      MEDIANAME = 'CompanyCRM_Backup',
      NAME = 'Full Backup of CompanyCRM';
GO

Aggiornare

Caspita, ovviamente una community DBA molto più dedicata qui che su SO. Grazie per il feedback finora. L'unica cosa che manca sono i "come". Ho mostrato il comando SQL sopra che sto usando per fare backup giornalieri, ma gli esempi di backup del registro incrementale sono MIA. Questo non è un DB di grandi dimensioni, attualmente funziona su SQLExpress. Quando dico HA o SQL Azure, mi riferisco in particolare all'architettura in atto che non abbiamo come piccola impresa. Questa istanza è attualmente in esecuzione sul nostro SOLO server. Se quel server si arresta in modo anomalo, il nostro tempo di recupero diventa un punto critico. Questo è il motivo per cui SQL Azure diventa attraente.


modificato la mia risposta al tuo aggiornamento, spero che sia di aiuto

Risposte:


5

MODIFICA, dal tuo aggiornamento

Come hai detto che puoi perdere 1 giorno di dati, metterei i database in modalità di recupero SEMPLICE. È quindi possibile fare un PIENO ogni mattina e / o sera. Se volevi coprirti durante il giorno, potresti passare attraverso un backup differenziale del database, uno di quelli per ogni evenienza. Ciò acquisirà tutte le modifiche apportate dal backup completo. Se conosco un lasso di tempo in cui sta avvenendo un sacco di input, potrei lanciare questo tipo di backup dopo che è stato completato. Può far risparmiare tempo alle persone nel recupero, in modo che non debbano fare ulteriori dati.

Poiché questo è il tuo unico server, mi assicurerei di eseguire DBCC CHECKDB contro i database. I backup non fanno nulla di buono quando scopri che sono corrotti (penso che qualcuno abbia menzionato anche questo). È possibile trovare alcuni script là fuori per impostare un'attività pianificata per controllare SQL ERRORLOG affinché il messaggio DBCC rilevi eventuali errori. SQL Server non ti avviserà in modo nativo degli errori restituiti dai messaggi DBCC, quindi a meno che non controlli manualmente ogni volta che uno script che lo fa può aiutare.

Il comando di backup differenziale:


USE CompanyCRM; 
GO 
BACKUP DATABASE CompanyCRM 
   TO DISK = 'D:\CRMBackups\CompanyCRMCRM_diff.Bak'    
WITH FORMAT, DIFFERENTIAL,
MEDIANAME = 'CompanyCRM_Backup',       
NAME = 'Full Backup of CompanyCRM'; 
GO 

1
@Shawn: OP ha detto che "La perdita di 1 giorno di dati a questo punto costerebbe decine di migliaia di dollari contro duecento questa volta l'anno scorso", dove ha detto che potrebbe perdere 1 giorno di dati ?!
Marian,

8
  • I backup in SQL Server non disturbano. Cioè il database rimane operativo. Leggi la documentazione
  • Esegui un backup completo ogni giorno, seguito dai backup LOG spediti (copiati) (di nuovo, la documentazione ha ... documentazione) più regolarmente - come ogni 15 minuti circa.

4
Penso che il backup sia qualcosa di cui non hai bisogno di un howto, ma una lettura completa della documentazione - è fondamentale per il business ed è - seriamente - importante. Non cucinare lo stile delle uova. Assumi un professionista.
TomTom,

2
Peccato che non posso votare le risposte su questo sito ...
RSolberg,

1
@RSolberg: la risposta di TomTom è valida, insieme agli altri consigli che hai già ricevuto. Suggerirei che non ti aspetti che nessuno dei rispondenti ti mostri davvero la sintassi di base del backup. Anche se vedo che Shawn è stato così gentile da farlo. Progettare una strategia di BACKUP non è sufficiente. Devi abbinarlo a una strategia di RIPRISTINO in modo che tutto sia valido quando ne hai bisogno.
Marian,

2
@RSolberg: scusa per averti fatto incazzare. Questo non è previsto. Ma in che modo questa community non ha aiutato? Hai risposte valide e valide (e commenti). Il tuo messaggio era: "Perdere 1 giorno di dati a questo punto costerebbe decine di migliaia di dollari contro un paio di centinaia questa volta l'anno scorso." Quindi hai bisogno di una solida strategia di backup e ripristino in modo da non arrivarci. Una solida strategia deriva dal conoscere molto bene le basi. Che derivano dalla lettura e dalla comprensione del manuale. Scusa se hai capito qualcos'altro!
Marian,

2
Sono d'accordo con @RSolberg sul fatto che la maggior parte delle risposte qui non mostrano "come" farlo, ma anche perché la domanda mancava di qualche dettaglio "cosa" non hai capito Russell. Devi dirci qualcosa in più su ciò di cui hai bisogno, ma sono d'accordo con te sul fatto che il sito qui non dovrebbe riguardare "RTFM n00b". Inoltre, come hai sottolineato, hai 10k su Stack Overflow , quindi sicuramente capisci i commenti segnalanti che sono scortesi o distruttivi. In futuro, dovresti farlo prima, piuttosto che bollire per la frustrazione.
jcolebrand

6

La prima cosa che devi fare è capire quanti dati puoi permetterti di perdere. Fino ad allora non avrai idea di quanto spesso eseguire il backup del database. Questo non è un numero che dovresti trovare. Questo è qualcosa che l'azienda (o il CEO di un'azienda più piccola) dovrebbe decidere. Il primo numero con cui torneranno è 0 minuti. Il che può essere fatto, ma sarà molto costoso da fare. In realtà la quantità minima di dati per cui è possibile eseguire i backup è circa ogni 2 minuti. Se la quantità di dati che cambia nel sistema è abbastanza piccola, è possibile eseguire backup ogni minuto.

Per eseguire i backup del registro delle transazioni, che è ciò che devi fare, devi mettere il database in modalità di recupero COMPLETO.

Se puoi permetterti di perdere 5 minuti di dati, probabilmente vorrai fare backup completi ogni giorno e backup del registro delle transazioni ogni 5 minuti. Se perdi 15 minuti di dati, ti consigliamo di eseguire backup completi e backup del registro delle transazioni ogni 15 minuti.

Un'altra opzione sarebbe quella di eseguire backup settimanali completi, backup differenziali giornalieri e backup del registro delle transazioni ogni x minuti, come ho già detto sopra.

Tenere presente che più spesso è necessario eseguire backup, più file sarà necessario ripristinare in caso di errore del database o cancellazione dei dati. Potrebbe avere senso eseguire backup differenziali per tutto il giorno per ridurre il tempo necessario per ripristinare il database.

Tutti i backup che utilizzano il database BACKUP e l'istruzione BACKUP LOG vengono eseguiti online e non impediscono agli utenti di accedere al database.


In realtà sono abbastanza in grado di valutare quanti dati possiamo perdere. Le piccole imprese richiedono alle persone di indossare molti cappelli, dal momento che il CIO tendo a essere coinvolto quotidianamente nelle decisioni aziendali.
RSolberg,

1
Ciò renderà la discussione molto più breve allora.
mrdenny,

3

Supponiamo che tu abbia uno scenario commerciale comune con il tuo tempo più occupato: dalle 9 alle 17 dal lunedì al venerdì. Quindi suggerirei: backup completo alla domenica sera. Backup differenziali alle 8:00, alle 18:00 e all'01: 00 (per ridurre i tempi di recupero). Registra i backup ogni ora o in base alle esigenze della tua azienda.

A seconda del periodo di conservazione, è necessario disporre di un processo di pulizia automatica per cancellare i vecchi file di backup. Tutti questi possono essere creati utilizzando piani di manutenzione SQL. Dai un'occhiata a questo link per SQL 2005 .

È necessario archiviare i backup su una qualche forma di disco ridondante (con mirroring) oppure utilizzare i nastri per l'archiviazione offsite. Gli utenti possono continuare a lavorare sul sistema durante l'esecuzione dei backup.


2

Non farei un backup completo ogni notte. Se si tratta di un database di grandi dimensioni, ciò potrebbe richiedere molto tempo, per non parlare del fatto che occupa molto spazio sul supporto. Eseguire un backup completo ogni fine settimana e un backup differenziale ogni notte. Quindi eseguire un backup del registro delle transazioni (presupponendo che il database sia in pieno recupero) ogni ora o ogni mezz'ora, ma assicurarsi che questi file .bak e .trn risiedano su un disco separato in caso di guasto del disco.


I tag sono stati persi, questo non è un enorme database. Attualmente è in esecuzione su un'istanza SQLExpress.
RSolberg,

1
Decine di migliaia di dollari, in esecuzione su Express? Interessante!
Andrei Rînea,

Non proprio. A seconda di ciò che memorizzi (nessun testo, nessun file binario), ovvero 10 gigabyte di dati. È possibile eseguire un sistema di contabilità per una grande azienda - SERIAMENTE grande società - in 10 gigabyte. Un negozio online con 100.000 ordini al giorno può facilmente fare la parte del negozio in 10 gigabyte.
TomTom

1

Puoi sincronizzare cloud la cartella dei backup di notte per ottenere l'archiviazione fuori sede? Dal momento che sono abbastanza sicuro che questo sia per un'azienda sanitaria, ce ne sono abbastanza sicuri per la conformità HiPA? O forse semplicemente li crittografano?

Lo script inserisce almeno una copia del backup su una condivisione di rete? In questo modo se la scatola fisica esplode ...


Sì a tutto quanto sopra. Effettivamente eseguiamo il backup su un'unità di rete con mirroring e copiamo i dati da quell'ambiente in un data center sicuro.
RSolberg,
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.