GitLab backup restore: are LFS objects in uploads actually recovered?

Short answer

Yes — on an Omnibus install with local storage, a standard gitlab:backup:restore recovers LFS objects, but the premise in the question needs one correction: LFS objects are not stored in uploads. They are a separate backup component, lfs-objects, archived alongside uploads, artifacts, repositories, and the database dump inside the same timestamped tarball. The restore task extracts each component back to its configured path, so existing LFS pointers resolve again without manual re-upload.

What is confirmed vs. assumed

Confirmed behavior for recent Omnibus versions:

• Local LFS content lives under the shared data directory (typically /var/opt/gitlab/gitlab-rails/shared/lfs-objects), not under uploads. Uploads holds attachments, avatars, and similar files.
• gitlab:backup:create includes lfs-objects as its own archive inside the tarball; restore unpacks it to the configured location.
• The restore must target the same GitLab version (and edition) as the backup, and gitlab-secrets.json must be restored separately or encrypted database values cannot be decrypted.
• Runner registration tokens are excluded and must be re-registered.

Assumed: a recent GitLab version on Omnibus with default local storage. Exact component lists and available rake tasks vary by version, so treat version-specific details as needing a check against your installed version's documentation.

External object storage changes everything

If LFS is configured to use S3-compatible object storage, the tarball contains only database metadata — the object bytes were never in the backup. "Fully recovered" then means: restore the backup, configure the instance to point at the same bucket, and the pointers resolve against the still-existing objects. If the bucket was deleted or lifecycle rules expired the objects, no restore can bring them back; object storage needs its own backup/replication strategy (versioning, cross-region replication) independent of gitlab:backup:create.

Verification

There is no official rake task that verifies LFS content integrity end to end. Practical checks:

1. Before trusting a backup, list the tarball contents and confirm the lfs-objects archive is present.
2. After restore, spot-check: download a known LFS-tracked file through the UI or API and compare size/hash against the original.
3. From a client, clone a repository and run git lfs pull or git lfs fsck to confirm pointers resolve and content downloads intact.
4. On newer versions, gitlab:backup:checksum can generate component checksums for backup-level comparison — useful, but it validates the archive, not LFS semantics.

If your restore test shows LFS downloads failing while repositories load fine, the one diagnostic detail that changes the recommendation is your gitlab.rb LFS storage setting (local path vs. object storage) — that determines whether you are debugging an extraction problem or a bucket-configuration problem.