2

Note:-Might be the question sounds too broad. But, I believe ,it's very good platform(stackexchange) and I can get advice from worldwide expert DBA here. Since, I'm not able to make decision or choose the right option.

Que: I'm new to postgres and need to make PITR solution for our continuously growing database. Need to plan incremental backup solution as well since database size is increasing at rapid speed. If we can't afford to lose any data and also need to have PITR, which one should be best solution:

  • Have an standby and in case of any failure/disaster take full backup(pg_basebackup) of the standby db cluster and do PITR from that backup(recovery.conf -time).

    • continuously taking incremental backups+log backups.

    • use any 3rd party tool to take incremental as well as log backup of postgres db.

Please let me know which option should be better or any other option if anybody has then suggest that option as well.Also, let me know if any performance impact can happen with a database in case we have multiple standby for that database or any negative impact of keeping a standby.

-Thanks in advance!

Improve this question

1 Answer 1

Reset to default
1

There are many possibities!

PITR vs STANDBY

PITR & Standby are complementary solutions:

  • Standby is interesting to recover from:
    • physical problem: server crash, datacenter unavailabity
    • and offer quick switchover procedures
  • PITR will help you in case of data damage:

    If someone performs an operation that damages your data (DROP TABLE , UPDATE with a wrong WHERE clause ...). Then, you will be able to restore your database before this operation.

Implementation

PITR implementation

There are many tools that can help you to perform PITR, I have already used:

  • barman
  • wal-e

And there are also:

  • PgBackREst
  • ...

This article lists and compares several LINUX backup tools.

My bast advices, regarding PITR implementation, are:

  • Use existing tools (and don't try to write a new one)
  • Test your backups
  • Monitor your backups (and see the monitoring point fails)!

standby implementation

As it's native, there's no need for additional tooling on the implementation-side.

But:

  • monitor it correctly
  • Write and test your switch procedures (and re-test them at regular intervals, to prevent that the procedure is not accurate when needed!)
Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.