Your helpdesk quietly becomes the memory of your whole support operation - every customer conversation, every promise, every attachment. Losing it is worse than losing the mail server, because the mail server never knew what was said. This page backs it up completely: all three parts, not just the obvious one.
Most OTRS backups fail the same quiet way: someone dumps the database, calls it done, and discovers during a restore that the configuration - mail accounts, queue settings, months of tuning - and the attachments were never in the file. A complete backup of this system has three parts, and each lives somewhere different. Capture all three, keep a copy off the server, and do the step almost nobody does: prove the restore works before you need it.
Before backing anything up, check one setting: this system can store ticket attachments inside the database or as files on disk under the article storage in the var folder. If they are in the database, a database dump genuinely contains them. If they are on disk - common on busier systems, where it keeps the database lean - a database-only backup silently leaves every attachment behind. Five minutes checking this setting decides whether your backup is complete or a convincing fake.
The database holds the tickets, the customers, the agents and the full history of every conversation. On MariaDB or MySQL, a dump is one command: mysqldump -u root -p otrs > otrs-backup.sql - adjust the database name if yours differs. On PostgreSQL the equivalent is pg_dump otrs > otrs-backup.sql. Run it nightly from a scheduled job, keep several dated copies rather than overwriting yesterday's, and watch the file size - a dump that suddenly shrinks is a warning, not a saving.
The configuration is what turns a fresh install back into your helpdesk: the main config file Kernel/Config.pm, your system configuration changes, templates and the var folder with its article storage and logs. One archive can hold the lot: tar -czf otrs-files-backup.tar.gz /opt/otrs/Kernel /opt/otrs/var. Take this archive after every meaningful admin change and always before an upgrade - upgrades are the moment a known-good config backup pays for itself.
Restore the backup once onto a spare machine or virtual machine: install the same version, load the database dump, unpack the file archive, start the system and log in. Check three things - old tickets open, attachments download, and mail settings are present. Time how long it takes and write the steps down. A backup that has never been restored is not a backup; it is a hope with a file name. After this test, you own a procedure, and procedures are what save you at 2 AM.
The full OTRS helpdesk installation with every screen shown live - server, database, installer and first login.
▶ Watch Full VideoIt depends on a system setting. Attachments can live inside the database or as files in the article storage under the var folder. Check which mode your system uses before trusting a database-only backup - on disk mode, the attachments are not in the dump.
For an active desk, nightly database dumps are the sensible floor, with the file archive taken after configuration changes and before every upgrade. The real measure is simple: how much ticket history could you afford to lose - a day is usually the honest answer.
Yes, for typical small and medium systems a database dump runs fine while the desk is live, and it is normally scheduled for a quiet hour anyway. Just make sure the job's success is checked - a dump that started failing a month ago protects nothing.