Mantenimento di backup (parziali) piccoli quando si utilizza FILESTREAM di SQL Server

Ho un database con quasi 1 TB di FILESTREAMdati di cui non ho bisogno di eseguire il backup (se i dati fossero eliminati verrebbero ricreati automaticamente in un paio d'ore, quindi non è importante). La maggior parte dei dati viene cambiata ogni due giorni, quindi i backup differenziali non aiuterebbero davvero a ridurre le dimensioni.

Ho fatto in modo che i backup funzionassero nel modo che mi serviva impostando la Modalità di ripristino su Full, creando un separato FILEGROUPper il FILESTREAM, quindi prendendo i backup solo del "Primario" FILEGROUP. Il problema che ciò ha causato è che il file di registro (di cui viene anche eseguito il backup) è ora inutilmente grande perché include i FILESTREAMdati.

SIMPLELa modalità di recupero mi toglie la capacità di fare backup di specifici messaggi di posta FILEGROUP, quindi non credo che sarà un'opzione.

Il mio pensiero è quello di spostare i FILESTREAMdati in un database separato, ma ora sto perdendo l'integrità referenziale e sicuramente ereditando anche una serie di altri problemi.

Esiste un modo per creare backup parziali in Simplemodalità di ripristino (senza impostare la FILESTREAMtabella in sola lettura)? In caso contrario, ci sono altre soluzioni sane al mio problema?

Il problema che ciò ha causato è che il file di registro (di cui viene anche eseguito il backup) è ora inutilmente grande perché include i dati FILESTREAM.

Non sono sicuro se intendi che il file di registro stesso è troppo grande o che i backup del file di registro diventano troppo grandi.

Se è il primo, quanto spesso esegui il backup del registro? A seconda del design dell'applicazione, è possibile ridurre le dimensioni eseguendo il backup più frequentemente (e ogni 5 minuti non è troppo frequente). Tuttavia, se lo stavi già facendo ed era ancora in mongolfiera, probabilmente sei sfortunato. Perché il file di registro di grandi dimensioni è di nuovo un problema?

Se è il secondo - sembrava che tu fossi felice di continuare con un semplice modello di recupero e nessun ripristino temporizzato se ti permettesse di avere backup più piccoli; in tal caso, rimanere in modalità completa ed eliminare i backup del registro.

Una soluzione per un database impostato sulla modalità di ripristino SEMPLICE è avere i dati FILESTREAM in un gruppo di file di sola lettura (che non è l'opzione ideale) e quindi eseguire il backup solo dei gruppi di file di lettura / scrittura con DIFFERENZIALE in questo modo:

BACKUP DATABASE [name] READ_WRITE_FILEGROUPS TO DISK = '' WITH DIFFERENTIAL, COMPRESSION;

Otterrà tutti i dati che sono stati modificati in qualsiasi filegroup di lettura / scrittura. È il più semplice, pronto all'uso, che è possibile mantenere gestibili backup parziali senza ottenere i dati FILESTREAM. Richiederebbe tuttavia che il processo di caricamento per i dati sopra menzionati debba modificare il filegroup in modo che sia letto / scritto, carichi eventuali dati aggiuntivi e quindi imposti la lettura di nuovo. Certamente non l'ideale.

Mi sento sporca fornire questo come opzione, ma se si sceglie di separare i dati FILESTREAM nel proprio database, è in grado di mantenere RI tra i tavoli nelle DBS separati a titolo di trigger :

Trigger -> Note -> Limitazioni:
un trigger viene creato solo nel database corrente; tuttavia, un trigger può fare riferimento a oggetti esterni al database corrente.

Aspettatevi problemi di prestazioni e una sezione del cuoio capelluto per diventare glabro dopo aver estratto ciuffi di pelliccia vostra testa per la frustrazione, ma in teoria si potrebbe fare questo. Non consiglio questo approccio a nessun livello, invece ti consiglio vivamente di aumentare la frequenza dei tuoi backup di tlog e / o passare al modello di recupero con registrazione di massa e vedere quanto spazio ti consente di risparmiare, MA questa è una possibile soluzione. Avresti davvero bisogno di soppesare il vantaggio di separare questi dati e gestire un progetto di database di Frankenstein, ma è un'opzione.

... ora devo andare a farmi una doccia ...

So che questa domanda ha già una risposta, ma esiste un'altra soluzione che potrebbe aiutare gli altri. Recentemente ho imparato dal blog di Brent Ozar che esiste un'opzione per scartare immediatamente i backup dei log:

BACKUP LOG MyDb TO DISK='NUL:'

Quindi puoi lasciare il tuo database in Fullmodalità di ripristino ed eseguire backup di filegroup. Quando il registro delle transazioni diventa troppo grande, emettere semplicemente il comando del registro di backup e il gioco è fatto.