Usar archivos de copia de seguridad de SQL Server encriptados
Organízate con las colecciones
Guarda y clasifica el contenido según tus preferencias.
Database Migration Service es totalmente compatible con las copias de seguridad cifradas de SQL Server. Puedes subir tu clave de cifrado a Google Cloud para que Database Migration Service pueda descifrar tus datos de forma segura y cargarlos en la instancia de destino de Cloud SQL para SQL Server sin poner en riesgo la seguridad de tus datos.
Si quieres usar archivos de copia de seguridad cifrados, debes cifrar todos los archivos de copia de seguridad (completa, diferencial y de registro de transacciones) que uses para una base de datos específica incluida en tu migración. Es decir, si quieres cifrar el archivo de copia de seguridad completa, también debes cifrar el archivo de copia de seguridad diferencial y los archivos de registro de transacciones que utilices en esa base de datos. Todos los archivos de copia de seguridad deben cifrarse con la misma clave.
El cifrado de copias de seguridad se evalúa por base de datos. Por ejemplo, si migras dos bases de datos de tu instancia de SQL Server de origen: my-business-database y my-other-database, puedes usar copias de seguridad cifradas de forma independiente para my-business-database, my-other-database o ambas bases de datos.
Para usar copias de seguridad cifradas en tu migración, sigue estos pasos:
Crea una copia de seguridad de tu instancia de SQL Server de origen y usa las funciones de cifrado. Guarda tus claves de cifrado en un lugar seguro para subirlas más tarde a Cloud Storage. Consulta
Cifrado de copias de seguridad en la documentación de Microsoft.
Solo en la CLI de Google Cloud: crea un archivo de asignación en formato JSON para asociar las claves de cifrado con las bases de datos correspondientes incluidas en tu trabajo de migración.
El archivo de asignación es una matriz de objetos que representan asignaciones de una sola base de datos. Ejemplo de archivo de configuración:
[{"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 y pvkPassword son rutas de Cloud Storage a los archivos de certificado en formato gs://BUCKET_NAME/OBJECT_NAME.
Por ejemplo: gs://my-bucket-name/certificate-folder/certificate-key-file1.
Para obtener más información, consulta el artículo sobre espacios de nombres de objetos en la documentación de Cloud Storage.
Cuando crees más archivos de copia de seguridad (el archivo de copia de seguridad diferencial o los archivos de registro de transacciones), asegúrate de cifrarlos con la misma clave de cifrado que usaste para la copia de seguridad completa.
[[["Es fácil de entender","easyToUnderstand","thumb-up"],["Me ofreció una solución al problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Es difícil de entender","hardToUnderstand","thumb-down"],["La información o el código de muestra no son correctos","incorrectInformationOrSampleCode","thumb-down"],["Me faltan las muestras o la información que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-08-21 (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."]]
