OJS backup guide

An Open Journal Systems (OJS) backup is not optional once you accept submissions. Lost databases or files directories mean lost manuscripts, reviewer history, and published galleys — often with no way to reconstruct DOIs cleanly.

What to back up in OJS

• MySQL/MariaDB database — full dump (all journals on the install)
• OJS files directory — submissions, revisions, private files, and production assets
• Public uploads and any custom plugins or themes you maintain yourself
• config.inc.php — store securely; it contains credentials and paths

How often to back up

• Daily database dumps for active journals
• Daily or continuous files sync if editors upload large PDF packages
• Retain multiple generations (for example 7–30 days) so a bad deploy does not overwrite the only good copy

Practice restores

A backup you have never restored is unproven. Schedule quarterly restore tests on a staging host: import the database, point the files path, verify login, and open a recent submission with its files intact.

Common backup mistakes

• Backing up only the database and forgetting the files directory
• Storing backups on the same disk as the live journal
• Never testing SMTP and HTTPS after a restore
• Excluding custom plugins that submissions depend on

Need managed hosting with automated backups? See managed hosting & migration, the OJS hosting guide, or contact us.