Use ficheiros de cópias de segurança do SQL Server encriptados
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
O Database Migration Service é totalmente compatível com cópias de segurança do SQL Server encriptadas. Pode carregar a sua chave de encriptação para o Google Cloud para que o serviço de migração de base de dados possa desencriptar em segurança os seus dados e carregá-los na instância de destino do Cloud SQL para SQL Server sem comprometer a segurança dos seus dados.
Se quiser usar ficheiros de cópia de segurança encriptados, tem de encriptar todos os ficheiros de cópia de segurança (completa, diferencial e registo de transações) que usar para uma base de dados específica incluída na sua migração. Ou seja, se quiser encriptar o ficheiro de cópia de segurança completa, também tem de encriptar o ficheiro de cópia de segurança diferencial e os ficheiros de registo de transações que usa para essa base de dados. Todos os ficheiros de cópia de segurança têm de ser encriptados com a mesma chave.
A encriptação de cópias de segurança é avaliada por base de dados. Por exemplo, se migrar duas bases de dados da sua instância do SQL Server de origem: my-business-database e my-other-database, pode usar cópias de segurança encriptadas de forma independente para my-business-database, my-other-database ou ambas as bases de dados.
Para usar cópias de segurança encriptadas para a sua migração, siga estes passos:
Faça uma cópia de segurança da instância do SQL Server de origem e use as funcionalidades de encriptação. Guarde as suas chaves de encriptação num local seguro para as carregar mais tarde para o Cloud Storage. Consulte a secção
Encriptação de cópias de segurança na documentação da Microsoft.
Apenas na CLI Google Cloud: crie um ficheiro de mapeamento no formato JSON para fazer corresponder as chaves de encriptação às respetivas bases de dados incluídas na tarefa de migração.
O ficheiro de mapeamento é uma matriz de objetos que representam mapeamentos para uma única base de dados. Exemplo de ficheiro de configuração:
[{"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 são caminhos do Cloud Storage para os ficheiros de certificado no formato gs://BUCKET_NAME/OBJECT_NAME.
Por exemplo: gs://my-bucket-name/certificate-folder/certificate-key-file1.
Para mais informações, consulte a secção
Namespaces de objetos
na documentação do Cloud Storage.
Quando criar mais ficheiros de cópia de segurança (o ficheiro de cópia de segurança diferencial ou os ficheiros de registo de transações), certifique-se de que os encripta com a mesma chave de encriptação que usou para a cópia de segurança completa.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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."]]
