
Introducing WAL-G: Faster Disaster Recovery for Postgres - craigkerstiens
https://www.citusdata.com/blog/2017/08/18/introducing-wal-g-faster-restores-for-postgres/
======
drob
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 improvements are great. Despite deploying WAL-E for
years, we _still_ have problems with python, pip, dependencies, etc, so the
switch to go is a welcome one. The backup_label issue has bitten us a half
dozen times, and every time it's very scary for whoever is on-call. (The right
thing to do is to rm a file in the database's main folder, so it's
appropriately terrifying.) So switching to the new non-exclusive backups will
also be great.

We're on 9.5 at the moment but will be upgrading to 10 after it comes out.
Looking forward to testing this out. Awesome work!

~~~
humanfromearth
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.

~~~
gardnr
Can you share your dockerfiles?

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

~~~
whitepoplar
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?

~~~
fdr
I was kafkes's guide on this project, and the WAL-E author and maintainer...

I'd say the differences between WAL-G and Barman are similar to WAL-E and
Barman, which comes up relatively frequently.
[https://news.ycombinator.com/item?id=13573481](https://news.ycombinator.com/item?id=13573481)

In summary, WAL-E is simpler program all around that focuses on cloud storage,
barman does more around inventories of backups and file-based backups and
configuring Postgres. There are integrative downsides to its span. WAL-E also
happens to predate Barman.

------
sehrope
I've used WAL-E (the predecessor of this) for backing up Postgres's DB for
years and it's been a very pleasant experience. From what I've read so far
this looks like it's superior in every way. Lower resource usage, faster
operation, and the switch to Go for WAL-G (v.s. Python for WAL-E) means no
more mucking with Python versions either.

Great job to everybody that's working on this. I'm looking forward to trying
it out.

~~~
tyingq
Every time I saw that mentioned, my mind goes to the movie.
[https://g.co/kgs/d8G9u5](https://g.co/kgs/d8G9u5)

~~~
ocharles
I don't think it's a coincidence WAL-E is named as it is :)

------
upbeatlinux
Wow, great work! I am definitely going to test this out over the weekend.
However AFAICT the `aws.Config` approach breaks certain backwards
compatibility w/how wal-e handles credentials. Also wal-g does not currently
support encryption. FWIW, I would love to simply drop-in wal-g without having
to make any configuration changes.

~~~
fdr
Do you want GPG based or some other client side encryption, or S3's encryption
support? The latter could probably just be turned on. The former is a feature
requiring code.

~~~
upbeatlinux
Ideally the presence of the `WALE_GPG_KEY_ID` env var should enable encrypted
backups
[https://github.com/wal-e/wal-e#encryption](https://github.com/wal-e/wal-e#encryption).

Put differently to be a "successor" it needs to be a drop in replacement ;)

~~~
fdr
I have to be selective about maintenance of features. I'll consider GPG
support.

~~~
tatersolid
Please consider libsodium or a similar "modern" crypto library instead.
There's a lot of ugly 90s crypto in GPG and the API is terrible. Libsodium
makes it hard for non-crypto devs to shoot themselves in the foot, and is much
less code to write.

------
jfkw
Will WAL-G eventually support the same archive targets as WAL-E (S3 and work-
alikes, Azure Blob Store, Google Storage, Swift, File System)?

~~~
fdr
As I'm probably the steward on this going forward: unknown. I don't intend to
implement them unless I need them. Would I take a patch with good coverage
that implemented those.

~~~
boulos
Would you be willing to own the abstraction for multiple backends? The code is
currently only a bit hardcoded to S3/AWS, but I assume most of the "work" will
be discussing how to abstract different transports, exponential backoff,
resumable uploads, and so on.

Fwiw, the GCS client for go (import "cloud.google.com/go/storage") is very
straightforward. Though as others have pointed out, it might be worthwhile to
just try to use minio-go if you want to gain Ceph as well.

Disclosure: I work on Google Cloud (and if the way is paved, we will
contribute here; seems like a great project)

------
craigkerstiens
For those interested in the repo directly to give it a try you can find it
here: [https://github.com/wal-g/wal-g](https://github.com/wal-g/wal-g)

------
jarym
"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!

~~~
wmf
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.

~~~
jarym
I wasn't being sarcastic - I like the fact that they replaced what needed
replacing and kept what worked well.

------
mephitix
Fantastic intern project, and fantastic work by the intern!

------
gigatexal
I wonder where python will end up in the next five or so years if Go is
continually chosen for concurrent or high perf code things like this.

------
X86BSD
Why would this be a better option than a simple zfs snapshot, zfs send/recv
backup and recovery strategy?

