# Wal archive-command like functionality? **URL:** \ **Category:** General\ **Created:** [June 17, 2026, 8:30am UTC](https://forum.yugabyte.com/t/wal-archive-command-like-functionality/5069 "2026-06-17T08:30:58Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![hispebarzu](https://avatars.discourse-cdn.com/v4/letter/h/9de053/32.png) [@hispebarzu](https://forum.yugabyte.com/u/hispebarzu)\ **Post date:** [June 17, 2026, 8:30am UTC](https://forum.yugabyte.com/t/wal-archive-command-like-functionality/5069/1 "2026-06-17T08:30:58Z")
I was skimming through the docs and was not able to find how to best replicate postgres functionality to minimize data loss in case of disaster. The closest I was able to find is: [[docdb] PITR: Metadata restore from external backups · Issue #8847 · yugabyte/yugabyte-db · GitHub](https://github.com/yugabyte/yugabyte-db/issues/8847) There are currently no way to keep S3 backups up-to-date or make incrimental backups in yb / yba? ---
**Author:** ![dorian\_yugabyte](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/dorian_yugabyte/32/206_2.png) [@dorian\_yugabyte](https://forum.yugabyte.com/u/dorian_yugabyte)\ **Post date:** [June 17, 2026, 8:49am UTC](https://forum.yugabyte.com/t/wal-archive-command-like-functionality/5069/2 "2026-06-17T08:49:19Z")
Hi @hispebarzu “incremental backup” is actually the only feature that is not open source. But it is available in YBA [YugabyteDB Anywhere Incremental Backups 101 | Yugabyte](https://www.yugabyte.com/blog/yugabytedb-anywhere-incremental-backups/) But it doesn’t do log shipping, but only backups the changed sst files on disk instead. We also have PITR but it doesn’t offload the logs to S3 and is only in-cluster: [Point-in-time recovery | YugabyteDB Docs](https://docs.yugabyte.com/stable/manage/backup-restore/point-in-time-recovery/) ---
**Author:** ![hispebarzu](https://avatars.discourse-cdn.com/v4/letter/h/9de053/32.png) [@hispebarzu](https://forum.yugabyte.com/u/hispebarzu)\ **Post date:** [June 30, 2026, 5:28pm UTC](https://forum.yugabyte.com/t/wal-archive-command-like-functionality/5069/3 "2026-06-30T17:28:57Z")
Thanks, I’ve overlooked YBA incremental backups implementation. Is there any plans to implement log shipping? We somewhat recently had a disater that wiped out our DB clusters, and business now values data availability more and there is more push towards sharded postgres, I doubt YBA can handle 10-minute incremetal backups. ---
**Author:** ![Alan\_Caldera](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/alan_caldera/32/91_2.png) [@Alan\_Caldera](https://forum.yugabyte.com/u/Alan_Caldera)\ **Post date:** [June 30, 2026, 6:50pm UTC](https://forum.yugabyte.com/t/wal-archive-command-like-functionality/5069/4 "2026-06-30T18:50:13Z")
Hi @hispebarzu - We aren’t planning to implement log shipping because our logs aren’t used for recovery in the way that other relational databases use them. That’s why we implemented Incremental Backups that actually capture changed files and can run on a shorter schedule. The time required for an incremental backup depends on the number of objects in your databases as we must extract the schema at every iteration. So if you have a relatively small number of objects, this could be a very short time period. All of our backups perform a ysql\_dump using the schema-only option per database, so you can test for yourself to see how much time that phase takes. Once the schema extraction phase is complete, the changed SST files are uploaded to your cloud store. This could occur in the 10 minute window that you mention. Restoring from backups is rare if the cluster is properly configured with 3 independent fault domains. Do you need assistance configuring the proper resilience/availability strategy? Alan ---
**Author:** ![sid](https://avatars.discourse-cdn.com/v4/letter/s/5f9b8f/32.png) [@sid](https://forum.yugabyte.com/u/sid)\ **Post date:** [September 10, 2026, 5:03am UTC](https://forum.yugabyte.com/t/wal-archive-command-like-functionality/5069/5 "2026-09-10T05:03:35Z")
> [@hispebarzu](#): > > [docdb] PITR: Metadata restore from external backups · Issue #8847 · yugabyte/yugabyte-db · GitHub Log shipping and rollforward PIT recovery is one of the critical requirement for any OLTP database systems. I would say with honest feedback is that biggest feature lagging. Its impossible to have snapshots every 5 to 10 min when we considering 10+TB database size. -Sid ---
**Author:** ![dorian\_yugabyte](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/dorian_yugabyte/32/206_2.png) [@dorian\_yugabyte](https://forum.yugabyte.com/u/dorian_yugabyte)\ **Post date:** [September 10, 2026, 8:27am UTC](https://forum.yugabyte.com/t/wal-archive-command-like-functionality/5069/6 "2026-09-10T08:27:15Z")
> [@sid](#): > > Its impossible to have snapshots every 5 to 10 min when we considering 10+TB database size. It works if you do incremental snapshot, and only backup the differing sstables instead of the whole db.