LXC Container Restore on ZFS filesystem and GNUSparseFile folder

[giuliolinuz]

Hi,


on a running Promxox vers. 4.2 we have decompress a tar.lzo file for recovering one specific folder for an accounting system application.

The problem is that the backup folder has a different schema of the production folder.
Exactly it contains a folder call GNUSparseFile.******* (some number) that contain sparse files. If we move that files on the original folder (parent folder) the binary files are not working.

If also I restore the LXC container on a new CT i have many of the original file in the original production-file-folder in various subfolder (GNUSparseFile.*****).

What we have to do for have a correct data integrity. We know that is related with zfs and sparse file on the vzdump/tar process but we never found so difficult a data restore before this case (so we can imagine it afflict all 4.* versions ...).


A friendly helping hand?


Thanks in advance

 

[pedroamador]

It seems to be an old issue, but I've got the same on LXC container "vzdump" file, using "pct restore" on ZFS storage. On certain files, the ones with non-ascii characters in their names (example: with "Ñ" character in their names), the vzdump command (or any tool used on it) makes a folder "GNUSparseFile.25472" and place the file on it.

Example: if you've got a file called "foo/españa.xml" then the file was moved to "foo/GNUSparseFile.25472/españa.xml".

To restore the files to their original folders, you should move it to their parent folders. This code works for me:

# IFS=$(echo -en "\n\b")
# for a in $(find . -name "*.25472"); do echo $a; mv "$a/"* "$a/.."; rmdir "$a"; done​

...but works only partially. There is some files with truncated names! O.O

I've put this issue under investigation... (now i'm changing from LVM storage to ZFS storage backend in a 4.2 => 5.0 migration)

 

[pedroamador]

I open a issue for this in bugzilla
https://bugzilla.proxmox.com/show_bug.cgi?id=1467

 

[giuliolinuz]

It' a big mess ... we have solved it patching the files related to vzdump procedure as in the following:

Proxmox v. 4.* -> /usr/share/perl5/PVE/LXC.pm
Proxmox v. 5.* -> /usr/share/perl5/PVE/Storage/Plugin.pm

... removing --sparse options.

We have also activate a sensor with Nagios for monitoring that this flag is not present after - for example - an update.

Otherwise a very big p.i.t.a.! If you also add the problem affected of vers. 4.2 for CT/LXC that does not save "/var" in the basic distro (if you don' t modify /etc/vzdump.conf adding "stdexcludes: 0") ... the question is: "what' s a consinstent backup with PMX 4.2 !?!"


Thanks for opening an issue Pedroamar!

 

[tmikaeld]

I've also got the same issue, I was the one that commented on the bug-tracker.

Would be nice if we could get an official Proxmox answer on this issue, It's extremely annoying and present in all of our backups and VM's (Since all of them use special characters in one way or another).

 

[tmikaeld]

And like @giuliolinuz says, removing --sparse is the only thing that helps, disabling ZFS only helps for future written files not the current ones on disk (Already compressed).

 

[pedroamador]

It's a good point @tmikaeld , you are right: disabling ZFS compression only helps for future written files. In my case I disabled ZFS compression and restored the containers from useful dump, made in servers with LVM storage instead ZFS.

 

[fabian]

updated tar package with proposed fix is available on pvetest:

http://download.proxmox.com/debian/dists/stretch/pvetest/binary-amd64/tar_1.29b-2+pve.1_amd64.deb