Recover credentials and storage

Saved database credentials

• Create a labeled credential when protecting a PostgreSQL, MySQL, or Firebase Firestore data source.
• Credentials are encrypted at rest and resolved by the worker only when a backup, validation, or restore job requires them.
• Rename a credential without changing its secret, or rotate the secret and revalidate it before future jobs use it.
• Delete is blocked while a protected database or saved restore target still references the credential.
• Credential creation, rotation, validation failure, and deletion are written to the organization audit log.

Firebase Firestore configuration

• Use a Google service-account JSON configuration for the Firebase project that owns Firestore.
• Add outputUriPrefix, such as gs://company-backups/firestore, or storageBucket so Recover knows where managed exports should be written.
• The service account needs Firestore export/import permissions and access to the configured Google Cloud Storage bucket.
• Private keys, client email, project ID, and storage settings are encrypted together as a tenant credential.

Scratch validation credentials

• Tier two validation imports a backup into a non-production scratch database or Firebase project before marking it restore tested.
• Each organization configures its own scratch target in the Recover storage and credential interface.
• Scratch credentials are tenant scoped and encrypted; workers never use another organization's validation target.
• For Firebase, use a dedicated scratch project and bucket that can be safely overwritten during validation.

Backup storage

• Use the shared Senal platform storage destination or configure an organization-owned S3 compatible destination.
• Storage secrets are encrypted separately from database credentials.
• Retention settings are enforced by schedule and plan limits.
• Firestore exports remain in the configured Google Cloud Storage prefix and are referenced by a validated export manifest.

Related documentation