pgBackRest VS fpart

This tutorial explains how to backup PostgreSQL database using pgBackRest and S3.

This isn't theoretical; many companies do PostgreSQL async 1:N physical replication, by using e.g. https://pgbackrest.org/ to have the primary push WAL segment files (a.k.a. "the last n milliseconds of packets" in the write-ahead log) as objects to S3, and then to have all read-replicas fetch from S3 and replay.

> You could do even better if you out-of-band signal the readiness so you do not need to poll while idle.

S3 and its clones have "object lifecycle notifications", where you can be informed by a push-based mechanism whenever a new object is put into the bucket.

But — what do you have to do, to get these notifications?

Subscribe to a message queue that S3 puts them into.

I haven't explored the territory in awhile but for bare-metal, you can't go wrong with Percona Distribution, which includes pgBackRest and a minimal web-ui. No one ever got fired for using Percona, etc.

Check out pgBackRest

I found this approach pretty cool in that regard: https://github.com/pgbackrest/pgbackrest

Something like PG barman or pg backrest could be good for you on the Postgres side.

Backups are limited. These days, pgbackrest is the go-to backup solution for PostgreSQL, and having used it I am very impressed so far. It provides full backups, differential, and incremental, as well as archiving of WAL segments for point in time recovery. It allows great flexibility in schedules and destinations for backups, how long to keep backups for, how many full backups. For example, you can have backups made to a local disk, and other backups to an external S3-compatible bucket, each with their own settings and schedules (e.g., scheduled via cron).

Native rsync is terrible for lots of small file as it copies each file one by one sequentially. If you have lots of cores to work with, use the fpsync utility that comes with the fpart command to run parallel rsync's. You can easily saturate a 10Gb link with multiple rsync processes in parallel

You should probably use something like fpsync and multiple rsync jobs to get the most bandwidth.

My favorite free solution is fpsync/fpart from https://github.com/martymac/fpart -- basically that is a highly optimized filesystem crawler and indexer that can spit out balanced lists of files to transfer to a waiting army of parallel rsync workers. Tools are provided to manage the rsync fleet. Combining fpsync/fpart with an army of parallel rsync workers is a great design pattern especially for HPC as you can farm the rsync workers out to compute nodes

I've migrated data from our Isilon to zfs hostA using the fpsync tool that comes with the fpart utility. I get reasonably good throughput from this. 15TB in 5 and 1/2 hours