Host-meta-<date>.tar file is not an archive

[polobo]

Obviously minor but the contents of the "meta" file are plain-text so the .tar extension is misleading.

[gjastrab]

@denishpatel and I were emailing about something which I think may be this same issue. I ran the following on my slave server (Ubuntu 13.10, PG 9.3.2, OmniPITR 1.3.1):

/opt/omnipitr/current/bin/omnipitr-backup-slave -D /var/lib/postgresql/9.3/main -s gzip=/var/lib/postgresql/9.3/wal_archive/ -pp /usr/lib/postgresql/9.3/bin/pg_controldata -l /var/log/postgresql/omnipitr/backup.log -dl gzip=/var/backups/omnipitr/

Which produced 3 files in /var/backups/omnipitr/:

1. ip-xxx-xxx-xxx-xxx-data-yyyy-mm-dd-tar.gz
2. ip-xxx-xxx-xxx-xxx-xlog-yyyy-mm-dd-tar.gz
3. ip-xxx-xxx-xxx-xxx-meta-yyyy-mm-dd-tar.gz

If I try to see what is in the meta file I see an error:

$ tar -tzf ip-xxx-xxx-xxx-xxx-meta-yyyy-mm-dd-tar.gz
gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now

[Deleted user]

Yes, it's not an archive. Just like checksum files. This is to make filename generation simpler - filename always matches whatever you chose by filename-template, where type of the data (data, xlog, checksum name, meta) dictates what's inside.

I know it's not the best approach - seemed sane when I designed it that way, but I am not willing to change it now, as there are scripts that depend on this.

[gjastrab]

Ah I see, you can just cat the file and it's fine despite the name. Ok thanks for clarifying.