Summary
The backup-strategy framework (backups.cozystack.io + strategy.backups.cozystack.io)
ships native drivers for Postgres (CNPG), MariaDB (MariaDB), ClickHouse
(Altinity), Etcd (Etcd), FoundationDB (FoundationDB), plus the generic
Velero and Job strategies. MongoDB has no native driver, even though
cozystack ships the Percona psmdb operator, which provides its own
PerconaServerMongoDBBackup / PerconaServerMongoDBRestore CRDs.
As a result a managed MongoDB app can only be backed up either:
- via the
Velero strategy — a crash-consistent PVC snapshot at the app level; or
- via a hand-written generic
Job strategy running mongodump.
There is no logical, engine-native backup through the unified
BackupJob / RestoreJob API, and therefore no PITR and no
restore-into-a-differently-named instance (both of which the native DB drivers
like CNPG provide).
Current state
- No
mongodbs.strategy.backups.cozystack.io kind. The BackupJob / RestoreJob
dispatch handles only Job, Velero, CNPG, Altinity, MariaDB,
FoundationDB, Etcd.
cozy-default BackupClass has no MongoDB mapping.
- The shipped
psmdb operator already exposes
PerconaServerMongoDBBackup / PerconaServerMongoDBRestore, which a driver
could orchestrate — analogous to the CNPG driver wrapping
cnpg.io/Backup, MariaDB wrapping the mariadb-operator, and Altinity
wrapping clickhouse-backup.
Why it matters
MongoDB is offered as a managed application, but its backup story is
inconsistent with the other managed databases: users get only crash-consistent
PVC snapshots or must build and maintain their own mongodump Job strategy.
There is no declarative, engine-native path and no point-in-time / cross-instance
restore.
Proposal
- Add a MongoDB backup-strategy driver (e.g. kind
MongoDB under
strategy.backups.cozystack.io) that drives the psmdb operator's
PerconaServerMongoDBBackup / PerconaServerMongoDBRestore.
- Wire it into the
BackupJob / RestoreJob dispatch and the supported-kinds
list.
- Add a
Postgres-style MongoDB mapping to the cozy-default BackupClass.
Summary
The backup-strategy framework (
backups.cozystack.io+strategy.backups.cozystack.io)ships native drivers for Postgres (
CNPG), MariaDB (MariaDB), ClickHouse(
Altinity), Etcd (Etcd), FoundationDB (FoundationDB), plus the genericVeleroandJobstrategies. MongoDB has no native driver, even thoughcozystack ships the Percona
psmdboperator, which provides its ownPerconaServerMongoDBBackup/PerconaServerMongoDBRestoreCRDs.As a result a managed MongoDB app can only be backed up either:
Velerostrategy — a crash-consistent PVC snapshot at the app level; orJobstrategy runningmongodump.There is no logical, engine-native backup through the unified
BackupJob/RestoreJobAPI, and therefore no PITR and norestore-into-a-differently-named instance (both of which the native DB drivers
like CNPG provide).
Current state
mongodbs.strategy.backups.cozystack.iokind. The BackupJob / RestoreJobdispatch handles only
Job,Velero,CNPG,Altinity,MariaDB,FoundationDB,Etcd.cozy-defaultBackupClass has no MongoDB mapping.psmdboperator already exposesPerconaServerMongoDBBackup/PerconaServerMongoDBRestore, which a drivercould orchestrate — analogous to the
CNPGdriver wrappingcnpg.io/Backup,MariaDBwrapping the mariadb-operator, andAltinitywrapping
clickhouse-backup.Why it matters
MongoDB is offered as a managed application, but its backup story is
inconsistent with the other managed databases: users get only crash-consistent
PVC snapshots or must build and maintain their own
mongodumpJob strategy.There is no declarative, engine-native path and no point-in-time / cross-instance
restore.
Proposal
MongoDBunderstrategy.backups.cozystack.io) that drives the psmdb operator'sPerconaServerMongoDBBackup/PerconaServerMongoDBRestore.BackupJob/RestoreJobdispatch and the supported-kindslist.
Postgres-style MongoDB mapping to thecozy-defaultBackupClass.