directory permissions broken after extraction if single file is extracted

[AxelRHD]

Hello Borg-Team,

I have problems with the extract-function. Had to backup with sudo because of file permissions (f. e. backing up the /usr/local/bin-folder). The directory-permissions changed from drwx r-x r-x (original file, also in archive) to drwx --- --- (created directory at extraction time).

I used the command sudo borg extract repo::archive usr/local/bin/file to restore a single file.

Is there something wrong in my usage of the extraction-tool or is this a bug?

[ThomasWaldmann]

that's a known issue and we already have a ticket for it.

See issue #5, attic issue 276.

[ThomasWaldmann]

hmm, or maybe not?

Are you saying you restored directly to the existing /usr/local/bin directory?
== you were root, and cwd was / when invoking the borg command?

[AxelRHD]

No, I tried to restore the file to another directory. I got from this destination the complete sub-directories usr/local/bin/file (for example in my home-directory).

[ThomasWaldmann]

OK, then see the attic issue I mentioned. The point is you told borg to only extract one file (not directories), so it had only the data of that one file. It created the directories on-the-fly without having metadata for them, except the names (which are stored with the file).

[ThomasWaldmann]

I reopened this to locally track it, so users can better find it. Will check the attic issue from the list instead.

[SanskritFritz]

It created the directories on-the-fly without having metadata for them, except the names (which are stored with the file).

How about having an option to istruct Borg not to recreate the path but only restore the files where the permissions are known? This might be important because if I restrore a single file for another user into their home directory, they still would not see their file since the path would have been created with root:root 700 permissions.

[ThomasWaldmann]

@SanskritFritz Imagine you backup /home/foo/x and /home/bar/x and not extract the whole path, then you'ld get a x vs x collision.

[SanskritFritz]

Yes, that is why I thought it should be optional.

PS. Of course I can live with current scenario as I just move the files of interest away and delete the path created by borg. Ah and there is borg mount of course 😄

[ygoe]

Wait, borg backup cannot properly restore directory permissions for 3 years now? With no signs of activity towards actually fixing it? How come so many are recommending this software for whole-system backup? I haven't tested restoring a complete system yet, just started with a Postgres database. All went quickly but the directory permissions are unusable. I have to manually check them down to some levels. This will be a nightmare if it happens to a complete Linux system!

[SanskritFritz]

@ygoe If you backup a whole linux system, you will likely backup it from the root dir. Then all directories will be backed up correctly with permissions and etc.
If you just backup a postgres database, then the directories leading to the file are not backed up, hence there is no way borg can know about their properties.

[ygoe]

I only and always backup the entire system, but not from / because that's a living filesystem. Instead, I first create an LVM snapshot, mount it to somewhere, change into that directory and backup from there. This gives me the relative paths I expect. But something goes wrong between creating this backup and restoring it (haven't checked the backup file listing yet).

[ThomasWaldmann]

@ygoe borg can restore permissions (unix uid, gid, mode) and ACLs of all objects that you actually archived and that you afterwards actually restored.

So, if you have directory/file, there will be 2 objects to consider:

• directory object + metadata (like permissions)
• file object + metadata + content data

If you restore only the file object from the archive, you will get it, including all metadata that is attached to file. The file will also know its full (relative) path, so borg will know it was actually directory/file and re-create the directory/, if it is not already there (it can not know directory metadata (like permissions) in this case).

If you restore directory + everything below, it will first extract the directory object and correctly create the directory with all permissions and other metadata. Then it will extract the file (and the directory is already there, so nothing to do for that).

[ygoe]

Just checked the backup contents, and it shows me the correct permissions of the affected directories. So it was captured correctly in the backup, it's just not restored correctly.

Here are the commands I used:

mkdir /restore
cd /restore
borg extract REPO::ARCHIVE etc/postgresql
borg extract REPO::ARCHIVE var/lib/postgresql

This command is then necessary to fix up the wrong permissions:

chmod 755 etc var var/lib

Everything below looks good again.

[ThomasWaldmann]

borg was precisely doing what you told it to do - the path you gave matched exactly that var/lib/postgresql - it did not match var, neither it did match var/lib - thus these 2 directories were not extracted.

[ygoe]

I really think borg could be smarter than that. After all, it has also included these two parent directories in its repository/archive. It could just look up how these directories should be restored, instead of stupidly creating them with some arbitraryly guessed metadata. That can almost only be wrong.

[SanskritFritz]

@ygoe Note that this already has been discussed in this thread further up.

[ygoe]

@SanskritFritz Where has this been discussed? I can't find anything relevant to my topic. I'm suggesting to use the existing information about parent directories when creating them (which already happens – the creating, not with the stored info). You suggested simply not creating these directories at all, which is not what I need. And I can't make any sense of this "attic" thing. The link doesn't lead me to relevant info either.

[ThomasWaldmann]

Guess the only solution possible would be to keep a cache of directory metadata in memory, so it can be looked up at ad-hoc creation time.