Database backups on Hostwolf Apps: how they work and how to restore

Hostwolf Apps supports scheduled database backups through its Coolify-based panel. A backup is a recovery point for the selected database data. It is not a copy of your entire application: repository code, environment secrets and files outside the database need their own recovery arrangements.

Check the schedule for each database

Open your project, select the database resource and open its backup settings. Inspect the existing schedule or create one. Backup schedules belong to individual database resources; an application deployment does not set a schedule for every database it uses.

In Backup schedule, choose what to include and when the backup runs. PostgreSQL supports selecting all databases or specific databases. Make sure the application database is included. Check the schedule's timezone and timeout rather than assuming a cron expression runs in your local timezone.

Enable the schedule and use Back up now to verify it. The database must be running. Open the execution history and confirm that the job completed successfully. An enabled schedule alone is not evidence that a recoverable backup exists.

Choose the frequency based on how much recent data you could afford to lose. A nightly backup can leave nearly a day's changes outside your most recent recovery point; it does not provide continuous point-in-time recovery.

Local disk and optional S3 storage

Local backups are stored on the database server's disk. That can help recover from an accidental data change, but losing the server or its disk can also lose its local backups.

For a separate copy, add and validate an S3-compatible storage destination in the console. Return to the backup's S3 storage settings, select the destination and enable S3 uploads. Keep bucket credentials restricted to the operations and location needed for these backups.

The Local copy setting lets you keep the local backup or delete it after an S3 upload. Choose deliberately: deleting local copies changes where you must retrieve recovery data. Check the execution's local and S3 storage status; a successful local dump with an S3 warning does not prove that the remote copy was uploaded.

Retention is configurable

The retention screen has separate local and S3 limits for Backups to keep, Days to keep and Maximum storage (GB). The first reached limit removes the oldest backup. A value of 0 means that particular retention limit is unlimited; it does not mean there is unlimited disk capacity.

There is no universal retention period to assume for every resource. Inspect the settings on your own schedule. For example, keeping seven backups with a daily schedule is different from keeping seven backups with an hourly schedule. Leave storage headroom and check that older copies are being removed as intended.

Backups are not a permanent archive. Download copies you need before deleting a server or before its paid period ends. If you use your own S3 destination, verify its lifecycle policy as well as the panel's retention settings.

Restore a backup and verify the result

A restore can overwrite existing data. First test with a separate PostgreSQL resource and pause writes before restoring into production.

1. Choose a completed backup in the execution history. Confirm its timestamp, selected database and available storage location, and obtain the backup file or its S3 location.
2. Start the target database resource. The restore screen requires a running database.
3. Open the target database's Restore database screen. Choose the file option for a local backup or the S3 option for an available remote backup. Select the file or storage object and the target database.
4. Review the restore configuration. PostgreSQL archive and SQL backups have different restore behavior. Options that drop matching objects or recreate the database are destructive. Restoring ownership and grants requires the corresponding roles to exist on the target.
5. Confirm the restore and read Database Restore Output. Wait for successful completion before connecting the application.
6. Verify important tables, recent records and application queries. If the target connection or credentials changed, update the application's DATABASE_URL and redeploy before reopening writes.

A full restore may change administrator passwords. Update the database configuration if that happens. Keep a fresh pre-restore backup of the existing target when it contains data you may need to recover.

Record how long your test took and the checks you used. Repeat it after changing database versions, backup formats or storage destinations. A backup becomes useful evidence only when you can restore it and verify the result.

For application context, see Hostwolf Apps and the Node.js with PostgreSQL guide.