Hacker News new | ask | show | jobs
by thejosh 2153 days ago
I really want to love timescaledb, it's great.. except for the minor issue of not being able to back up.

https://github.com/timescale/timescaledb/issues/1835

4 comments

TimescaleDB definitely supports backups :-)

Here is a page from our docs on how to perform Backup & Restore: https://docs.timescale.com/latest/using-timescaledb/backup

Not sure what's going on in that one Github issue, but we are looking into it.

It seems to be affecting multiple people too. :(
That issue is now closed by the original author:

"Data is successfully dumped. also i can see the constraints, indexes are also copied successfully."

https://github.com/timescale/timescaledb/issues/1835

Cool. :)
This issue is related to slightly confusing _warnings_ that the software prints out, it doesn't effect the _correctness_ of the backups.

The warnings are produced by COPY TO, which is used by pg_dump, since COPY TO doesn't copy chunks. It is not an issue for pg_dump, since it also do COPY TO on each chunk table.

Timescale engineer here - was part of discussion about this warning. We need to do another round and see how to remove this confusion.

Posted elsewhere, but also posting here for posterity:

That issue is now closed by the original author:

"Data is successfully dumped. also i can see the constraints, indexes are also copied successfully."

https://github.com/timescale/timescaledb/issues/1835

That seems like a pretty big deal.

Does a WAL backup approach work?

TimescaleDB offers a number of backup and restore options, including wal-e (WAL-based), pg_dump & pg_restore:

https://docs.timescale.com/latest/using-timescaledb/backup

There are hundreds of thousands of TimescaleDB databases in production so this is generally not an issue.

Seemed like an odd issue to be outstanding. I assume if this was a real issue it would be a much bigger story.
Correct, the issue is due to confusing notices printed during pg_dump as it uses COPY TO underneath.