A source backup is useful when it can recover the repository history the running site depends on. I check what the archive includes, verify it and restore it into a disposable directory. Keeping the latest release folder alone does not preserve the history needed to inspect or rebuild earlier versions.
Name what the backup covers
A Git bundle can hold repository objects and references. It does not automatically include the live database, uploaded files, ignored environment configuration or external services. Submodules and Git LFS content need their own treatment. I write that boundary down so nobody mistakes a source archive for a complete website recovery plan.
I also check which references the archive includes. A deployment may use a detached commit or a linked worktree whose current head is not covered by the branch list I happened to inspect. The archive needs to retain the source that matters to the running release.
Verify before upload, then test recovery
A successful archive command proves less than it appears to. I verify the bundle and check that the expected commits are present. I then periodically restore into a fresh, disposable directory and inspect the recovered references.
# Example for a small standalone repository.
# Store the resulting archive outside the public web root.
git bundle create /safe/backup/site.bundle --all
git bundle verify /safe/backup/site.bundle
git clone /safe/backup/site.bundle /safe/restore-checkThe Git bundle documentation explains the difference between complete bundles and incremental bundles with prerequisites. An incremental archive is only useful if I have retained the history it depends on.
Budget scratch space
Creating the backup may need temporary disk space before the final object is uploaded. I check the actual scratch location and its permissions, rather than assuming the web server’s main volume has room. A large archive failing halfway through should not fill the partition the website needs to keep running.
The scheduled task needs a lock or another way to avoid overlapping runs. Retrying on the same day should also be predictable: it should not accidentally create an unbounded pile of near-identical archives.
Keep an independent recovery route
I separate the credentials and retention policy for archives from routine deployment access. Recovery instructions should be available if the original server is gone. I record when the last archive succeeded and when a restore was last tested; those are different dates.
My standard is simple: I should be able to explain what would be recovered, what would still need another backup, and when I last demonstrated the process. A reassuring filename alone cannot answer any of that.