One of the easiest mistakes to make when working with Linux servers, Docker, or self-hosted applications is changing something that already works β without creating a backup first.
It sounds obvious, but it saves a lot of headaches.
My simple rule
If it works, back it up.
Before modifying configuration files, application code, Docker settings, or production services, create a backup.
For example:
cp -a /mnt/d/mailtrain /mnt/d/mailtrain-backup-$(date +%Y%m%d-%H%M)
Now you have a point-in-time copy you can return to if something goes sideways.
Even better: use Git
For code and configuration that you expect to customize regularly, Git is even better.
git status
git add .
git commit -m "Backup before customization"
Then you can see what changed:
git diff
And, when appropriate, roll back to a previous version.
Why this matters
When you're working with Dockerized applications, a small configuration change can sometimes affect several services.
A five-second backup can save an hour of troubleshooting.
And if you're building a setup that you plan to reproduce for multiple clients, backups become even more valuable. You want a repeatable installation, not a server that only works because nobody remembers exactly what was changed. π
The takeaway
Backup first. Customize second.
Future you will be glad you did.
Top comments (0)