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

GitLab's built-in gitlab:backup:create task bundles the database, repositories, uploads, and CI artifacts into one timestamped tarball, and gitlab:backup:restore brings the instance back from it. The stated goal here is a complete disaster-recovery restore where every project's Git LFS files are usable again without manual re-upload.

The uncertainty is around LFS specifically. The backup does include the uploads directory, which is where LFS objects live on a local-disk setup, but the restore documentation does not clearly state that those objects are extracted and re-linked so LFS pointers resolve again. There is also the complication that instances using external object storage (for example S3) only get metadata in the tarball, with the actual objects living outside the backup entirely. Add in the same-major-version restore requirement and the fact that runner registration data is excluded, and it is hard to know what "fully recovered" really means.

Assume a recent GitLab version on Linux package (Omnibus) installation with local storage. Verification ideas considered include comparing gitlab:backup:checksum output and spot-checking LFS files through the UI or API after restore.

1. Does a standard restore re-extract and re-link LFS objects from uploads so existing LFS pointers resolve, or is a separate step required?
2. With external object storage configured, what is the documented way to make LFS content available again after a restore?
3. Is there an official verification task or checksum comparison that confirms LFS integrity, not just database integrity?