We currently overwrite the production settings.php with uncloaked DB credentials during a backup, and then overwrite it again with the cloaking back in place. We'd be better off generating a new settings.php (without cloaking) and just injecting that into our tarball (prior to gzipping). Besides the fact that the credentials aren't cloaked during backups, this makes it difficult to properly handle anything we inject into settings.php.

For example, in hosting_s3 (see: #2412563: amazon s3 storage service) we inject a bucket name into settings.php for use with amazons3. For backups, we create a new bucket and sync the contents. Ideally, we'd be able to alter this in hook_provision_drupal_config(), when generating the settings.php for the backup. However, since it's re-written in-place, we'd actually be pointing the live site to the backup bucket for the duration of the backup. This forced us to manually extract the settings.php from the backup (interrupting gzipping, in order to do so), alter the file, and re-append it to the tarball (see this commit).

Unfortunately, we couldn't even create a new settings.php, hence: #2460443: allow writing config files to arbitrary locations on the fly. Once that issue is fixed, we should write a temporary settings.php for backups, and leave the live one alone.