Utiliser des fichiers de sauvegarde SQL Server chiffrés
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Database Migration Service est entièrement compatible avec les sauvegardes SQL Server chiffrées. Vous pouvez importer votre clé de chiffrement dans Google Cloud afin que Database Migration Service puisse déchiffrer vos données de manière sécurisée et les charger dans l'instance de destination Cloud SQL pour SQL Server sans compromettre la sécurité de vos données.
Si vous souhaitez utiliser des fichiers de sauvegarde chiffrés, vous devez chiffrer tous les fichiers de sauvegarde (complète, différentielle, journal des transactions) que vous utilisez pour une base de données spécifique incluse dans votre migration. Autrement dit, si vous souhaitez chiffrer votre fichier de sauvegarde complète, vous devez également chiffrer le fichier de sauvegarde différentielle et les fichiers de journal des transactions que vous utilisez pour cette base de données. Tous les fichiers de sauvegarde doivent être chiffrés avec la même clé.
Le chiffrement des sauvegardes est évalué par base de données. Par exemple, si vous migrez deux bases de données à partir de votre instance SQL Server source: my-business-database et my-other-database, vous pouvez utiliser des sauvegardes chiffrées indépendamment pour my-business-database, my-other-database ou les deux bases de données.
Pour utiliser des sauvegardes chiffrées pour votre migration, procédez comme suit:
Effectuez la sauvegarde de votre instance SQL Server source et utilisez les fonctionnalités de chiffrement. Enregistrez vos clés de chiffrement dans un emplacement sécurisé pour les importer ultérieurement dans Cloud Storage. Consultez la section
Chiffrement des sauvegardes dans la documentation Microsoft.
CLI Google Cloud uniquement: créez un fichier de mappage au format JSON pour faire correspondre les clés de chiffrement à leurs bases de données pertinentes incluses dans votre tâche de migration.
Le fichier de mappage est un tableau d'objets qui représentent chacun des mappages pour une seule base de données. Exemple de fichier de configuration:
[{"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 et pvkPassword sont des chemins Cloud Storage vers les fichiers de certificat au format gs://BUCKET_NAME/OBJECT_NAME.
Exemple : gs://my-bucket-name/certificate-folder/certificate-key-file1.
Pour en savoir plus, consultez la section Espaces de noms d'objets dans la documentation de Cloud Storage.
Lorsque vous créez d'autres fichiers de sauvegarde (le fichier de sauvegarde différentielle ou les fichiers de journal des transactions), assurez-vous de les chiffrer avec la même clé de chiffrement que celle utilisée pour la sauvegarde complète.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/05 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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."]]
