bookmark_borderbookmark
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Database Migration Service ist vollständig mit verschlüsselten SQL Server-Sicherungen kompatibel. Sie können Ihren Verschlüsselungsschlüssel auf Google Cloud hochladen, damit der Database Migration Service Ihre Daten sicher entschlüsseln und in die Cloud SQL for SQL Server-Zielinstanz laden kann, ohne die Datensicherheit zu gefährden.
Wenn Sie verschlüsselte Sicherungsdateien verwenden möchten, müssen Sie alle Sicherungsdateien (Vollsicherung, Differenzsicherung, Transaktionsprotokoll) verschlüsseln, die Sie für eine bestimmte Datenbank verwenden, die in der Migration enthalten ist. Wenn Sie also die Datei mit der Vollsicherung verschlüsseln möchten, müssen Sie auch die Datei mit der Differenzsicherung und die Transaktionslogdateien verschlüsseln, die Sie für diese Datenbank verwenden. Alle Sicherungsdateien müssen mit demselben Schlüssel verschlüsselt werden.
Die Sicherungsverschlüsselung wird pro Datenbank ausgewertet. Wenn Sie beispielsweise zwei Datenbanken aus Ihrer Quell-SQL-Serverinstanz my-business-database und my-other-database migrieren, können Sie verschlüsselte Sicherungen unabhängig für my-business-database, my-other-database oder beide Datenbanken verwenden.
So verwenden Sie verschlüsselte Sicherungen für die Migration:
Erstellen Sie eine Sicherung Ihrer SQL Server-Quell-Instanz und verwenden Sie die Verschlüsselungsfunktionen. Speichern Sie Ihre Verschlüsselungsschlüssel an einem sicheren Ort, um sie später in Cloud Storage hochzuladen. Weitere Informationen finden Sie in der Microsoft-Dokumentation unter
Sicherungsverschlüsselung.
Nur Google Cloud-Befehlszeile: Erstellen Sie eine Zuordnungsdatei im JSON-Format, um die Verschlüsselungsschlüssel mit den entsprechenden Datenbanken in Ihrem Migrationsjob abzugleichen.
Die Zuordnungsdatei ist ein Array von Objekten, die jeweils Zuordnungen für eine einzelne Datenbank darstellen. Beispielkonfigurationsdatei:
[{"database":"db1","encryptionOptions":{"certPath":"Path to certificate 1","pvkPath":"Path to certificate private key 1","pvkPassword":"Private key password 1"}},{"database":"db2","encryptionOptions":{"certPath":"Path to certificate 2","pvkPath":"Path to certificate private key 2","pvkPassword":"Private key password 2"}}]
certPath, pvkPath und pvkPassword sind Cloud Storage-Pfade zu den Zertifikatsdateien im Format gs://BUCKET_NAME/OBJECT_NAME.
Beispiel: gs://my-bucket-name/certificate-folder/certificate-key-file1.
Weitere Informationen finden Sie unter Objekt-Namespaces in der Cloud Storage-Dokumentation.
Geben Sie die Cloud Storage-Pfade zu Ihren Verschlüsselungsschlüsseln an, wenn Sie den
Migrationsjob erstellen.
Wenn Sie weitere Sicherungsdateien erstellen (die Differenzsicherungsdatei oder die Transaktionsprotokolldateien), verschlüsseln Sie sie mit demselben Verschlüsselungsschlüssel, den Sie für die vollständige Sicherung verwendet haben.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-01 (UTC)."],[[["\u003cp\u003eDatabase Migration Service supports encrypted SQL Server backups, allowing secure data transfer to Cloud SQL by decrypting data using user-provided encryption keys.\u003c/p\u003e\n"],["\u003cp\u003eIf encrypting backups, all backup files (full, differential, transaction log) for a specific database must be encrypted using the same key.\u003c/p\u003e\n"],["\u003cp\u003eEncryption can be applied independently per database during migration, offering flexibility in securing different databases.\u003c/p\u003e\n"],["\u003cp\u003eTo use encrypted backups, users must first encrypt backups on their source SQL Server, upload encryption keys to Cloud Storage, and then map the keys to the respective databases during migration setup.\u003c/p\u003e\n"],["\u003cp\u003eWhen creating additional backup files, they must also be encrypted with the same key used for the initial full backup.\u003c/p\u003e\n"]]],[],null,["# Use encrypted SQL Server backup files\n\nDatabase Migration Service is fully compatible with encrypted\nSQL Server backups. You can upload your\nencryption key to Google Cloud so that Database Migration Service can safely decrypt\nyour data and load it to the Cloud SQL for SQL Server destination instance without\ncompromising your data security.\n\nIf you want to use encrypted backup files, you must encrypt **every backup file**\n(full, differential, transaction log) you use for a specific database included\nin your migration. That is, if you want to encrypt your full backup file, then\nyou must also encrypt the differential backup file and the transaction log files\nyou use for that database. All backup files must be encrypted with the same\nkey.\n\nBackup encryption is evaluated per database. For example, if you migrate\ntwo databases from your source SQL Server instance: `my-business-database`\nand `my-other-database`, you can use encrypted backups independently for\n`my-business-database`, or `my-other-database`, or both databases.\n\nTo use encrypted backups for your migration, perform the following steps:\n\n1. Take the backup of your source SQL Server instance and use\n the encryption features. Save your encryption keys in a safe location to\n upload them later to Cloud Storage. See\n [Backup encryption](https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/backup-encryption) in Microsoft documentation.\n\n2. [Upload the encryption keys](/storage/docs/uploading-objects)\n to a Cloud Storage bucket.\n\n3. **Google Cloud CLI only**: Create a mapping file in the JSON format to match\n the encryption keys with their relevant databases included in your migration job.\n The mapping file is an array of objects that each represent mappings for\n a single database. Example configuration file:\n\n [\n {\n \"database\": \"db1\",\n \"encryptionOptions\": {\n \"certPath\": \"Path to certificate 1\",\n \"pvkPath\": \"Path to certificate private key 1\",\n \"pvkPassword\": \"Private key password 1\"\n }\n },\n {\n \"database\": \"db2\",\n \"encryptionOptions\": {\n \"certPath\": \"Path to certificate 2\",\n \"pvkPath\": \"Path to certificate private key 2\",\n \"pvkPassword\": \"Private key password 2\"\n }\n }\n ]\n\n Where:\n - `database` is your database identifier. That identifier must match the [database folder names in your Cloud Storage](/database-migration/docs/sqlserver/storage-buckets).\n - `certPath`, `pvkPath` and `pvkPassword` are Cloud Storage paths to the certificate files in the format `gs://BUCKET_NAME/OBJECT_NAME`. For example: `gs://my-bucket-name/certificate-folder/certificate-key-file1`. For more information, see [Object namespaces](/storage/docs/objects#namespace) in the Cloud Storage documentation.\n4. Provide the Cloud Storage paths to your encryption keys when you\n [create the migration job](/database-migration/docs/sqlserver/create-migration-job).\n\n5. When you create more backup files (the differential backup file or transaction\n log files), make sure you encrypt then with the same encryption key you used\n for the full backup."]]
