The day the server disk dies, your backup is either a restore or a rumour. GitLab concentrates everything your team cannot recreate - so its backup deserves the same seriousness as the server itself.
Here is the uncomfortable truth about a code server: every developer having a clone protects only the current state of the code. The history of who changed what, the issues, the merge request discussions, the user accounts, the attachments and the settings exist in exactly one place - GitLab's database and storage, inside one virtual machine. If that machine dies unbacked-up, the code survives in pieces and the team's memory does not. A backup is not a feature you add later. Without one, what you have installed is a demo.
👆 Miss any green row and the restore will expose the gap at the worst possible moment - during the recovery itself.
TurnKey appliances ship with their own backup system, TKLBAM - TurnKey Backup and Migration - reachable through the appliance's administration tools. Configure it on day one, not after the first scare, and schedule it daily for a team that pushes code every day. Two details decide whether it saves you later. First, the backup is encrypted with a passphrase: store that passphrase in the same password manager as your root passwords, because an encrypted backup whose passphrase is lost is just a brick. Second, point the backup at storage that is not the server itself - an external drive, a NAS, or cloud storage - which the next rule explains.
Virtual machine snapshots feel like backups and are not. A snapshot lives on the same host and the same disks as the server it protects, so the failure that kills the server usually kills the snapshot in the same minute. Snapshots are perfect for the hour before a risky change - take one before an upgrade, delete it after. A backup is a copy that has left the machine: synchronised to another device, on a schedule, with older copies kept. And one copy should leave the building entirely, because fire and theft do not respect your folder structure.
GitLab has a strict, documented rule that surprises everyone once: a GitLab backup can only be restored onto the same GitLab version and edition it was taken from. This shapes two habits. Write the GitLab version next to every backup you keep, so a future restore starts with the right appliance. And always take a fresh backup immediately before an upgrade, because if the upgrade goes wrong, that same-version backup is your only clean road back. Teams discover this rule during disasters. You are reading it now, which is the cheaper way.
Spin up a throwaway virtual machine, install the same appliance, restore your backup into it, sign in, and open a project. The whole exercise takes an afternoon the first time and teaches you every step your future stressed self will need. If something in the chain is broken - a forgotten passphrase, a missing configuration file - you find out on a quiet day with coffee, not during an outage with the team standing behind you. An untested backup is a hope, not a plan. After the test, put the date in your calendar and repeat it when the appliance version changes.
Watch the complete install in the video, then give it the backup it deserves before the first real project moves in.
▶️ Watch Full VideoDaily for a team pushing code every day; weekly is the bare minimum for a quiet instance. Automate it either way - manual backups are precisely the ones forgotten during busy weeks.
It protects the code's current state only. Issues, merge request discussions, project settings, user accounts and attachments exist only on the server. Lose the server and the team's memory goes with it.
Roughly the size of your repositories plus uploads and the database. Check the trend monthly: a backup that suddenly doubles usually means someone committed large binary files, which is worth a conversation - not just a bigger disk.