A rollback is only one part of recovery.

Restoring application code and restoring persistent data solve different problems. Plan both before a workload becomes important to your team.

Separate code from data.

Returning to an earlier application release does not automatically undo a database migration or recover deleted files. Check compatibility between old application code and the current data schema.

Define the recovery set.

Identify databases, uploaded files, configuration and the authority needed to decrypt protected material. A backup that cannot be decrypted or connected to the correct application state is not sufficient.

Test restoration.

Restore into an isolated environment and verify application behavior. Record what was recovered and which dependencies were needed. Set recovery objectives only after the process has been measured and agreed.

Understand what DOCKOCK provides.

DOCKOCK does not currently provide customer backup or restore actions. Use a separately managed, tested recovery process. Confirm that data can actually be restored before relying on a backup.

DOCKOCK FIELD GUIDE