Bagikan melalui


Database, topologi penyebaran, dan pencadangan

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

Anda dapat membantu melindungi penyebaran Anda dari kehilangan data dengan membuat jadwal pencadangan yang teratur untuk database yang Azure DevOps Server bergantung. Untuk memulihkan penyebaran Azure DevOps Server Anda sepenuhnya, pertama-tama cadangkan semua database Azure DevOps Server.

Jika penyebaran Anda termasuk Layanan Pelaporan SQL Server, Anda juga harus mencadangkan database yang Azure DevOps gunakan dalam komponen tersebut. Untuk mencegah kesalahan sinkronisasi atau kesalahan ketidakcocokan data, Anda harus menyinkronkan semua pencadangan ke stempel waktu yang sama. Cara termudah untuk memastikan sinkronisasi yang berhasil adalah dengan menggunakan transaksi yang ditandai. Dengan secara rutin menandai transaksi terkait di setiap database, Anda membuat serangkaian titik pemulihan umum di dalam database. Untuk panduan langkah-demi-langkah untuk mencadangkan penyebaran server-tunggal yang menggunakan pelaporan, lihat Membuat jadwal dan rencana cadangan.

Mencadangkan database

Lindungi penyebaran Azure DevOps Anda dari kehilangan data dengan membuat pencadangan database. Tabel dan ilustrasi yang menyertainya berikut ini menunjukkan database mana yang akan dicadangkan, dan menyediakan contoh bagaimana database tersebut mungkin didistribusikan secara fisik dalam penyebaran.

Jenis Database Produk Komponen yang diperlukan?
Database konfigurasi Azure DevOps Server Ya
Database gudang Azure DevOps Server Ya
Database pengumpulan proyek Azure DevOps Server Ya
Database pelaporan Layanan Pelaporan SQL Server No
Database analisis SQL Server Analysis Services No

Topologi penyebaran

Berdasarkan konfigurasi penyebaran Anda, semua database yang memerlukan pencadangan mungkin berada di server fisik yang sama, seperti dalam contoh topologi ini.

Catatan

Contoh ini tidak termasuk Layanan Pelaporan atau Produk SharePoint, jadi Anda tidak perlu mencadangkan database apa pun yang terkait dengan pelaporan, analisis, atau Produk SharePoint.

Struktur database Azure DevOps Server sederhana

Atau, database tersebut mungkin didistribusikan di banyak server dan farm server. Dalam topologi contoh ini, Anda harus mencadangkan database berikut, yang diskalakan di seluruh enam server atau farm server:

  • konfigurasi

  • database gudang

  • database pengumpulan proyek yang terletak pada kluster SQL Server

  • database pengumpulan yang terletak pada server mandiri yang menjalankan SQL Server

  • database yang terletak pada server yang menjalankan Layanan Pelaporan

  • database yang terletak pada server yang menjalankan Analysis Services

  • database administratif Produk SharePoint dan database pengumpulan situs untuk kedua aplikasi web SharePoint

    Jika database SharePoint Anda diskalakan di beberapa server, Anda tidak dapat menggunakan fitur Pencadangan Terjadwal untuk mencadangkannya. Anda harus mengonfigurasi pencadangan secara manual untuk database tersebut, dan memastikan bahwa pencadangan tersebut disinkronkan dengan pencadangan database Azure DevOps Server. Untuk informasi selengkapnya, baca Mencadangkan Azure DevOps Server secara manual.

Struktur database Azure DevOps Server yang kompleks

Dalam kedua contoh ini, Anda tidak perlu mencadangkan klien mana pun yang tersambung ke server. Namun, Anda mungkin perlu membersihkan cache secara manual untuk Azure DevOps Server di komputer klien sebelum mereka dapat tersambung kembali ke penyebaran yang dipulihkan.

Database untuk mencadangkan

Daftar berikut ini menyediakan detail tambahan mengenai apa yang harus Anda cadangkan, tergantung pada sumber daya penyebaran Anda.

Penting

Semua database dalam daftar berikut adalah database SQL Server. Meskipun Anda dapat menggunakan SQL Server Management Studio untuk mencadangkan database individual kapan saja, Anda harus menghindari penggunaan pencadangan individual tersebut jika memungkinkan. Anda mungkin mengalami hasil yang tidak terduga jika Anda memulihkan dari pencadangan individual karena database yang Azure DevOps gunakan semuanya terkait. Jika Anda hanya mencadangkan satu database, data dalam database tersebut mungkin tidak disinkronkan dengan data di database lain.

  • Database untuk Azure DevOps Server - Tingkat data logis untuk Azure DevOps Server termasuk beberapa database SQL Server, termasuk konfigurasi, database gudang, dan database untuk setiap pengumpulan proyek dalam penyebaran tersebut. Database ini mungkin semuanya berada di server yang sama, didistribusikan di beberapa instans dalam penyebaran SQL Server yang sama, atau didistribusikan di beberapa server. Terlepas dari distribusi fisiknya, Anda harus mencadangkan semua database ke stempel waktu yang sama untuk membantu memastikan terhadap kehilangan data. Anda dapat melakukan pencadangan database secara manual atau otomatis dengan menggunakan rencana pemeliharaan yang berjalan pada waktu atau interval tertentu.

    Penting

    Daftar database Azure DevOps tidak statik. Database baru dibuat setiap kali Anda membuat pengumpulan. Saat Anda membuat pengumpulan, pastikan Anda menambahkan database untuk pengumpulan tersebut ke rencana pemeliharaan Anda.

  • Database untuk Layanan Pelaporan dan Analysis Services - Jika penyebaran Anda menggunakan Layanan Pelaporan SQL Server atau SQL Server Analysis Services untuk menghasilkan laporan untuk Azure DevOps Server, Anda harus mencadangkan database pelaporan dan analisis. Namun, Anda masih harus meregenerasi database tertentu setelah pemulihan, seperti gudang.
  • Kunci enkripsi untuk server laporan - Server laporan memiliki kunci enkripsi yang harus Anda cadangkan. Kunci ini melindungi informasi sensitif yang disimpan dalam database untuk server laporan. Anda dapat mencadangkan kunci ini secara manual dengan menggunakan alat Konfigurasi Layanan Pelaporan atau alat baris-perintah.

Persiapan tingkat lanjut untuk pencadangan

Saat menyebarkan Azure DevOps, Anda harus menyimpan rekaman akun yang Anda buat dan nama komputer, kata sandi, dan opsi penyetelan apa pun yang Anda tentukan. Anda juga harus menyimpan salinan semua materi pemulihan, dokumen, dan database serta pencadangan log transaksi di lokasi yang aman. Supaya terlindung terhadap bencana, seperti kebakaran atau gempa bumi, Anda harus menyimpan duplikat pencadangan server Anda di lokasi yang berbeda dari lokasi server. Strategi ini akan membantu melindungi Anda terhadap kehilangan data penting. Sebagai praktik terbaik, Anda harus menyimpan tiga salinan media pencadangan, dan Anda harus menyimpan setidaknya satu salinan situs luar lokasi di lingkungan yang terkontrol.

Penting

Lakukan pemulihan data uji coba secara berkala untuk memverifikasi bahwa file Anda dicadangkan dengan benar. Pemulihan uji coba dapat mengungkapkan masalah perangkat keras yang tidak muncul dengan verifikasi khusus-perangkat lunak.

Saat mencadangkan dan memulihkan database, Anda harus mencadangkan data ke media dengan alamat jaringan (misalnya, pita dan disk yang telah dibagikan sebagai drive jaringan). Rencana pencadangan Anda harus termasuk ketentuan untuk mengelola media, seperti taktik berikut:

  • Rencana pelacakan dan pengelolaan untuk menyimpan dan mendaur ulang kumpulan pencadangan.
  • Jadwal untuk menimpa media pencadangan.
  • Dalam lingkungan multi-server, keputusan yang digunakan pencadangan terpusat atau terdistribusi.
  • Cara melacak masa pakai media yang berguna.
  • Prosedur untuk meminimalkan efek kehilangan kumpulan pencadangan atau media pencadangan (misalnya, pita).
  • Keputusan untuk menyimpan kumpulan pencadangan di lokasi atau di situs luar dan analisis tentang bagaimana keputusan ini dapat memengaruhi waktu pemulihan.

Karena data Azure DevOps disimpan dalam database SQL Server, Anda tidak harus mencadangkan komputer tempat klien Azure DevOps diinstal. Jika kegagalan media atau bencana yang melibatkan komputer tersebut muncul, Anda dapat memasang ulang perangkat lunak klien dan menyambungkan kembali ke server. Dengan memasang ulang perangkat lunak klien, pengguna Anda akan memiliki alternatif yang lebih bersih dan lebih dapat diandalkan untuk memulihkan komputer klien dari cadangan.

Anda dapat mencadangkan server dengan menggunakan fitur Pencadangan Terjadwal yang tersedia, atau dengan membuat rencana pemeliharaan secara manual di SQL Server untuk mencadangkan database yang terkait dengan penyebaran Azure DevOps Anda. Database Azure DevOps bekerja dalam hubungan satu sama lain, dan jika Anda membuat rencana manual, Anda harus mencadangkannya dan memulihkannya secara bersamaan. Untuk informasi selengkapnya tentang strategi untuk mencadangkan database, lihat Mencadangkan dan memulihkan Database SQL Server.

Jenis pencadangan

Memahami jenis pencadangan yang tersedia membantu Anda menentukan opsi terbaik untuk mencadangkan penyebaran Anda. Misalnya, jika Anda bekerja dengan penyebaran besar dan ingin terlindung terhadap kehilangan data sambil secara efisien menggunakan sumber daya penyimpanan terbatas, Anda dapat mengonfigurasi cadangan diferensial serta pencadangan data lengkap. Jika Anda menggunakan SQL Server Always On, Anda dapat mengambil cadangan database sekunder Anda. Anda juga dapat mencoba menggunakan pemadatan pencadangan atau memisahkan pencadangan di beberapa file. Berikut adalah deskripsi singkat tentang opsi pencadangan Anda:

Pencadangan data lengkap (database)

Pencadangan database lengkap diperlukan untuk pemulihan penyebaran Anda. Pencadangan penuh mencakup bagian dari log transaksi sehingga Anda dapat memulihkan pencadangan penuh. Pencadangan penuh serba lengkap di mana mereka mewakili seluruh database seperti yang ada saat Anda mencadangkannya. Untuk informasi selengkapnya, lihat Pencadangan database lengkap.

Cadangan data diferensial (database)

Cadangan database diferensial hanya merekam data yang telah berubah sejak pencadangan database lengkap terakhir, yang disebut pangkalan diferensial. Pencadangan database diferensial lebih kecil dan lebih cepat daripada pencadangan database lengkap. Opsi ini menghemat waktu pencadangan dengan peningkatan kompleksitas sebagai gantinya. Untuk database besar, cadangan diferensial dapat muncul pada interval yang lebih pendek daripada pencadangan database, yang mengurangi paparan kehilangan kerja. Untuk informasi selengkapnya, lihat Pencadangan database diferensial.

Anda juga harus mencadangkan log transaksi Anda secara teratur. Pencadangan ini diperlukan untuk memulihkan data saat Anda menggunakan model pencadangan database lengkap. Jika mencadangkan log transaksi, Anda dapat memulihkan database ke poin kegagalan atau ke poin waktu sebelumnya.

Pencadangan log transaksi

Log transaksi adalah rekaman seri dari semua modifikasi yang telah muncul dalam database sebagai tambahan terhadap transaksi yang melakukan setiap modifikasi. Log transaksi merekam awal setiap transaksi, perubahan pada data, dan, jika perlu, informasi yang cukup untuk membatalkan modifikasi yang dibuat selama transaksi tersebut. Log terus-menerus berkembang karena operasi yang dicatat muncul dalam database.

Dengan mencadangkan log transaksi, Anda dapat memulihkan database ke poin waktu sebelumnya. Misalnya, Anda dapat memulihkan database ke poin sebelum data yang tidak diinginkan dimasukkan atau kegagalan muncul. Selain pencadangan database, pencadangan log transaksi harus menjadi bagian dari strategi pemulihan Anda. Untuk informasi selengkapnya, lihat Pencadangan Log Transaksi (SQL Server).

Pencadangan log transaksi umumnya menggunakan sumber daya yang lebih sedikit daripada pencadangan penuh. Oleh karena itu, Anda dapat membuat pencadangan log transaksi lebih sering daripada pencadangan penuh, yang mengurangi risiko kehilangan data Anda. Namun, terkadang pencadangan log transaksi lebih besar daripada pencadangan penuh. Misalnya, database dengan tingkat transaksi yang tinggi menyebabkan log transaksi berkembang dengan cepat. Dalam situasi ini, Anda harus membuat pencadangan log transaksi lebih sering. Untuk informasi selengkapnya, lihat Memecahkan masalah log transaksi lengkap (Kesalahan 9002 SQL Server).

Anda dapat melakukan jenis pencadangan log transaksi berikut:

  • Pencadangan log murni hanya berisi rekaman log transaksi untuk interval, tanpa perubahan massal apa pun.
  • Pencadangan log massal berisi halaman log dan data yang diubah oleh operasi massal. Pemulihan di titik waktu tidak diperbolehkan.
  • Pencadangan log-ekor diambil dari database yang mungkin rusak untuk mengambil rekaman log yang belum dicadangkan. Pencadangan log-ekor diambil setelah kegagalan untuk mencegah kehilangan pekerjaan dan dapat berisi data log murni atau log massal.

Karena sinkronisasi data sangat penting untuk keberhasilan pemulihan Azure DevOps Server, Anda harus menggunakan transaksi yang ditandai sebagai bagian dari strategi pencadangan jika Anda mengonfigurasi cadangan secara manual. Untuk informasi selengkapnya, lihat Membuat jadwal dan rencana pencadangan dan mencadangkan Azure DevOps Server secara manual.

Pencadangan layanan tingkat aplikasi

Satu-satunya pencadangan yang diperlukan untuk tingkat aplikasi logis adalah terhadap kunci enkripsi untuk Layanan Pelaporan. Jika menggunakan fitur Pencadangan Terjadwal untuk mencadangkan penyebaran Anda, kunci ini akan dicadangkan untuk Anda sebagai bagian dari rencana. Anda mungkin berasumsi bahwa Anda harus mencadangkan situs web yang digunakan sebagai portal proyek.

Meskipun Anda dapat mencadangkan tingkat aplikasi dengan lebih mudah daripada tingkat data, masih ada beberapa langkah untuk memulihkan tingkat aplikasi. Anda harus memasang tahap aplikasi lain untuk Azure DevOps Server, mengalihkan pengumpulan proyek untuk menggunakan tahap aplikasi baru, dan mengalihkan situs portal untuk proyek.

Nama database default

Jika Anda tidak menyesuaikan nama database Anda, Anda dapat menggunakan tabel berikut untuk mengidentifikasi database yang digunakan dalam penyebaran Azure DevOps Server Anda. Seperti disebutkan sebelumnya, tidak semua penyebaran memiliki semua database ini. Misalnya, jika Anda tidak mengonfigurasi Azure DevOps Server dengan Layanan Pelaporan, Anda tidak akan memiliki database ReportServer atau ReportServerTempDB. Demikian pula, Anda tidak akan memiliki database untuk System Center Virtual Machine Manager (SCVMM), VirtualManagerDB, kecuali Anda mengonfigurasi Azure DevOps Server untuk mendukung Manajemen Lab. Sebagai tambahan, database yang Azure DevOps Server gunakan mungkin didistribusikan di lebih dari satu instans SQL Server atau di lebih dari satu server.

Catatan

Secara default, awalan TFS_ ditambahkan ke nama database apa pun yang dibuat secara otomatis saat Anda memasang Azure DevOps Server atau saat beroperasi.

Database Deskripsi
TFS_Configuration Database konfigurasi untuk Azure DevOps Server berisi katalog, nama server, dan data konfigurasi untuk penyebaran. Nama database ini mungkin termasuk karakter tambahan antara TFS_ dan Konfigurasi, seperti nama pengguna orang yang menginstal Azure DevOps Server. Misalnya, nama database mungkin TFS_UserNameConfiguration
TFS_Warehouse Database gudang berisi data untuk membangun gudang yang digunakan Layanan Pelaporan. Nama database ini mungkin termasuk karakter tambahan antara TFS_ dan Gudang, seperti nama pengguna orang yang menginstal Azure DevOps Server. Misalnya, nama database mungkin TFS_UserNameWarehouse.
TFS_CollectionName Database untuk pengumpulan proyek berisi semua data untuk proyek dalam pengumpulan tersebut. Data ini termasuk kode sumber, konfigurasi build, dan konfigurasi manajemen lab. Jumlah database pengumpulan akan sama dengan jumlah pengumpulan. Misalnya, jika Anda memiliki tiga pengumpulan dalam penyebaran Anda, Anda harus mencadangkan ketiga database pengumpulan ini. Nama setiap database mungkin termasuk karakter tambahan antara TFS_ dan CollectionName, seperti nama pengguna orang yang membuat pengumpulan. Misalnya, nama database pengumpulan mungkin TFS_UserNameCollectionName.
TFS_Analysis Database untuk SQL Server Analysis Services berisi sumber data dan kubus untuk penyebaran Azure DevOps Server Anda. Nama database ini mungkin termasuk karakter tambahan antara TFS_ dan Analisis, seperti nama pengguna orang yang menginstal Azure DevOps Server. Misalnya, nama database mungkin TFS_UserNameAnalysis.
Catatan: Anda dapat mencadangkan database ini, tetapi Anda harus membangun kembali gudang dari database TFS_Warehouse yang dipulihkan.
ReportServer Database untuk Layanan Pelaporan berisi pengaturan laporan dan pengaturan laporan untuk penyebaran Azure DevOps Server Anda.
Catatan: Jika Reporting Services diinstal di server terpisah dari Azure DevOps Server, database ini mungkin tidak ada di server tingkat data untuk Azure DevOps Server. Dalam kasus ini, Anda harus mengonfigurasi, mencadangkan, dan memulihkannya secara terpisah dari Azure DevOps Server. Anda harus menyinkronkan pemeliharaan database untuk menghindari kesalahan sinkronisasi.
ReportServerTempDB Database sementara untuk Layanan Pelaporan untuk sementara menyimpan informasi saat Anda menjalankan laporan tertentu.
Catatan: Jika Reporting Services diinstal di server terpisah daripada Azure DevOps Server, database ini mungkin tidak ada di server tingkat data untuk Azure DevOps Server. Dalam kasus ini, Anda harus mengonfigurasi, mencadangkan, dan memulihkannya secara terpisah dari Azure DevOps Server. Namun, Anda harus menyinkronkan pemeliharaan database untuk menghindari kesalahan sinkronisasi.
VirtualManagerDB Database administrasi untuk SCVMM berisi informasi yang Anda lihat di Konsol Administrator SCVMM, seperti mesin virtual, host mesin virtual, server pustaka mesin virtual, dan propertinya.
Catatan: Jika SCVMM diinstal di server terpisah daripada Azure DevOps Server, database ini mungkin tidak ada di server tingkat data untuk Azure DevOps Server. Dalam kasus ini, Anda harus mengonfigurasi, mencadangkan, dan memulihkannya secara terpisah dari Azure DevOps Server. Namun, Anda harus menggunakan transaksi yang ditandai dan menyinkronkan pemeliharaan database untuk menghindari kesalahan sinkronisasi.