Condividi tramite

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 da cui dipende Azure DevOps Server. Per ripristinare completamente la distribuzione di Azure DevOps Server, eseguire prima di tutto il backup di tutti i database di Azure DevOps Server.

Se la distribuzione include SQL Server Reporting Services, è anche necessario eseguire il backup dei database usati da Azure DevOps all'interno di tali componenti. Per evitare errori di sincronizzazione o errori di mancata corrispondenza dei dati, è necessario sincronizzare tutti i backup con lo stesso timestamp. Il modo più semplice per garantire la corretta sincronizzazione consiste nell'usare transazioni contrassegnate. Contrassegnando regolarmente le transazioni correlate in ogni database, si stabilisce una serie di punti di ripristino comuni nei database. Per indicazioni 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 dalla perdita di dati creando backup del database. La tabella seguente e le illustrazioni di accompagnamento mostrano quali database eseguire il backup e forniscono 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 del 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

In base alla configurazione di distribuzione, tutti i database che richiedono il backup potrebbero trovarsi nello stesso server fisico, come in questa topologia di esempio.

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 semplice del database del server Azure DevOps

In alternativa, i database potrebbero essere distribuiti tra più server e server farm. In questa topologia di esempio è necessario eseguire il backup dei database seguenti, ridimensionati in sei server o server farm:

  • database di configurazione

  • database del warehouse

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

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

  • i database che si trovano nel server che esegue Reporting Services

  • database che si trova nel server che esegue Analysis Services

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

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

Struttura complessa del database di Azure DevOps Server

In entrambi questi esempi non è necessario eseguire il backup di nessuno 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 di cui eseguire il backup

L'elenco seguente fornisce dettagli aggiuntivi sugli elementi di cui è necessario eseguire il backup, a seconda delle risorse di distribuzione.

Importante

Tutti i database nell'elenco seguente sono database di SQL Server. Sebbene sia possibile usare SQL Server Management Studio per eseguire il backup di singoli database in qualsiasi momento, è consigliabile evitare di usare tali singoli backup quando possibile. Se si esegue il ripristino da singoli backup, è possibile che si verifichino risultati imprevisti perché i database usati da Azure DevOps sono tutti correlati. Se si esegue il backup di un solo database, i dati in tale 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 di SQL Server, tra cui il database di configurazione, il database del warehouse e un database per ogni raccolta di progetti nella distribuzione. Questi database potrebbero trovarsi tutti nello stesso server, distribuiti in più istanze nella stessa distribuzione di SQL Server o distribuiti tra più server. Indipendentemente dalla distribuzione fisica, è necessario eseguire il backup di tutti i database nello stesso timestamp per garantire la perdita di dati. È possibile eseguire i backup del database manualmente o automaticamente usando piani di manutenzione eseguiti a intervalli o ore specifici.

    Importante

    L'elenco dei database di Azure DevOps non è statico. Viene creato un nuovo database ogni volta che si crea una raccolta. Quando si crea una raccolta, assicurarsi di aggiungere il database per tale 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, è comunque necessario rigenerare determinati database dopo il ripristino, ad esempio il magazzino.
  • Chiave di crittografia per il server di report: il server di report dispone di una chiave di crittografia di cui è necessario eseguire il backup. Questa chiave protegge le informazioni riservate archiviate nel database per il server di report. È possibile eseguire manualmente il backup di questa chiave usando lo strumento di configurazione di Reporting Services o uno strumento da riga di comando.

Preparazione avanzata per i backup

Quando si distribuisce Azure DevOps, è necessario mantenere un record degli account creati e di qualsiasi nome computer, password e opzioni di configurazione specificate. È anche consigliabile conservare una copia di tutti i materiali di ripristino, i documenti e i backup del database e del log delle transazioni in una posizione sicura. Per proteggersi da un'emergenza, ad esempio un incendio o un terremoto, è necessario mantenere duplicati dei backup del server in una posizione diversa dalla posizione dei server. Questa strategia consente di proteggersi dalla perdita di dati critici. Come procedura consigliata, è consigliabile conservare tre copie del supporto di backup e mantenere almeno una copia fuori sede in un ambiente controllato.

Importante

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

Quando si esegue il backup e il ripristino di un database, è necessario eseguire il backup dei dati nei supporti con un indirizzo di rete, ad esempio nastri e dischi condivisi come unità di rete. Il piano di backup deve includere il provisioning per la gestione dei supporti, ad esempio le tattiche seguenti:

  • Piano di rilevamento e gestione per l'archiviazione e il riciclo dei set di backup.
  • Pianificazione per la sovrascrittura dei supporti di backup.
  • In un ambiente multiserver, una decisione di usare backup centralizzati o distribuiti.
  • Un modo per tenere traccia della vita utile dei media.
  • Procedura per ridurre al minimo gli effetti della perdita di un set di backup o di un supporto di backup, ad esempio un nastro.
  • Decisione di archiviare i set di backup in loco o fuori sede e un'analisi del modo in cui questa decisione potrebbe influire sul tempo di ripristino.

Poiché i dati di Azure DevOps vengono archiviati nei database di 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 interessava tali computer, è possibile reinstallare il software client e riconnettersi al server. Installando nuovamente il software client, gli utenti avranno un'alternativa più pulita e affidabile al ripristino di un computer client da un backup.

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

Tipi di backup

Comprendere i tipi di backup disponibili consente di determinare le opzioni migliori per il backup della distribuzione. Ad esempio, se si lavora con una distribuzione di grandi dimensioni e si vuole proteggersi dalla perdita di dati usando in modo efficiente risorse di archiviazione limitate, è possibile configurare backup differenziali e backup completi dei dati. Se si usa SQL Server Always On, è possibile eseguire backup del database secondario. È anche possibile provare a usare la compressione dei backup o suddividere i backup tra più file. Di seguito sono riportate brevi descrizioni delle opzioni di backup:

Backup completi dei dati (database)

Per la recuperabilità della distribuzione è necessario un backup completo del database. Un backup completo include parte del log delle transazioni in modo da poter ripristinare il backup completo. I backup completi sono autonomi in quanto rappresentano l'intero database esistente durante il 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 del database sono più piccoli e veloci rispetto ai backup completi del database. Questa opzione consente di risparmiare tempo di backup a causa di una maggiore complessità. Per i database di grandi dimensioni, i backup differenziali possono verificarsi a intervalli più brevi rispetto ai backup del database, riducendo così l'esposizione alla perdita di lavoro. Per altre informazioni, vedere Backup differenziali del database.

È anche consigliabile eseguire regolarmente il backup dei log delle transazioni. Questi backup sono necessari per il ripristino dei dati quando si usa il modello di backup completo del 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 del 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 ai dati e, se necessario, informazioni sufficienti per annullare le modifiche apportate durante tale transazione. Il log aumenta continuamente man mano che si verificano operazioni registrate nel database.

Eseguendo il backup dei log delle transazioni, è possibile ripristinare il database in un momento precedente. Ad esempio, è possibile ripristinare il database a un punto prima dell'immissione di dati indesiderati o di un errore. Oltre ai backup del database, i backup del log delle transazioni devono far parte della strategia di ripristino. Per altre informazioni, vedere Backup di log delle transazioni (SQL Server).

I backup del log delle transazioni in genere usano meno risorse rispetto ai backup completi. Pertanto, è possibile creare backup del log delle transazioni più frequentemente rispetto ai backup completi, riducendo così il rischio di perdita di dati. Tuttavia, a volte un backup del log delle transazioni è maggiore di un backup completo. Ad esempio, un database con una frequenza di transazioni elevata determina un aumento rapido del log delle transazioni. In questo caso, è consigliabile creare backup del log delle transazioni più frequentemente. Per altre informazioni, vedere Risolvere i problemi relativi a un log delle transazioni pieno (Errore di SQL Server 9002).

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

  • Un backup del log puro contiene solo i record del log delle transazioni per un intervallo, senza modifiche in blocco.
  • Un backup del log bulk contiene pagine di log e dati modificate dalle operazioni bulk. Il recupero temporizzato non è consentito.
  • Un backup della parte finale del log viene eseguito da un database potenzialmente danneggiato per acquisire i record di log di cui non è stato ancora eseguito il backup. Un backup della parte finale del log viene eseguito dopo un errore per evitare la perdita di lavoro e può contenere dati di log puro o di log 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 di 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 usa la funzionalità Backup pianificati per eseguire il backup della distribuzione, questa chiave verrà sottoposta a backup come parte del piano. Si potrebbe presupporre che sia necessario 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 di 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 hanno tutti questi database. Ad esempio, se azure DevOps Server non è stato configurato con Reporting Services, i database ReportServer o ReportServerTempDB non saranno disponibili. 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 è in funzione.

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 del 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 di compilazione e le configurazioni di gestione del lab. Il numero di database di raccolta sarà uguale 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 warehouse 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 quando si eseguono report 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 amministrazione di SCVMM, ad esempio macchine virtuali, host macchina virtuale, server di libreria di macchine virtuali e relative proprietà.
Nota: se SCVMM è installato in un server separato rispetto ad 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 consigliabile usare transazioni contrassegnate e sincronizzare la manutenzione dei database per evitare errori di sincronizzazione.