The day the Snipe-IT server dies, your backup decides whether you lost a program or lost the company's memory. A real backup of this system is three pieces — here is the complete set.
Snipe-IT feels like one application, but its value is stored in three separate places, and a backup that misses any one of them is a partial rescue at best. The database holds every asset, person, checkout and licence. The uploaded files hold asset photos, company logos, label and file attachments. The .env file holds the configuration — including the APP_KEY that encrypts sensitive data, without which parts of a restored database are unreadable. This guide covers backing up all three, using the built-in backup feature honestly, and the only proof a backup exists: a restore you have actually performed.
Everything structured lives in MySQL or MariaDB: assets, people, history, licences, settings. Back it up with a plain dump — on a manual install, mysqldump -u snipeit -p snipeit > snipeit-backup.sql produces one file containing the whole register's memory. On the Docker route, the database lives in its own container and volume; dump it from there with the same mysqldump run inside that container, or through the compose tooling. Schedule it — nightly is a sane default for a register that changes daily — and keep several generations, not just the latest, because the corruption you discover on Friday may have entered on Tuesday.
The database knows an asset has a photo; the photo itself lives in the application's file storage (the storage area and public uploads — asset images, logos, imported files, attachments). A backup of only the database restores a register whose every picture and attachment is a broken link. So the second piece of every backup is a copy of those upload directories, taken at the same time as the dump — a database from Tuesday restored beside files from Friday is a small, confusing lie. On Docker installs this is the data volume's job: make sure your backup process includes the volume's contents, not just the container definitions.
The piece almost everyone forgets, once, and never again: the .env file. It holds your site settings and, critically, the APP_KEY — the encryption key generated at install time (php artisan key:generate). Sensitive values in the database are encrypted with this key. Restore a perfect database and perfect files onto a fresh install with a different key, and those encrypted values cannot be read — the register opens, and pieces of it are silently broken. So: copy the .env into every backup set, store the key also in the company password vault, and never regenerate it casually on a live system. Treat the key like the keys to the building, because for this data, it is.
Snipe-IT includes a Backups section in the admin settings that can create a backup of the application from the web interface and offers automated backup behaviour. Use it — it is convenient and better than a manual process somebody forgets. But read its limit honestly: an in-app backup, stored on the same server, in the same storage the application controls, protects you against mistakes (a bad import, a deleted model) and not against the server dying. The rule that completes it: at least one copy of the full three-piece set must live off the Snipe-IT machine — the office NAS, another server, an encrypted cloud folder. A backup that dies in the same fire, flood or ransomware as the original was a rehearsal, not a backup.
Once a quarter, perform the only ritual that converts hope into knowledge: take the latest backup set to a spare machine or throwaway VM, install Snipe-IT empty, restore the database, restore the files, restore the .env, and log in. Check three things: an asset with a photo displays correctly, a checkout history reads completely, and a licence record's sensitive fields show real values (that is the APP_KEY proving itself). Time the restore while you do it — that number is your recovery time, and it belongs in the office's head, not in a surprise. Every untested backup in the world is a story people tell themselves; a tested one is a procedure.
.env, together, copied off the server, restore-tested quarterly. Miss the key and the data is locked; miss the off-server copy and the data is hostage to the same accident; miss the test and you find out during the emergency.
See the install this guide protects — set up live in the video, end to end.
▶️ Watch Full VideoThree things together: the MySQL/MariaDB database, the uploaded files (asset photos, logos, attachments in the storage and uploads areas), and the .env configuration file, which holds the APP_KEY needed to read encrypted data.
It is a good convenience and protects against mistakes like bad imports. But if the backup stays on the same server, it does not survive the server failing. Keep at least one full copy somewhere else, and test a restore.
A new key will let the application run, but data encrypted with the old key cannot be decrypted with it. That is why the .env file belongs in every backup set and in your password vault from day one.