Usar arquivos de backup criptografados do SQL Server
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 backups
criptografados do SQL Server. É possível fazer upload da chave de criptografia para Google Cloud para que o Database Migration Service descriptografe os dados com segurança e os carregue na instância de destino do Cloud SQL para SQL Server sem comprometer a segurança dos dados.
Se você quiser usar arquivos de backup criptografados, criptografe todos os arquivos de backup
(completo, diferencial, registro de transações) que você usa para um banco de dados específico incluído
na migração. Ou seja, se você quiser criptografar seu arquivo de backup completo, também
precisa criptografar o arquivo de backup diferencial e os arquivos de registro de transações
que você usa para esse banco de dados. Todos os arquivos de backup precisam ser criptografados com a mesma
chave.
A criptografia de backup é avaliada por banco de dados. Por exemplo, se você migrar
dois bancos de dados da instância de origem do SQL Server: my-business-database
e my-other-database, será possível usar backups criptografados de forma independente para
my-business-database, my-other-database ou ambos os bancos de dados.
Para usar backups criptografados na migração, siga estas etapas:
Faça o backup da instância de origem do SQL Server e use
os recursos de criptografia. Salve suas chaves de criptografia em um local seguro para
enviar para o Cloud Storage mais tarde. Consulte
Criptografia de backup na documentação da Microsoft.
Somente na Google Cloud CLI: crie um arquivo de mapeamento no formato JSON para corresponder
as chaves de criptografia aos bancos de dados relevantes incluídos no job de migração.
O arquivo de mapeamento é uma matriz de objetos que representam mapeamentos para
um único banco de dados. Exemplo de arquivo 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 arquivos 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
Namespaces de objetos
na documentação do Cloud Storage.
Forneça os caminhos do Cloud Storage para suas chaves de criptografia ao
criar o job de migração.
Ao criar mais arquivos de backup (o arquivo de backup diferencial ou os arquivos de registro de transações), criptografe-os com a mesma chave de criptografia usada para o backup completo.
[[["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-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."]]
