That did it.

I compared and some WAL had transferred to S3, but at one point, the rest 
did not. I know early on, I had put in a bad S3 prefix but corrected it. 
Presumably, that put the system in a bad state. 

And, so, I cleared archive_status of all files, and the rest started 
transferring at the next cycle. I ran a backup-push, and it did not get 
stuck. backup-list shows one file now, because I finally ended up with a 
JSON file.

Looks like we're good now. Thanks all for the help.

On Wednesday, August 13, 2014 11:45:45 AM UTC-4, Daniel Farina wrote:
>
> On Tue, Aug 12, 2014 at 5:55 PM, Paul Tiseo <[email protected] 
> <javascript:>> 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.

Reply via email to