git-annex/ tips/ recover data from lost+found

Suppose something goes wrong, and fsck puts all the files in lost+found. It's actually very easy to recover from this disaster.

First, check out the git repository again. Then, in the new checkout:

    $ mkdir recovered-content
    $ sudo mv ../lost+found/* recovered-content
    $ sudo chown you:you recovered-content
    $ chmod -R u+w recovered-content
    $ git annex add recovered-content
    $ git reset HEAD recovered-content
    $ rm -rf recovered-content
    $ git annex fsck

The way that works is that when git-annex adds the same content that was in the repository before, all the old links to that content start working again. So, this works as long as you're using one of the SHA* or other checksumming backends, which is the default.

comment 5

If you're worried about lost+found containing non-annexed content, you can copy (`cp`) the files, rather than moving them (`mv`). After adding the files, `git annex unused` will find any non-annexed ones that were added, and they can then be removed.

This tip was written before `git annex reinject --known` existed, but that is also a good way to do it.

Comment by joey — Tue Jul 22 18:11:47 2025
Isn't this procedure assuming that lost+found contains only uncorrupted previously annexed files?

    git annex add recovered-content

lost+found does not contain only annexed file, right? It may contain any kind of file not originally annexed.

Examples:

- a file that was imported in the regular git part of the git annex repository
- a corrupted variant of an annexed file
- a git pack, a git index or any git administrative file
- a file totally unrelated that happened to be on the same filesystem.

In all these cases, this command will result in new additions to the annex.

This is not what a recovery should do, is it?

Shouldn't that become rather something like:

    git annex reinject --known

Comment by https://launchpad.net/~stephane-gourichon-lpad — Tue Jul 22 18:11:47 2025
comment 3

This procedure is also very useful when you accidentally rename files in the object dir.

Such a case occurred to me when I 'detoxed' a git-annex: detox renames files and it substitutes "--" with "-", thus destroying my annex.

I find git-annex very elegant in this situation: rather than trying to rename back the files (objects) you just re-add them (since content is still there unmodified) recreating the symlink targets!

Kudos!

Comment by atrent — Tue Jul 22 18:11:47 2025
comment 2
The `git annex fsck` at the end will verify if you've managed to recover all the files.
Comment by http://joeyh.name/ — Tue Jul 22 18:11:47 2025
Why fsck?

Other steps I understand but what is the purpose of the last, "git annex fsck"? Shouldn't "git annex add" recreate any missing annex files and therefore fix dangling symlinks?

Comment by https://www.google.com/accounts/o8/id?id=AItOawmWBvsZvSsAL8P2ye3F0OBStjFCVnOImzM — Tue Jul 22 18:11:47 2025
Comments on this page are closed.