Live data from Hacker News

Introducing WAL-G: Faster Disaster Recovery for Postgres

citusdata.com

21–30 of 66 posts

Re: Introducing WAL-G: Faster Disaster Recovery for Postgres

#22
post #2

Hello everyone, I'm the primary author for WAL-G and would be happy to answer any questions.

Can you elaborate on how much automated testing is behind this? When it comes to backup tools, I am very cautious.

WAL-G has a number of unit tests, and has been tested manually in a staging environment for a number of weeks without issues. We are looking to implement more integration tests in the future.

Re: Introducing WAL-G: Faster Disaster Recovery for Postgres

#24
post #18

Earlier quoted context omitted.

Is this production ready, or just an early dev snapshot?

WAL-G is not yet production ready, but it has been used in a staging environment for the past few weeks without any issues. Once fdr adds parallel WAL support, he plans to take it into production.

Cool cool.

is google cloud storage on the roadmap?

Re: Introducing WAL-G: Faster Disaster Recovery for Postgres

#25
post #21

"WAL-E compresses using lzop as a separate process, as well as the command cat to prevent disk I/O from blocking." Good to see people sticking to the unix philosophy of doing one thing well and delegating other concerns - cat and lzop are both fine choices!

I don't know if you're being sarcastic, because the point of the article is that the Unix philosophy was a performance bottleneck and they replaced all the Unixy stuff with Go libraries.

Re: Introducing WAL-G: Faster Disaster Recovery for Postgres

#26
post #2

Hello everyone, I'm the primary author for WAL-G and would be happy to answer any questions.

Thanks for making this! To someone who's unfamiliar with Postgres tooling, what's the difference between WAL-G and Barman? What're the advantages of using one over the other?

WAL-G (and WAL-E) are expected to run next to the main database, while barman is to be run on a separate machine. Barman can also backup many databases. It is essentially the difference between a central backup service and local backups.

Re: Introducing WAL-G: Faster Disaster Recovery for Postgres

#27
post #2

Hello everyone, I'm the primary author for WAL-G and would be happy to answer any questions.

It would be nice if you could sign the tarball with the binary. I see the tag is already signed so hopefully it's not much trouble: https://wiki.debian.org/Creating%20signed%20GitHub%20release...

Re: Introducing WAL-G: Faster Disaster Recovery for Postgres

#28
post #20

This is great. Can't wait to be using it. We've been using WAL-E for years and this looks like a big improvement. The steady, high throughput is a big deal – our prod base backups take 36 hours to restore, so if the recovery speed improvements are as advertised, that's a big win. In the kind of situation in which we'd be using these, the difference between 9 hours and 36 hours is major. Also, the quality of life impr…

Same here, perf is obviously great, but no more crazy dependencies is just great! So much time I wasted trying to make it fit into a docker container.

Re: Introducing WAL-G: Faster Disaster Recovery for Postgres

#30
post #2

Hello everyone, I'm the primary author for WAL-G and would be happy to answer any questions.

Any plans to support backup to Google Cloud Storage instead of just S3?

Or some sort of pluggable storage system.

For now, since I'm also on GCP, I'm using PGHoard: https://github.com/ohmu/pghoard

Post reply on HN