On Tue, Aug 12, 2014 at 5:55 PM, Paul Tiseo <[email protected]> wrote: > Under the postgres user manually, and when added in archive_command, type > returns /usr/local/bin/wal-e, which is correct. The log (not the csv) also > says "envdir: fatal: unable to run wal-e: file does not exist". > > BTW, in the original post, the wal-push commands were run under the postgres > user. And, they work that way. It's on the tail end of a manual backup-push > or under the archive_command context that I get a fail. Very confused. Is > there any way to put wal-e into a more verbose mode?
envdir is telling you what's wrong on the tin: $ envdir /tmp/empty does-not-exist envdir: fatal: unable to run does-not-exist: file does not exist > Attached is my last postgres .log file after the restart for adding the type > item. That said, your log file suggests it is not saying that error nowadays. Something has changed. Okay, I think you are close to working: the problem is somehow your archive_status directory has gotten out of synchronization with your pg_xlog directory, so the archiver is spewing confusion about uploading a non-existent file, because archive_status is what Postgres uses to remember what to upload. However, regular segments appearing now and then seem to upload fine. I don't know how that would have happened, but deleting the 000000010000000000000009.00000028.backup.ready out of archive_status file seems advisable to me. It looks like you have some postdated backups already (e.g. 000000010000000000000020.00000028.backup). There seems to be more evidence of this desynchronization in your file listings, so you may want to delete all *.backup.ready files and then take one fresh backup for good measure. -- You received this message because you are subscribed to the Google Groups "wal-e" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
