Share via

Database, topologie di distribuzione e backup

  • Articolo

Azure DevOps Server 2022 | Azure DevOps Server 2020 | Azure DevOps Server 2019

È possibile proteggere la distribuzione dalla perdita di dati creando una pianificazione regolare dei backup per i database che Azure DevOps Server dipende. Per ripristinare completamente la distribuzione Azure DevOps Server, eseguire il backup di tutti i database Azure DevOps Server.

Se la distribuzione include SQL Server Reporting Services, è necessario eseguire anche il backup dei database usati da Azure DevOps all'interno di tali componenti. Per prevenire eventuali errori di sincronizzazione o di mancata corrispondenza dei dati, tutti i backup devono essere sincronizzati allo stesso timestamp. Il modo più semplice per garantire una corretta sincronizzazione consiste nell'utilizzare le transazioni contrassegnate. Contrassegnando di routine le transazioni correlate in ogni database, si stabilisce una serie di punti di ripristino comuni nei database. Per istruzioni dettagliate sul backup di una distribuzione a server singolo che usa la creazione di report, vedere Creare una pianificazione e un piano di backup.

Backup dei database

Proteggere la distribuzione di Azure DevOps contro la perdita di dati creando backup del database. La tabella seguente e le illustrazioni di accompagnamento mostrano quali database eseguire il backup e fornire esempi di come tali database potrebbero essere distribuiti fisicamente in una distribuzione.

Tipo di database Prodotto Componente obbligatorio?
Database di configurazione Azure DevOps Server Sì
Database warehouse Azure DevOps Server Sì
Database della raccolta di progetti Azure DevOps Server Sì
Database di report SQL Server Reporting Services No
Database di analisi SQL Server Analysis Services No

Topologie di distribuzione

A seconda della configurazione di distribuzione, tutti i database per i quali è richiesto il backup possono trovarsi nello stesso server fisico, come in questo esempio di topologia.

Nota

Questo esempio non include Reporting Services o Prodotti SharePoint, pertanto non è necessario eseguire il backup di database associati a report, analisi o Prodotti SharePoint.

Struttura di database di Azure DevOps Server semplice

In alternativa, i database possono essere distribuiti in diversi server e server farm. In questo esempio di topologia, è necessario eseguire il backup dei database seguenti, che sono ridimensionati in sei server o server farm:

  • database di configurazione

  • database warehouse

  • database della raccolta di progetti che si trovano nel cluster SQL Server

  • database di raccolta che si trova nel server autonomo che esegue SQL Server

  • database che si trovano nel server che esegue Reporting Services

  • database che si trova nel server che esegue Analysis Services

  • database amministrativi di SharePoint Products e database della raccolta siti per entrambe le applicazioni Web di SharePoint

    Se i database di SharePoint vengono ridimensionati in più server, non è possibile usare la funzionalità Backup pianificati per eseguirne il backup. È necessario configurare manualmente i backup per tali database e assicurarsi che tali backup vengano sincronizzati con i backup del database Azure DevOps Server. Per altre informazioni, vedere Eseguire il backup manuale di Azure DevOps Server.

Struttura di database Azure DevOps Server complessa

In entrambi gli esempi non è necessario eseguire il backup dei client che si connettono al server. Tuttavia, potrebbe essere necessario cancellare manualmente le cache per Azure DevOps Server nei computer client prima di poter riconnettersi alla distribuzione ripristinata.

Database da sottoporre a backup

L'elenco seguente fornisce altri dettagli relativi a ciò che è necessario eseguire il backup, a seconda delle risorse di distribuzione.

Importante

Tutti i database nell'elenco seguente sono SQL Server database. Anche se è possibile usare SQL Server Management Studio per eseguire il backup di singoli database in qualsiasi momento, è consigliabile evitare l'uso di tali singoli backup quando possibile. È possibile che si verifichino risultati imprevisti se si ripristinano dai singoli backup perché i database usati da Azure DevOps sono tutti correlati. Se si esegue il backup di un solo database, i dati nel database potrebbero non essere sincronizzati con i dati negli altri database.

  • Database per Azure DevOps Server: il livello dati logico per Azure DevOps Server include diversi database SQL Server, tra cui il database di configurazione, il database del warehouse e un database per ogni raccolta di progetti nella distribuzione. Questi database possono trovarsi nello stesso server, distribuiti in diverse istanze nella stessa distribuzione SQL Server o distribuite in più server. Indipendentemente dalla distribuzione fisica, è necessario eseguire il backup di tutti i database allo stesso timestamp per evitare una possibile perdita di dati. I backup dei database possono essere eseguiti manualmente o automaticamente utilizzando piani di manutenzione eseguiti in momenti specifici o a intervalli specifici.

    Importante

    L'elenco dei database Di Azure DevOps non è statico. Un nuovo database viene creato ogni volta che si crea una raccolta. Quando si crea una raccolta, assicurarsi di aggiungere il database per quella raccolta al piano di manutenzione.

  • Database per Reporting Services e Analysis Services: se la distribuzione usa SQL Server Reporting Services o SQL Server Analysis Services per generare report per Azure DevOps Server, è necessario eseguire il backup dei database di report e analisi. Tuttavia, sarà sempre necessario rigenerare determinati database dopo il ripristino, ad esempio quello relativo al warehouse.
  • Chiave di crittografia per il server di report: il server di report dispone di una chiave di crittografia che è necessario eseguire il backup. Questa chiave protegge le informazioni riservate archiviate nel database del server di rapporti. È possibile eseguire manualmente il backup della chiave utilizzando lo strumento di configurazione di Reporting Services o uno strumento della riga di comando.

Preparazione avanzata per i backup

Quando si distribuisce Azure DevOps, è necessario mantenere un record degli account creati e qualsiasi nome di computer, password e opzioni di configurazione specificate. Inoltre, sarebbe bene conservare in un percorso protetto una copia di tutti i materiali di ripristino, documenti e backup dei log dei database e delle transazioni. Per salvaguardarsi da un'eventuale calamità, quale un incendio o un terremoto, è consigliabile conservare duplicati dei backup dei server in luoghi diversi dal luogo in cui si trovano i server. Questa strategia contribuirà a salvaguardarsi dal rischio di una perdita di dati critici. Si consiglia di conservare tre copie dei supporti di backup, di cui almeno una fuori sede in un ambiente adeguatamente controllato.

Importante

Eseguire periodicamente tentativi di ripristino di dati per verificare che il backup dei file sia stato eseguito correttamente. Un ripristino di prova può rivelare problemi hardware che non vengono visualizzati con una verifica solo software.

Quando si eseguono il backup e il ripristino di un database, è necessario eseguire il backup dei dati su supporti con un indirizzo di rete, ad esempio nastri e dischi che sono stati condivisi come unità di rete. Il piano di backup deve includere indicazioni sulla gestione dei supporti, ad esempio i seguenti espedienti:

  • Un piano per tenere traccia e gestire la memorizzazione e il riciclo degli insiemi di backup.
  • Una pianificazione per la sovrascrittura dei supporti di backup.
  • In un ambiente multiserver, la scelta tra backup centralizzato e distribuito.
  • Un metodo per tenere traccia della durata utile dei supporti.
  • Una procedura per ridurre al minimo le conseguenze della perdita di un set di backup o di un supporto di backup, ad esempio un nastro.
  • La scelta tra l'archiviazione dei set di backup in sede o fuori sede e un'analisi dell'impatto di tale scelta sui tempi di ripristino.

Poiché i dati di Azure DevOps vengono archiviati in database SQL Server, non è necessario eseguire il backup dei computer in cui sono installati i client di Azure DevOps. Se si verifica un errore multimediale o un'emergenza che ha coinvolto tali computer, è possibile reinstallare il software client e riconnettersi al server. Installando nuovamente il software client, gli utenti avranno un'alternativa più pulita e più affidabile al ripristino di un computer client da un backup.

È possibile eseguire il backup di un server usando le funzionalità Backup pianificate disponibili oppure creando manualmente piani di manutenzione in SQL Server per eseguire il backup dei database correlati alla distribuzione di Azure DevOps. I database DevOps di Azure funzionano in relazione tra loro e, se si crea un piano manuale, è necessario eseguirne il backup e ripristinarli contemporaneamente. Per altre informazioni sulle strategie per il backup dei database, vedere Backup e ripristino di database SQL Server.

Tipi di backup

Informazioni sui tipi di backup disponibili consentono di determinare le opzioni migliori per il backup della distribuzione. Ad esempio, se si utilizza una distribuzione di grandi dimensioni e si desidera evitare la perdita di dati utilizzando in modo efficiente le risorse di archiviazione limitate, è possibile configurare dei backup differenziali nonché dei backup di dati completi. Se si usa SQL Server Always On, è possibile eseguire backup del database secondario. È inoltre possibile provare a utilizzare la compressione dei backup o dividere i backup in più file. Di seguito sono riportate brevi descrizioni delle opzioni di backup:

Backup completi dei dati (database)

Un backup completo del database è necessario per la recuperabilità della distribuzione. Un backup completo include parte del log delle transazioni, che ne consente il ripristino. I backup completi sono indipendenti in quanto rappresentano l'intero database esistente al momento dell'esecuzione del backup. Per altre informazioni, vedere Backup completi del database.

Backup differenziali dei dati (database)

Un backup differenziale del database registra solo i dati modificati dopo l'ultimo backup completo del database, denominato base differenziale. I backup differenziali di database sono più rapidi e di dimensioni inferiori rispetto ai backup completi di database. Si tratta di un'opzione che consente di risparmiare tempo ma aumenta la complessità. Per i database di grandi dimensioni, i backup differenziali possono avvenire a intervalli più brevi rispetto ai backup di database, riducendo il rischio di una perdita del lavoro. Per altre informazioni, vedere Backup differenziali del database.

Anche i log delle transazioni devono essere sottoposti a regolare backup. Questi backup sono necessari per il ripristino dei dati quando si utilizza il modello di backup completo dei database. Se si esegue il backup dei log delle transazioni, è possibile ripristinare il database fino al punto di errore o a un momento precedente.

Backup dei log delle transazioni

Il log delle transazioni è un record seriale di tutte le modifiche apportate in un database oltre alla transazione che ha eseguito ogni modifica. Il log delle transazioni registra l'inizio di ogni transazione, le modifiche apportate ai dati e, se necessario, informazioni sufficienti per annullare le modifiche apportate nel corso della transazione. La dimensione del registro cresce continuamente per ogni operazione registrata eseguita sul database.

Eseguendo il backup dei log delle transazioni, è possibile ripristinare il database com'era in un momento precedente. Ad esempio, è possibile ripristinare il database a un punto prima che i dati indesiderati vengano immessi o si sia verificato un errore. La strategia di recupero deve includere il backup del registro delle transazioni oltre al backup dei database. Per altre informazioni, vedere Backup di log delle transazioni (SQL Server).

Poiché in genere i backup del registro delle transazioni richiedono meno risorse rispetto al backup completo, è possibile creare il backup del log delle transazioni con più frequenza rispetto ai backup completi, riducendo il rischio di una perdita di dati. È però possibile che in alcuni casi la dimensione del backup del registro delle transazioni sia maggiore di quella di un backup completo. Ad esempio, un database con una frequenza delle transazioni elevata determina un aumento rapido del log delle transazioni. In questi casi è consigliabile creare backup del log delle transazioni con maggiore frequenza. Per altre informazioni, vedere Risolvere i problemi relativi a un log delle transazioni completo (errore SQL Server 9002).

È possibile eseguire i seguenti tipi di backup del log delle transazioni:

  • Il backup puro del registro contiene solo i record del registro delle transazioni per un intervallo, senza modifiche di massa.
  • Il backup bulk del log contiene le pagine del log e dei dati modificate in seguito a operazioni di massa. Il recupero temporizzato non è consentito.
  • Il backup della parte finale del log viene eseguito per un database possibilmente danneggiato per ottenere i record del registro delle transazioni di cui non è stato ancora eseguito il backup. Questo tipo di backup viene eseguito in seguito a un errore per impedire la perdita del lavoro e può contenere dati del log puro o bulk.

Poiché la sincronizzazione dei dati è fondamentale per il ripristino corretto di Azure DevOps Server, è consigliabile usare transazioni contrassegnate come parte della strategia di backup se si configurano manualmente i backup. Per altre informazioni, vedere Creare una pianificazione e un piano di backup e eseguire manualmente il backup Azure DevOps Server.

Backup del servizio livello applicazione

L'unico backup necessario per il livello applicazione logica è per la chiave di crittografia per Reporting Services. Se si utilizza la funzionalità Backup pianificati per eseguire il backup della distribuzione, verrà eseguito il backup automatico della chiave come parte del piano. Si supponga di dover eseguire il backup di siti Web usati come portali di progetto.

Anche se è possibile eseguire il backup di un livello applicazione più facilmente rispetto a un livello dati, esistono ancora diversi passaggi per ripristinare un livello applicazione. È necessario installare un altro livello applicazione per Azure DevOps Server, reindirizzare le raccolte di progetti per usare il nuovo livello applicazione e reindirizzare i siti del portale per i progetti.

Nomi database predefiniti

Se non si personalizzano i nomi dei database, è possibile usare la tabella seguente per identificare i database usati nella distribuzione di Azure DevOps Server. Come accennato in precedenza, non tutte le distribuzioni dispongono di tutti questi database. Se, ad esempio, non è stato configurato Azure DevOps Server con Reporting Services, non saranno disponibili i database ReportServer o ReportServerTempDB. Analogamente, non si avrà il database per System Center Virtual Machine Manager (SCVMM), VirtualManagerDB, a meno che non si configuri Azure DevOps Server per supportare Lab Management. Inoltre, i database usati da Azure DevOps Server possono essere distribuiti in più di un'istanza di SQL Server o in più server.

Nota

Per impostazione predefinita, il prefisso TFS_ viene aggiunto ai nomi di tutti i database creati automaticamente quando si installa Azure DevOps Server o mentre funziona.

Database Descrizione
TFS_Configuration Il database di configurazione per Azure DevOps Server contiene il catalogo, i nomi dei server e i dati di configurazione per la distribuzione. Il nome di questo database può includere caratteri aggiuntivi tra TFS_ e Configurazione, ad esempio il nome utente della persona che ha installato Azure DevOps Server. Ad esempio, il nome del database potrebbe essere TFS_UserNameConfiguration
TFS_Warehouse Il database warehouse contiene i dati per la compilazione del warehouse utilizzato da Reporting Services. Il nome di questo database può includere caratteri aggiuntivi tra TFS_ e Warehouse, ad esempio il nome utente della persona che ha installato Azure DevOps Server. Ad esempio, il nome del database potrebbe essere TFS_UserNameWarehouse.
TFS_CollectionName Il database per una raccolta di progetti contiene tutti i dati per i progetti in tale raccolta. Questi dati includono il codice sorgente, le configurazioni della build e le configurazioni di Lab Management. Il numero di database di raccolte sarà pari al numero di raccolte. Ad esempio, se nella distribuzione sono presenti tre raccolte, è necessario eseguire il backup di questi tre database di raccolta. Il nome di ogni database può includere caratteri aggiuntivi tra TFS_ e CollectionName, ad esempio il nome utente della persona che ha creato la raccolta. Ad esempio, il nome di un database di raccolta potrebbe essere TFS_UserNameCollectionName.
TFS_Analysis Il database per SQL Server Analysis Services contiene le origini dati e i cubi per la distribuzione di Azure DevOps Server. Il nome di questo database può includere caratteri aggiuntivi tra TFS_ e Analysis, ad esempio il nome utente della persona che ha installato Analysis Services. Ad esempio, il nome del database potrebbe essere TFS_UserNameAnalysis.
Nota: è possibile eseguire il backup di questo database, ma è necessario ricompilare il magazzino dal database TFS_Warehouse ripristinato.
ReportServer Il database per Reporting Services contiene i report e le impostazioni del report per la distribuzione di Azure DevOps Server.
Nota: se Reporting Services è installato in un server separato da Azure DevOps Server, questo database potrebbe non essere presente nel server livello dati per Azure DevOps Server. In tal caso, è necessario configurare, eseguire il backup e ripristinarlo separatamente da Azure DevOps Server. È consigliabile sincronizzare la manutenzione dei database per evitare errori di sincronizzazione.
ReportServerTempDB Il database temporaneo per Reporting Services archivia temporaneamente le informazioni utilizzate per eseguire rapporti specifici.
Nota: se Reporting Services è installato in un server separato rispetto a Azure DevOps Server, questo database potrebbe non essere presente nel server livello dati per Azure DevOps Server. In questo caso, è necessario configurare, eseguire il backup e ripristinarlo separatamente da Azure DevOps Server. Tuttavia, è necessario sincronizzare la manutenzione dei database per evitare errori di sincronizzazione.
VirtualManagerDB Il database di amministrazione per SCVMM contiene le informazioni visualizzate nella console di amministratore SCVMM, ad esempio macchine virtuali, host macchina virtuale, server di libreria di macchine virtuali e le relative proprietà.
Nota: se SCVMM è installato in un server separato rispetto a Azure DevOps Server, questo database potrebbe non essere presente nel server livello dati per Azure DevOps Server. In tal caso, è necessario configurare, eseguire il backup e ripristinarlo separatamente da Azure DevOps Server. Tuttavia, è necessario utilizzare transazioni contrassegnate e sincronizzare la manutenzione dei database per evitare errori di sincronizzazione.