Well, it doesn't work, because it is compressed.
This doesn't work either:
The reason is the end-of-archive marker written by the first tar (meaning: 1024 byte binary zero [edit: it is 'two blocks' actually, e.g. 2*4096 byte]).

So the next question is: how to prevent tar from writing such marker.

I am going to check the source of tar, then keep blogging.

Comments are welcome.

PS: gunzip + append + gzip sequence isn't a solution, it would be a waste of resoures.

Edit: astrogeek suggested using option -i at untar-time. (Thank you, astrogeek.) It does work:
Problem is, the unlucky guy who will have to use these files might be someone else in the future when I'm long dead. So it would be better if he shouldn't be using any extra options at untar-time.

Edit: it is create.c:write_eot in tar-source. It is called unconditionally. (At least in non-incremental mode. I don't know what incremental mode is, and don't wish to know.) Next idea is creating some tar-replacement (actually, I've done that on platform BS2000 some decades before), or using dd(1) to remove the last 1024 bytes of archive (which is not guaranteed to be 1024, it might be less or more...)

Edit: now this "works":
Okay, but where this 8192 comes from? How platform-independent it is? Clearly it isn't a solution, it is a hack.

Edit: Rather:

Did you try -r?

EDIT: Nevermind, that is what doesn't work on compressed archives.

I don't know about wasting resources, but it looks like you may be able to parallelize it

http://askubuntu.com/a/578957

1 members found this post helpful.

Hi,thank you for your answer, I think I should edit the Original Post to make it clearer.

The -A and -r options to tar only work with non-compressed archives.

Actually, you can use the above method to append a compressed archive, but you then must untar using the -i option to ignore the end-of-archive markers.

The info page for tar includes some good notes on -A, -r and -i not found in the man page.

I see no way to suppress the end-of-archive markers during the creation or concatenation of compressed archives using only tar options.

1 members found this post helpful.

Thanks, I've incorporated this option into the Original Post.

This strikes me as seeming like a XY problem

Perhaps explain what is trying to be accomplished?
If you're taking frequent backups and want to continually update backup files, incremental backup may well be what you're looking for.

1 members found this post helpful.

No, these aren't the same files again and again; these files are generated at a speed of few hundreds per day; and I want to archive them [edit: after being processed] in monthly files (say save.2016.12.tar.xz); the archive-script will run daily and it will delete the archived files.

Why not make a non-compressed tarball of compressed files?

1 members found this post helpful.

Well, most certainly that would be possible, but less efficient compression-wise: tar does have some overhead (minimal size is 1024 byte for every non-empty file)

So you're creating several hundred unique files a day and you're trying to back them up to a single tarball representing that months files? I assume you have previous months as well (save.2016.11.tar.xz) kept as well?
Then have the current months tarball uncompressed and update it daily and all others compressed (So 09, 10, 11 compressed and 12 uncompressed). Then when the next month hits, compress the old one and create a new one.

That should be a good balance of performance, compression and ease of implementation.

On a side note:
I'd be cautious doing this method of backing up. I don't know how well tar responds to errors. If a error corrupts the tarball during a update, you'll lose the whole month of data.
I might suggest rsyncing data from the "live" directory to a "backup" directory, continually adding files to it until the end of the month, tarballing + compressing it, deleting the extra files and thus reset for the next month.

1 members found this post helpful.

Now that file for December is finished, I reorganized it to see how much space I have to lost due to the daily append. (Note: actually it is 'xz' not 'gzip')

Guess it is acceptable.