borgbackup / borg

Deduplicating archiver with compression and authenticated encryption.
https://www.borgbackup.org/
Other
11k stars 739 forks source link

Missing parent directories have default permissions!? #8157

Closed iomari closed 6 months ago

iomari commented 6 months ago

Greetings,

I'm using borg2 on Kubuntu 23.10.

My yaml file has many folder from my home directory and also folders like root, /usr,etc that require root access.

I'm using sudo to start my backup with no issues what soever on completion I can mount the repo and see all my files. However, a few of the folders in my home directory are owned by root though the actual folder on my system is owned by the user.

Why did the backup change ownership on some of my home folders?

iomari commented 6 months ago

Here is the command to backup:

sudo borgmatic --progress --stats -c ~/.config/borgmatic/config-complete.yaml --repository /mnt/2t2/backups/borg/complete

Here is the yaml: https://pastebin.com/1Jx6hSMm

When I mount the repo and list my home folder, here is a snippit of the output.

Notice the folders owned by root:

drwxr-xr-x 1 root root 0 Mar 21 11:18 . 
drwxr-xr-x 1 root root 0 Mar 21 11:18 .. 
drwx------ 1 iomari iomari 0 Jan 25 2022 .abook 
drwxrwxr-x 1 iomari iomari 0 Oct 23 2021 .ansible 
drwxr-xr-x 1 iomari iomari 0 Mar 30 2023 ansible 
drwxr-xr-x 1 iomari iomari 0 Mar 19 14:26 .antigen 
drwxrwxr-x 1 iomari iomari 0 Jan 1 2021 .aria2 
drwxr-xr-x 1 root root 0 Mar 21 11:18 backups 
-rw------- 1 iomari iomari 6090 Jul 19 2023 .bash_history 
-rw-r--r-- 1 iomari iomari 4559 Sep 18 2023 .bashrc 
drwxrwxr-x 1 iomari iomari 0 Jan 16 12:13 bin 
drwxrwxr-x 1 iomari iomari 0 Nov 12 13:59 .borg 
drwxrwxr-x 1 iomari iomari 0 Sep 3 2022 broot 
drwxrwxr-x 1 iomari iomari 0 Oct 22 15:33 .buildozer 
drwxr-xr-x 1 root root 0 Mar 21 11:18 .cache 
drwxrwxrwx 1 iomari iomari 0 Sep 24 15:12 calibre_library 
lrwxrwxrwx 1 iomari iomari 24 Oct 9 2022 clipart -> /mnt/2t2/backups/clipart 
-rw------- 1 iomari iomari 4623 Dec 4 16:00 .clush_history 
drwxrwxr-x 1 iomari iomari 0 Jan 7 2023 .clusterssh 
drwxrwxr-x 1 iomari iomari 0 Jul 5 2023 code 
drwxr-xr-x 1 root root 0 Mar 21 11:18 .config

Here is the same folder list from the live fllesystem. Keep in mind that not all the folders in home are in the repo butlook at .cache and .config as an example.

They are owned by iomari not root as it appears in the repo:

drwxrwxr-x 2 iomari iomari 4096 Mar 9 2022 cache 
drwxrwxr-x 2 iomari iomari 4096 Nov 27 2020 .cachier 
-rw------- 1 iomari iomari 17984 Jan 25 13:52 .calc_history 
-rw------- 1 iomari iomari 3359 Feb 14 2023 .calc_history-83757.tmp 
drwxr-xr-x 3 iomari iomari 4096 Oct 27 2017 calibre 
drwxrwxrwx 7 iomari iomari 4096 Sep 24 15:12 calibre_library 
lrwxrwxrwx 1 iomari iomari 17 Jun 19 2020 'Calibre Library' -> ./calibre_library 
drwxrwxr-x 5 iomari iomari 4096 Jun 3 2021 .cargo 
drwxrwxr-x 11 iomari iomari 4096 Jun 5 2021 .cheat.sh 
drwxrwxr-x 2 iomari iomari 4096 Sep 8 2020 .cht.sh 
drwxr-xr-x 6 iomari iomari 4096 Apr 23 2018 .cinnamon 
drwxrwxr-x 6 iomari iomari 4096 Jul 4 2022 .clamtk 
drwxrwxr-x 11 iomari iomari 4096 Aug 21 2019 click 
lrwxrwxrwx 1 iomari iomari 24 Oct 9 2022 clipart -> /mnt/2t2/backups/clipart 
-rw------- 1 iomari iomari 4623 Dec 4 16:00 .clush_history 
drwxrwxr-x 3 iomari iomari 4096 Jan 7 2023 .clusterssh 
drwxrwxr-x 3 iomari iomari 4096 Jul 24 2023 .cmake-js 
drwxrwxr-x 24 iomari iomari 4096 Jul 5 2023 code 
drwxrwxr-x 7 iomari iomari 4096 Mar 13 2020 code-insiders 
drwxrwxr-x 2 iomari iomari 4096 Sep 30 2022 .conda 
drwxrwxr-x 436 iomari iomari 28672 Mar 21 11:24 .config
infectormp commented 6 months ago

(deleted - thanks for reformatting the lists and helping in general!)

ThomasWaldmann commented 6 months ago

This is not a bug, but expected behaviour.

Also I think we already have a ticket about this, thus I am closing this as duplicate.

Borg only has metadata for the filesystem objects that you put into the borg archive at borg create time. For example, you do NOT back up the .cache fs object, thus you can not expect that borg knows correct metadata for it.

In such a case, the FUSE fs created by borg mount will just "make up" the missing filesystem objects (e.g. missing parent directories), but it will use some default permissions as it does not have anything more specific. Similar will happen if you use borg extract.

Solution: backup up all fs objects you want to have precise metadata for, exclude stuff you do not need. That long list of directories to back up in your yaml is rather unusual, normally one gives one or a few starting directories ("recursion roots") and then excludes unwanted stuff that is contained in them.

iomari commented 6 months ago

Understood. However my home folder is extremely long. That's why is less work to list included rather than excluded. But I'll try it and see how it works. Thanks.

On Thu, Mar 21, 2024, 2:22 PM TW @.***> wrote:

This is not a bug, but expected behaviour.

Also I think we already have a ticket about this, thus I am closing this as duplicate.

Borg only has metadata for the filesystem objects that you put into the borg archive at borg create time. For example, you do NOT back up the .cache fs object, thus you can not expect that borg knows correct metadata for it.

In such a case, the FUSE fs created by borg mount will just "make up" the missing filesystem objects (e.g. missing parent directories), but it will use some default permissions as it does not have anything more specific.

Solution: backup up all fs objects you want to have precise metadata for, exclude stuff you do not need. That long list of directories to back up in your yaml is rather unusual, normally one gives one or a few starting directories ("recursion roots") and then excludes unwanted stuff that is contained in them.

— Reply to this email directly, view it on GitHub https://github.com/borgbackup/borg/issues/8157#issuecomment-2012282319, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACBDTHTY3OVT5BRK7ES3RNLYZLNJNAVCNFSM6AAAAABFBBL24OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJSGI4DEMZRHE . You are receiving this because you authored the thread.Message ID: @.***>