Reviewed · Hosmio resources
Before you start
Choose a disposable destination and a written test scope. Confirm access to application code, required software versions and approved backup material. Keep the target separate from production, with outbound notifications, scheduled jobs and external writes disabled until deliberately tested.
01
List what must move and what must be recreated.
Include the runtime, database, uploaded files, configuration, scheduled jobs, certificates, DNS ownership and external integrations. Record who controls each dependency and how access can be recovered if the current VPS is unavailable. Identify any supplier-specific feature that needs a replacement rather than a file copy.
Write down the expected versions and extensions. An installation command that retrieves whatever is latest today may not recreate the application you operate. Reference protected secret storage for credentials; a recovery plan should explain how an authorized person retrieves them without putting the secrets in the plan itself.
02
Choose a data-aware export and restore method.
For PostgreSQL, a logical export with pg_dump covers one database, while global objects such as roles need separate treatment. The tool refuses to dump a server from a newer major version than the client supports. The official documentation also cautions against treating pg_dump as a universal regular-production backup strategy. PostgreSQL: pg_dump ↗
Choose the method appropriate to your application and recovery needs with its operator. Record what the export omits and how files are kept consistent with database references. A command returning successfully is a useful first check, not proof that a complete application has been preserved.
03
Restore into an explicitly separate target.
Inspect the archive and destination before restoring. PostgreSQL archive restoration uses pg_restore; options that clean existing objects can remove data, and its default behavior can continue after SQL errors. Plan error handling and inspect the result rather than assuming every object was restored. PostgreSQL: pg_restore ↗ Do not run a tutorial against the production database simply because its name is familiar.
For file backups, select the intended snapshot and an empty test destination. Restic documents that restoration can overwrite existing files; an interrupted overwrite may leave a partial result. restic: restoring from backup ↗ Record the source snapshot and target path in the exercise note. These are method-selection guidelines, not commands executed or verified against a Hosmio VPS.
04
Check user tasks and hidden side effects.
| Check | Evidence to retain | Result |
|---|---|---|
| Application starts with the documented versions | Version inventory and startup result | Not yet tested |
| Representative records and files agree | Synthetic record and attachment checks | Not yet tested |
| Permissions behave correctly | Two test roles and expected access | Not yet tested |
| Jobs do not send duplicate external work | Outbound actions disabled or controlled test | Not yet tested |
| Replacement operator can follow the notes | Independent walkthrough and gaps | Not yet tested |
Use synthetic accounts and harmless test records wherever possible. Verify access boundaries as well as successful reads. An application that starts but grants the wrong permissions is not a successful recovery. Keep failed checks in the record with an owner for remediation.
05
Plan the point at which new writes change the decision.
A rehearsal should inform the future move’s sequence: final consistency step, destination checks, traffic switch, acceptance decision and old-service retirement. Decide who can stop or reverse the operation. If the destination has accepted new writes, sending users back to an old copy may lose or split those writes; rollback needs a data plan, not just a DNS change.
Allow for overlap in the budget. A second server, independent storage, traffic charges, licenses and operator time may be needed. Do not assume a supplier prorates either VPS or that prepaid funds are refundable. Hosmio’s published period prices describe upfront terms; they do not define a migration or refund service.
06
Leave evidence that another operator can use.
Record the exercise date, versions, copy identifiers, target, elapsed effort and results only after the exercise is actually performed. Until then use “planned” or “not tested”. Keep the acceptance sheet with the recovery notes and list dependencies that still prevent an independent rebuild.
If the rehearsal fails, classify the gap: missing data, incompatible software, unavailable credentials, an external dependency or an unclear procedure. Resolve the smallest blocking issue, then repeat the affected check. Do not call the application portable while a critical task remains untested.
Connect the plan to named operating responsibilities and the client’s change-approval process. The intended result is a demonstrated ability to recover within a documented scope, not a promise of zero interruption or an automatically delivered migration.