SQLite is not the risk. Unverified backups are.

SQLite works well for many small blogs. The real risk is assuming that copying database.db once in a while is enough. A backup that has never been restored is only a hope.

Back up the complete system state

A blog usually stores content in the database, media files in static/uploads/, and runtime settings in .env. Restoring only the database may bring posts back but lose images or configuration such as contact email, site settings, and ad records.

Verify every backup

After a backup is created, check that the archive exists, has a reasonable size, can be listed, and contains the expected database and upload files. Then open the SQLite file and run a simple query. This catches permission and cron-user problems early.

Restore somewhere safe

Never test restore by overwriting production. Extract the archive into a temporary directory or local environment. Verify the homepage, article pages, image paths, and admin settings.

Keep several versions

Keep recent daily backups, weekly backups, and monthly backups. A single latest backup may already contain corrupted or accidentally deleted data.

Takeaway

Reliable backup means more than producing a file. It means the database, uploads, and configuration are saved together, verified, and periodically restored in a safe environment.