Restore of a whole directory

[filippocarletti]

Restoring (overwrite) a directory from a restic backup leads to wrong permissions for the directory.
See https://community.nethserver.org/t/cockpit-backup-and-restore-data-not-working-correctly/13850/28 for details.

Steps to reproduce

• Delete a directory from an ibay
• Restore it from a restic backup selecting overwrite

Expected behavior

Directory permissions set like before deletion.

Actual behavior

Dir perms are root:root

[filippo@neth.net@ns77-com ~]$ ls -la dir/
total 4
drwxr-xr-x 2 filippo@neth.net locals@neth.net  18 Dec  4 10:20 .
drwx------ 4 filippo@neth.net locals@neth.net 254 Dec  4 10:20 ..
-rw-r--r-- 1 filippo@neth.net locals@neth.net   5 Dec  4 10:20 file
[filippo@neth.net@ns77-com ~]$ rm -rf dir/
[filippo@neth.net@ns77-com ~]$ ls -la dir/
ls: cannot open directory dir/: Permission denied
[filippo@neth.net@ns77-com ~]$ logout
[root@ns77-com filippo]# ls -la dir/
total 4
drwx------ 2 root             root             18 Dec  4 10:30 .
drwx------ 4 filippo@neth.net locals@neth.net 254 Dec  4 10:30 ..
-rw-r--r-- 1 filippo@neth.net locals@neth.net   5 Dec  4 10:20 file

Components

restic-0.9.6-1.ns7.x86_64

---

Thanks to Mario (@trentatre) and Marc (@dnutan)

[nethbot]

in 7.7.1908/testing:

• nethserver-backup-data-1.7.0-1.1.g3ec2c2c.ns7.noarch.rpm x86_64 armhfp aarch64

[nethbot]

in 7.7.1908/testing:

• nethserver-restore-data-2.0.3-1.1.gceb6ef5.ns7.noarch.rpm x86_64 armhfp aarch64

[edospadoni]

Test cases:

1. check the bug is not reproducible
2. check that restore works with and without overwrite option
3. check that restore works for file or directory with all engines (duplicity, rsync, restic)
4. check that restore works for file or directory with all engines (duplicity, rsync, restic) where backup is big enough to completes in minutes/hours

[dnutan]

Only tested with restic:

• UI: checkboxes for sub-items are no longer visually selected
• Nested folder restored with wrong ownership when parent folder does not exist
• Nested files/folders (deep paths) are not restored if parent folders do not exist

[edospadoni]

• UI: checkboxes for sub-items are no longer visually selected

Yes, now only the selected node on the tree structure will be selected because it is possible to select both files and directories

• Nested folder restored with wrong ownership when parent folder does not exist

In which restore mode? new file or overwrite?

• Nested files/folders (deep paths) are not restored if parent folders do not exist

In which restore mode? new file or overwrite?

[filippocarletti]

The same problem also affects duplicity.

[dnutan]

IIRC, first case with overwrite, second case with both modes.

[filippocarletti]

@dnutan the issue is about restoring files contained in directories that have been removed.

Both duplicity and restic, when you ask to restore a file, create the directory that contains the file with default permissions (i.e. root user and 700 mode).

I bet that this scenario is uncommon: if you delete a directory, you restore a directory.

With the restore interface that automatically selects file name (as it is now, without the fix discussed in this issue), you can't restore a directory and always fall in the wrong permission scenario.

To correctly test this issue, you should select a directory if you want to restore a directory.
I tested these packages extensively, but I'd like to have your opinion. Thank you.

[dnutan]

packages:

• nethserver-restore-data-2.0.3-1.1.gceb6ef5.ns7.noarch
• nethserver-backup-data-1.7.0-1.1.g3ec2c2c.ns7.noarch

Original state:

[root@server share]# pwd
/var/lib/nethserver/ibay/share
[root@server share]# tree -Fugap
.
├── [drwxrws--- test@dom buero@do]  dir/
│   ├── [-rw-rw---- test@dom buero@do]  file\ in\ dir.log
│   └── [drwxrws--- test@dom buero@do]  subdir/
│       ├── [-rw-rw---- test@dom buero@do]  file\ in\ subdir.log
│       └── [drwxrws--- test@dom buero@do]  sub-subdir/
│           └── [-rw-rw---- test@dom buero@do]  file\ in\ sub-subdir.log
└── [-rw-rw---- test@dom buero@do]  file.png

3 directories, 4 files

Backup engine: restic; Restore method: cockpit UI.

[root@server share]# # delete dir/subdir/
[root@server share]# # restore dir/subdir/sub-subdir/ (overwrite)
[root@server share]# tree -Fugap
.
├── [drwxrws--- test@dom buero@do]  dir/
│   ├── [-rw-rw---- test@dom buero@do]  file\ in\ dir.log
│   └── [drwx--S--- root     buero@do]  subdir/
│       └── [drwxrws--- test@dom buero@do]  sub-subdir/
│           └── [-rw-rw---- test@dom buero@do]  file\ in\ sub-subdir.log
└── [-rw-rw---- test@dom buero@do]  file.png

3 directories, 3 files
[root@server share]# # denied access to dir/subdir/

[root@server share]# # delete dir/subdir/
[root@server share]# # restore dir/subdir/sub-subdir/file\ in\ sub-subdir.log (overwrite)
[root@server share]# tree -Fugap
.
├── [drwxrws--- test@dom buero@do]  dir/
│   ├── [-rw-rw---- test@dom buero@do]  file\ in\ dir.log
│   └── [drwx--S--- root     buero@do]  subdir/
│       └── [drwx--S--- root     buero@do]  sub-subdir/
│           └── [-rw-rw---- test@dom buero@do]  file\ in\ sub-subdir.log
└── [-rw-rw---- test@dom buero@do]  file.png

3 directories, 3 files
[root@server share]# # denied access to dir/subdir/

[root@server share]# # delete dir/subdir/
[root@server share]# # restore dir/subdir/sub-subdir/file\ in\ sub-subdir.log (new file)
[root@server share]# tree -Fugap
.
├── [drwxrws--- test@dom buero@do]  dir/
│   └── [-rw-rw---- test@dom buero@do]  file\ in\ dir.log
└── [-rw-rw---- test@dom buero@do]  file.png

1 directory, 2 files
[root@server share]# # (new) file not restored

[root@server share]# # delete dir/subdir/
[root@server share]# # restore dir/subdir/sub-subdir/ (new folder)
[root@server share]# tree -Fugap
.
├── [drwxrws--- test@dom buero@do]  dir/
│   └── [-rw-rw---- test@dom buero@do]  file\ in\ dir.log
└── [-rw-rw---- test@dom buero@do]  file.png

1 directory, 2 files
[root@server share]# # (new) directory not restored

[filippocarletti]

Since you deleted "dir/subdir/" you are supposed to restore "dir/subdir/" and find no problems at all.

I think that we can't do much better than this (except having restic and duplicity behave differently).

[dnutan]

I see what you mean. Restoring directly with restic --include offers the same result. Same as reported in the link you gave us: restic/restic#1402

[nethbot]

in 7.7.1908/testing:

• nethserver-restore-data-2.0.3-1.2.g46dcda6.ns7.noarch.rpm x86_64 armhfp aarch64

[nethbot]

in 7.7.1908/updates:

• restic-0.9.6-1.ns7.x86_64.rpm x86_64

[nethbot]

in 7.7.1908/updates:

• nethserver-backup-data-1.7.1-1.ns7.noarch.rpm x86_64 armhfp aarch64

[nethbot]

in 7.7.1908/updates:

• nethserver-restore-data-2.0.4-1.ns7.noarch.rpm x86_64 armhfp aarch64

[dnutan]

Besides the upstream permission/ownership issue dealt here, note the other inconsistency between what the UI reports (successful restore) and the file/directory not restored in new file mode (no overwrite).