Best Practices for Rolling Back Merges in a Traditional Versioned Enterprise Geodatabase

[MuhammadAnwar]

Hello,

I have implemented traditional versioning in a PostgreSQL-based Enterprise Geodatabase hosted on GCP. My workflow is as follows:

1. The SDE default version is protected.

2. A child version of default, called custodian, is also protected.

3. Users create child versions of custodian to make their edits, then post changes back to custodian.

4. The custodian version accumulates changes posted from multiple user versions.

5. Finally, the SDE user posts changes from the custodian version to the default version.

I am looking for guidance on how to handle potential rollbacks:

• Custodian Rollback: If the custodian posts user_x’s changes and later finds an issue, is there a way to restore the custodian version to its prior state?

• SDE Default Rollback: Similarly, if the SDE posts changes from the custodian version into default and realizes there is a problem, can the default version be reverted to its previous state?

• Best Practices for Backups: If direct rollbacks are not feasible, what is the recommended approach (e.g., creating backups or snapshots) to restore the geodatabase to a known good state?

Any insights or best practices on managing rollbacks or backups in this multi-level versioning setup would be greatly appreciated. Thank you!

[JakeSkinner · Accepted solution]

Hi @MuhammadAnwar, once you perform the POST operation, you won't be able to get the edits back to the child versions unless you perform a database backup/restore.  I would review the enterprise database information for backing up your PostgreSQL database.  I typically recommend having an automated process to backup your database(s) on a nightly basis at a minimum.

https://www.postgresql.org/docs/8.1/backup.html

[MuhammadAnwar]

Thank you