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.
Comments
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
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.