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 and it works.
Sorry for the delay, I needed some time to look at the code to try to understand.
FTR, here is how I think it is done. The function is in lxc/export.go
There are 2 phases:
ask to the lxd server to create a backup file. This is the part I have asked you to examine and we have found no obvious problem in this
once the file is done, ask the lxd server to download the file. This is the part where it all goes pear shaped.
I have now a very nasty feeling. I have noticed there is an automatic pruning of âoldâ backups. How itâs done is that in lxc/export.go lxc client ask to create a backup file with a maximum shelf life of 30 minutes.
ExpiryDate: time.Now().Add(30 * time.Minute)
For a typical backup of one of my containers (3 Go at most) there is absolutely no chance a backup takes more than that.
In your case itâs rather different, and the task pruning âoldâ backup run hourly. This does not seem configurable. The only way of testing if this hypothesis is correct would be to recompile the lxc client with an expiration delay of say 4 hours.
I donât know if you are ready for such an enterprise
It could have side effects in case of people having several backup crashes in rapid succession and rather low disk space. IMO the ideal solution would be to get a parameter to bump this default time for people needing it. But of course there is another problem, that is, the error reporting is somewhat limited.
lxc export will delete the backup as soon as itâs retrieved so that shouldnât really be a problem unless your container is huge AND you make a lot of exports AND they all run at the same time AND they all fail somehow.
*** Fail somehow: that was my first hypothesis. Everything that can fail, will fail eventually.
*** huge container: thatâs a reasonable supposition and it may not even be necessary, since I also did the hypothesis of limited space - another realist posslbility, you can get good prices for a 50 Gb SSD on the Net, thatâs what I use for one of mu servers
****make lot of exports: there are 2 ways it can happen:
a script that retries in case of failure
a human that tend to think that itâs possible to get different results when trying again the same operation when it fails; thatâs something that has a bad name but itâs part of the human nature and it can happen more frequently than one can imagine.
I admit that I never looked deep to this problem, but git log on a recently fetched lxd gives
commit b58bfa5d1586b12c8bb327c09b209251dfb09745 (HEAD -> master, origin/master, origin/HEAD)
thatâs the commit immediately following the one interesting you.
and snap info lxd gives
channels:
(âŠ)
edge: git-b58bfa5 2019-06-20 (10939) 56MB -
the git ref (b58bfa5) looks like the beginning of the git commit; so itâs probably that; the âedgeâ snap is the equivalent of a ânightly buildâ (remember the firefox version that crashed ? thatâs what a nightly build is, no quality control, nothing but raw untested code). But if you want to experiment, thatâs your data. A backup first could be useful. Oops, I almost forgot thatâs the feature that is not working for you Probably a better idea would be to setup a test server.
For now the edge snap will have it so you could switch to that, not that I would ever recommend running edge on anything but a test system.
Otherwise, we do cherry-pick bugfixes somewhat regularly and this will be included the next time we do so.
It may also be worth pointing out that the compression algorithm is configurable, so if space isnât a problem for you, you can set backups.compression_algorithmtonone` and save yourself a lot of CPU and time.