Live data from Hacker News

Introducing WAL-G: Faster Disaster Recovery for Postgres

citusdata.com

31–40 of 66 posts

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

#31
post #23

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

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.

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

#32
post #30

Earlier quoted context omitted.

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

Unknown, but I don't have an immediate plan to implement them: https://news.ycombinator.com/item?id=15049527

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

#33
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…

Hey Dan, nice to hear from you!

> our prod base backups take 36 hours to restore, so if the recovery speed improvements are as advertised, that's a big win.

Yes, if you attach 16TB of storage to each instance, your back-up restores may take a while. :))

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

#34
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...

Done.

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

#35
post #18

Earlier quoted context omitted.

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?

I answered this question in a couple of other places, but: unknown because I don't have use for that yet. https://news.ycombinator.com/item?id=15049527

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

#36

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.

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.

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

#37
post #2

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

Do you have plans to support encrypted backups?

Maybe. Depends what you mean by that: https://news.ycombinator.com/item?id=15049691

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

#38
post #3

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…

python versioning can be a bitch, but virtualenv/virtualenvwrapper make 99.999999% of the problems go away.

i have a huge ETL pipeline at twitch that relies heavily on wal-e, and installs it on worker nodes and things like that.

that being said, if WAL-G is faster, i don't care waht it is written in, and am happy to use it

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

#39
post #2

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

Thanks! Does WAL-G provides some kind of "continuous backup" where changes committed to the database are continuously streamed to the backup storage? Or does it work "step by step", for example by backing up every 5 minutes or every 10 MB?

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

#40
post #39
post #2

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

Thanks! Does WAL-G provides some kind of "continuous backup" where changes committed to the database are continuously streamed to the backup storage? Or does it work "step by step", for example by backing up every 5 minutes or every 10 MB?

It does continuous backup like WAL-E.

Both back up PG's WAL files (Write Ahead Log) and allow restoring your database state as it was at a specific time or after a specific transaction committed. This is known as point-in-time recovery (PITR) [0]

Users and admins make mistakes, and accidentally delete or overwrite data. With PITR you can restore in a new environment, just before the mistake occurred and recover the data from there.

[0] https://www.postgresql.org/docs/9.6/static/continuous-archiv...

Post reply on HN