restore fails for a lxc - mtime problem?

[Florian Schaal]

It looks like a restore with pbs is not possible if it is an LXC container with quotas.

Error: error extracting archive - error at entry "aquota.group": failed to restore mtime attribute on "aquota.group": Operation not permitted (os error 1)


TASK ERROR: unable to restore CT 127 - command '/usr/bin/proxmox-backup-client restore '--crypt-mode=none' ct/805/2020-09-13T00:00:02Z root.pxar /var/lib/lxc/127/rootfs --allow-existing-dirs --repository xx@pbs@yy:zz' failed: exit code 255

update: looks more like a general problem with mtime

Error: error extracting archive - error at entry "": failed to apply directory metadata: failed to restore mtime attribute on "xxx": Operation not permitted (os error 1)

 

[wolfgang]

Hi,

what do you use as storage for the container?

 

[Florian Schaal]

Hi,

interessting point.... the containers are on lvmthin or ceph.

When i try to restore to lvmthin instead of ceph, the quota-files are not the problem but the restore fails with some other files and mtime:

Error: error extracting archive - error at entry "": failed to apply directory metadata: failed to restore mtime attribute on "web1566": Operation not permitted (os error 1)

 

[flames]

Hello,

i have exactly same problem with a debian 9.x container. PVE 6.3-3 (Ceph) + PBS 1.0-6 (ZFS, physical HDDs).
Error: error extracting archive - error at entry "": failed to apply directory metadata: failed to restore mtime attribute on "somerandomfilename": Operation not permitted (os error 1)
Backing up and restoring same container to/from a NFS storage with PVE built in backup works perfectly in all cases with any compression setting.

Ok, of course one can search for files with invalid mtime attribute and fix them, but in heterogenous networks they appear again and again.
The issue is, that this error is not reported at backup stage (so admin would know his backup is bad)... It is impossible to restore from a "successful" and verified backup! Either PBS should cancel the backup with an error, or while restore give a warning not an error and proceed with restore (either fix the mtime to current datetime, or set it wrong again, therefore the warning).

We are still in testing phase, and of course, if you don't test your backups via real restore, you have no backups. But this is not what we want, you can't test your daily backups ... daily

Thanks, Merry Christmas and a Happy new year to all.

 

[6am]

Hi Flames,

We have the same problem that you mention and I totally agree with the reflections you make about backups.
Two weeks ago I opened an incident:

https://bugzilla.proxmox.com/show_bug.cgi?id=3198

The problems we have are related to the atime attribute and with files with the chattr +i active. I have tried the restore on practically all disk types (zfs, LVM, LVMThin, ext4, ....) with the same error.

The tool looks great, but bugs like this don't help get it into production

Regards and Happy New Year to everyone.

 

[Florian Schaal]

I think, this is the same as in https://bugzilla.proxmox.com/show_bug.cgi?id=3026 (3 months ago)

It seems, that this is not releated to the Filesystem - i can reproduced this with cepf and lvmthin.

 

[fabian]

thanks for the nudge, I merged those two entries and set the status so that someone will take a look..