Lxc export error backup file not found

This

lxc export yourcontainer yourcontainer.tar.gz --optimized-storage=false

Also fails :sob::sob:

Other container gives me the following error

DBUG[06-13|17:54:47] Sending request to LXD method=DELETE url=http://unix.socket/1.0/containers/opsi/backups/backup0 etag= Error: Fetch container backup file: not found

Hi

If i create a second lxd host amd copy the container there should it make any differenece?

The software used is quite different, so if you get a similar problem; it could mean that the problem is specific to your system (hardware problem, misconfiguration, ā€¦?). OTOH if it works, it would suggest more that the problem point at some default in the LXD export feature.

Hmmm i notised something. The working containers give me on a debug a full configuration that i can see. The not working containers are not showing these details. Can i repair this? Maybe it will work again after the repair?

Iā€™m afraid itā€™s not so clear for me. Do you really mean (taking what you say litteraly) lxc config show mycontainer --debug ? and what could be these ā€˜detailsā€™ that are missing ?

Hi,

No if i do lxc export container container.tar.gz ā€”debug

The working once showing lots of info of the xontainer like network and stuff. The containers that fail the export is not showing this info. Only minimal

lot of information ? I looked at an export debug output and I do not see any container information. At the beginning it outputs the system configuration but thatā€™s all. Using ps I see that (for my system config) it is doing first a rsync, then a tar, then a gzip. I think that the rsync is the initial build of the backup image from a snapshot of the container (not sure, itā€™s just an idea), then the image is tarred and gzipped.
I have no idea on what is happening for your config (as I said it may differ for another storage, never looked at how lxc export is working with a zfs storage)

I have no better idea than looking at ps while the backup is running to try to find at what stage it is failing, the lxd reporting is not enlightening at all, lxc operation show just that the job is running, never any information on what could happen behind the curtain. Basically lxc client asks the server ā€˜do the backupā€™, the server does a lot of complex stuff and reports at the end either ā€˜backup successfulā€™ or ā€˜failedā€™.

Hi

What would be the ps command to monitor this?

try to hit
ps -g $(pgrep daemon.start) -o pid,pgid,args
regularly

The export runs.

Then is see it is tarring.

Tar -cf ā€¦

After this it stops?

FTR I tried to switch from gzip (the default) to xz:

lxc config set backups.compression_algorithm xz

and I got the exact same result as you.

You did not change the default compression by any chance ?

BTW if you have lot of free space on the dest device you could try to set compression to none. If compression is failing for you maybe it could ā€˜solveā€™ the problem (in a wayā€¦)

Hi no i did not change it.

How can i check what it is using now for compression?

lxc config get backups.compression_algorithm
if it returns nothing, itā€™s the default: gzip

I see in the 3.14 changelog that some problems have been fixed about backup, do you have the latest and greatest and does it work better ?

Yes i have the latest version.

installed: 3.14 (10923)

I made sure its using gzip and trying again. I keep you informed!

The problem may be a bug in lxd < 3.14. Or it may be in gzip (the utility). Itā€™s old yes but old bugs are the worst :slight_smile:

Hi Gpatel

for the record. i am using gzip as compression. i see that it is compressing the backup0 file and it looks like its going al the way. but the step after the compression seems to fail.

I wanna try without compression. how can i do this. Yust to check if it works then.

AFAIK there is no step after the compression. gzip is passed a stream of uncompressed tar and produces a stream of compressed gzipped tar that in all probability goes directly to the final destination. Unless there is some snap magic.I canā€™t figure out how gzip launched from a snap can write anywhere on the system while snap is designed to block any access outside of the magical snap realm.

If it does not work my guess is that the compression is failing. I think that the reporting of errors happening while the various utilities launched for backup purpose (rsync, tar, gzip in the default case) are running is a bit limited.

use
lxc config set backups.compression_algorithm none
just tried it now with an Alpine container :slight_smile: and it works.

i am now trying without compression. i keep you informed if this works.