Reference · built on requestOperator by FibricIT & reliability

Backup Proof

Checks each protected asset for a completed, recent backup and a passed restore test, and proposes the test restore when proof is missing.

Request accessPricing ↗

About

A backup that has never been restored is a hope, not a plan. Backup Proof starts from your inventory of protected assets, the ServiceNow CMDB or a table you keep in PostgreSQL, and checks each one against what AWS Backup reports: Backup Job State Change events on EventBridge, NumberOfBackupJobsFailed and NumberOfBackupJobsExpired in CloudWatch, and the recovery points that exist in each vault. For databases it reads pg_stat_archiver to confirm WAL archiving has not silently stopped, and for file backups it checks that new objects keep landing in the bucket.

Each asset gets a verdict: backed up and tested, backed up but untested, or missed. For the last two it proposes the next step. A restore testing selection for the asset, a page when the plan is failing, or a ticket when the asset is missing from every plan. You approve; it never starts a restore alone.

This is a reference listing. It documents what Fibric would read from Backup Proof and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Backup Job State Change, Copy Job State Change, and Restore Job State Change events from source aws.backup on your EventBridge bus, with state and statusMessage
  • NumberOfBackupJobsFailed, NumberOfBackupJobsExpired, NumberOfRecoveryPointsPartial, and restore job counts from the AWS/Backup namespace in CloudWatch, by vault and resource type
  • Restore Job State Change events that carry restoreTestingPlanArn, so scheduled restore tests are told apart from ad hoc restores
  • Configuration items in the ServiceNow CMDB through the Table API, or an asset table in PostgreSQL, as the list of what must be protected
  • pg_stat_archiver on each PostgreSQL cluster: last_archived_time, failed_count, and last_failed_wal
  • Object-created events and object metadata under the S3 prefixes where dump files and exports are written

Proposed actions

  • Target capability: propose adding an untested asset to a restore testing selection, with the vault, recovery point window, and retention hours filled in for approval
  • Target capability: propose a PagerDuty alert event when a backup job for a protected asset has failed or expired past the window you set
  • Target capability: propose a Jira issue for each asset in the inventory that no backup plan covers, or whose WAL archiving has stopped
  • Target capability: propose a comment on the asset's CMDB record with the date of its last completed backup and last passed restore

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Prove a database backup can come back

    An RDS instance has completed backups for months and no restore job in its history. Backup Proof proposes adding it to your restore testing selection, and records the Restore Job State Change when the test completes.

    With Amazon EventBridge, ServiceNow

  • Page on the silent expired job

    A backup job moves to EXPIRED because it could not start inside its window, and NumberOfBackupJobsExpired ticks up. The operator matches the resourceArn to a critical asset and proposes a PagerDuty alert.

    With Amazon CloudWatch, PagerDuty

  • Catch WAL archiving that stopped

    last_archived_time on a cluster is a day old and failed_count is rising. Backup Proof proposes a Jira issue with the failing WAL name and the cluster, before the next base backup is needed.

    With PostgreSQL, Jira

  • Find the asset nobody backs up

    A new CMDB record has no backup plan and no recovery points. The operator proposes a ticket to the asset owner and a note on the CMDB record.

    With ServiceNow, Jira

Requirements

  • An EventBridge rule on the default bus that forwards aws.backup events to the EventBridge connector's API destination
  • Read access to the AWS/Backup namespace in CloudWatch for each account and Region that holds a vault
  • An inventory of protected assets: the cmdb_ci tables in ServiceNow or a PostgreSQL table with one row per asset and its backup plan
  • A PostgreSQL role that can read pg_stat_archiver on each cluster to be checked, and S3 list access on dump prefixes
  • A restore testing plan in AWS Backup that proposals can add selections to, and a Jira project for gaps
Authentication
No credential belongs to Backup Proof. Each read and each approved write goes through the EventBridge, CloudWatch, S3, PostgreSQL, ServiceNow, PagerDuty, or Jira connector with that connector's own grant.

Limits

  • AWS Backup emits events and metrics about every 5 minutes, best effort. The Completed with issues status shows only in the console, not in metrics.
  • Restore testing covers the resource types AWS Backup lists for it. Assets outside that list get a ticket, not a test.
  • pg_stat_archiver shows the last archived and last failed WAL file. It does not prove that older files were archived in order.
  • The operator proposes selections, alerts, and tickets. It does not run a restore, delete a recovery point, or change a backup plan's schedule.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Backup Proof ↗

Questions and answers

What am I approving?
A restore testing selection, an alert, or a ticket, one asset at a time. Each proposal shows the asset, the last completed backup, the last restore job if any, and the evidence that triggered it. Retention hours and the target vault are editable before approval.
What proof is left afterwards?
Per asset, a dated record of the backup job, the recovery point, the restore test job and its state, who approved what, and the CMDB comment if one was posted. It reads as a ledger you can hand to an auditor.
Can it start a restore on its own?
No. A restore test starts only when AWS Backup runs the plan that your approved selection joined. The operator never calls StartRestoreJob, never deletes anything, and never changes retention.
Ask about Backup Proof

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy