Background
With the new Porch re-architecture, PackageRevision CRs are stored in etcd and no longer reside in the Porch Cache DB. The Porch Cache DB now serves the following role:
-
Approved PackageRevision resources (package content, not the CR itself) are stored in the Porch Cache DB. These can be repopulated from Git during a restore operation, as approved package revisions are committed to Git upon approval.
-
Unapproved PackageRevision resources are stored only in the Porch Cache DB. Since unapproved package revisions have not yet been committed to Git, they cannot be repopulated from Git.
Porch Cache DB is expected to hold GiB(s) of data related to approved package revisions. Taking a full backup of the Porch Cache DB at scale introduces the following concerns:
-
Full backup operations are time-consuming and operationally expensive.
-
A full backup unnecessarily includes approved package revision data that is already safely recoverable from Git, increasing backup size without adding recovery value.
-
A large backup size directly increases the Recovery Point Objective (RPO) and RTO (recovery time objective), which is undesirable from a resilience and availability standpoint.
Requirement
The Porch backup mechanism shall support a selective backup strategy for the Porch Cache DB with the following constraints:
-
Selective backup scope: The backup of Porch Cache DB shall be limited exclusively to data associated with unapproved PackageRevisions. Approved PackageRevision data stored in Porch Cache DB shall be excluded from the backup, as it is recoverable from Git. The selective backup shall ensure that all unapproved PackageRevision resources stored in the Porch Cache DB are captured and can be fully restored, since these resources are not stored in Git and cannot be recovered by any other means.
-
No full backup of Porch Cache DB: A full backup of the Porch Cache DB shall not be required or performed as part of the standard backup procedure, given that approved package revision content can be repopulated from Git during restore.
Background
With the new Porch re-architecture, PackageRevision CRs are stored in etcd and no longer reside in the Porch Cache DB. The Porch Cache DB now serves the following role:
Approved PackageRevision resources (package content, not the CR itself) are stored in the Porch Cache DB. These can be repopulated from Git during a restore operation, as approved package revisions are committed to Git upon approval.
Unapproved PackageRevision resources are stored only in the Porch Cache DB. Since unapproved package revisions have not yet been committed to Git, they cannot be repopulated from Git.
Porch Cache DB is expected to hold GiB(s) of data related to approved package revisions. Taking a full backup of the Porch Cache DB at scale introduces the following concerns:
Full backup operations are time-consuming and operationally expensive.
A full backup unnecessarily includes approved package revision data that is already safely recoverable from Git, increasing backup size without adding recovery value.
A large backup size directly increases the Recovery Point Objective (RPO) and RTO (recovery time objective), which is undesirable from a resilience and availability standpoint.
Requirement
The Porch backup mechanism shall support a selective backup strategy for the Porch Cache DB with the following constraints:
Selective backup scope: The backup of Porch Cache DB shall be limited exclusively to data associated with unapproved PackageRevisions. Approved PackageRevision data stored in Porch Cache DB shall be excluded from the backup, as it is recoverable from Git. The selective backup shall ensure that all unapproved PackageRevision resources stored in the Porch Cache DB are captured and can be fully restored, since these resources are not stored in Git and cannot be recovered by any other means.
No full backup of Porch Cache DB: A full backup of the Porch Cache DB shall not be required or performed as part of the standard backup procedure, given that approved package revision content can be repopulated from Git during restore.