Qual è la tua best practice Modello di recupero per database di SharePoint

Paul Randal ha posto alcune domande davvero interessanti sulle migliori pratiche per i database SQL di SharePoint. Oggi, mentre aiutava un cliente a mantenere l'installazione di SharePoint, mi ha posto una domanda sul miglior modello di recupero SQL per il database di SharePoint.

È mia pratica (non sono un amministratore DB :)))) utilizzare il modello di recupero semplice. Se si esegue il backup dei database di SharePoint su base regolare e si dispone anche di un backup di strumenti di terze parti su base a livello di articolo, non è necessario conservare gli interi registri.

Mi sto perdendo qualcosa qui? È questo l'approccio giusto? Hai mai usato il registro DB di SharePoint per recuperare i tuoi dati?

Dipende interamente dalla quantità di dati che sei disposto a perdere rispetto alla quantità di sforzo amministrativo richiesto. Se stai usando il semplice modello di recupero e fai i backup una volta alla settimana la domenica ... se hai un incidente alle 11:59 di sabato, allora hai perso una settimana di lavoro. L'aumento della frequenza dei backup (o l'assunzione di differenziali) ridurrà la quantità di perdita di dati.

Eseguendo backup completi / differenziali regolari ma utilizzando il modello di recupero completo con i registri delle transazioni, è possibile ripristinare l'ultimo backup e quindi riprodurre i registri delle transazioni in un punto immediatamente prima dell'incidente e perdere pochi o nessun dato.

Parlando di Paul Randal ... ha appena scritto un grande articolo su questo argomento per la rivista TechNet questo mese :) http://technet.microsoft.com/en-us/magazine/dd822915.aspx

Il backup del solo database NON otterrà tutte le informazioni sul tuo sharepoint. Sicuramente otterrà tutto nel database, ma tutte le personalizzazioni e l'aspetto andranno persi. Questo potrebbe non interessarti come amministratore, ma ti assicuro che i tuoi utenti saranno infelici.

Le opzioni includono ottenere un agente di backup in grado di leggere il database sharepoint per il proprio software di backup o fare alcuni backup con script che catturano le informazioni di configurazione e mettere al sicuro sia il backup del database SQL che il backup del database SQL.

http://technet.microsoft.com/en-us/library/cc288330.aspx Ha alcune informazioni.

PROVA i tuoi backup. Ripristinali. Guarda cosa cambia, cosa funziona e cosa no. Il nostro primo ripristino non è stato buono come avrebbe potuto essere. Fortunatamente per noi era solo una parte del processo di creazione di un server di prova che era un duplicato del nostro server di produzione, piuttosto che cercare di recuperare dati persi o distrutti.

Modificato per pertinenza Dopo averlo letto di nuovo mi sono reso conto di essermi distratto e di aver perso il punto di risposta della mia risposta. Se si eseguono backup completi con la registrazione delle transazioni, è possibile tornare a punti molto più precisi nel tempo. Ciò richiede più abilità come DBA ma non è poi così difficile. Se non hai un sacco di aggiornamenti e perdere un'intera giornata di lavoro non è la fine del mondo, allora probabilmente stai bene. Altre opzioni includono l'esecuzione del backup semplice più spesso. Dire Mezzanotte, 10:00, 14:00, 18:00 o qualsiasi altra cosa funzioni per il ciclo di lavoro delle organizzazioni. Ciò consumerà più disco, ma ridurrà i rischi di perdita di dati. Come per tutti i backup, è un equilibrio tra ciò che gli utenti tollereranno e ciò che gli amministratori possono fornire.

Sharepoint deve essere trattato come un database SQL perché È un database SQL, quindi prendi tutte le normali precauzioni di installazione SQL nell'impostazione del negozio. Per quanto riguarda i backup, non dovresti solo eseguire il backup dei database regolarmente, ma devi eseguire il backup del tuo 12 alveare che contiene tutte le tue informazioni SP.

Dai un'occhiata a questa discussione per maggiori informazioni: http://social.technet.microsoft.com/Forums/en-US/sharepointgeneral/thread/102c5c71-38a3-4360-b5cb-9b8b7c07bfea

Ci sono alcuni database che sono impostati in modalità semplice e pronti all'uso. Il database di ricerca, ad esempio. I dati di ricerca sono memorizzati in due posizioni: un database e il file indice sul file system del server. È necessario che entrambi forniscano query di ricerca ed entrambi siano stati sottoposti a backup simultaneamente affinché qualsiasi versione ripristinata funzioni. Poiché le probabilità sono molto, molto basse, la maggior parte delle persone opterebbe semplicemente per ridisegnare il proprio contenuto e rigenerare l'indice di ricerca.

In questo caso, la modalità semplice funzionerebbe perfettamente.