Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Database Migration Service è completamente compatibile con i backup di SQL Server criptati. Puoi caricare la chiave di crittografia su Google Cloud in modo che Database Migration Service possa decriptare in sicurezza i tuoi dati e caricarli nell'istanza di destinazione Cloud SQL per SQL Server senza compromettere la sicurezza dei dati.
Se vuoi utilizzare file di backup criptati, devi criptare ogni file di backup (completo, differenziale, log delle transazioni) che utilizzi per un database specifico incluso nella migrazione. In altre parole, se vuoi criptare il file di backup completo, devi criptare anche il file di backup differenziale e i file dei log delle transazioni che utilizzi per quel database. Tutti i file di backup devono essere criptati con la stessa chiave.
La crittografia dei backup viene valutata per database. Ad esempio, se esegui la migrazione di due database dall'istanza SQL Server di origine: my-business-database e my-other-database, puoi utilizzare i backup criptati in modo indipendente per my-business-database, my-other-database o per entrambi i database.
Per utilizzare i backup criptati per la migrazione, svolgi i seguenti passaggi:
Esegui il backup dell'istanza SQL Server di origine e utilizza
le funzionalità di crittografia. Salva le chiavi di crittografia in una posizione sicura per caricarle in un secondo momento su Cloud Storage. Consulta
Crittografia dei backup nella documentazione di Microsoft.
Solo Google Cloud CLI: crea un file di mappatura in formato JSON per associare le chiavi di crittografia ai relativi database pertinenti inclusi nel job di migrazione.
Il file di mappatura è un array di oggetti che rappresentano ciascuno le mappature per un singolo database. File di configurazione di esempio:
[{"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 e pvkPassword sono percorsi di Cloud Storage
ai file del certificato nel formato gs://BUCKET_NAME/OBJECT_NAME.
Ad esempio: gs://my-bucket-name/certificate-folder/certificate-key-file1.
Per ulteriori informazioni, consulta Spazi dei nomi degli oggetti nella documentazione di Cloud Storage.
Quando crei altri file di backup (il file di backup differenziale o i file di log delle transazioni), assicurati di criptarli con la stessa chiave di crittografia utilizzata per il backup completo.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-05 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."]]
