Тогда если они там что-то запускают - меняют - это

уже будет совсем другая база, то накатить wal не получится

настроить какую-то синхронизацию данных в этой новой базе из оригинальной... да это целый квест, на пару отделов )

у вас вообще процедуры бекапов базы настроены ?
я бы предложил по запросу просто восстанавливать им последний бекап, и усе )

ну вот сечас как раз так и делаем. но прост восстановление бекапа происходит порядка 14-16 часов

Про восстановление последнего бэкапа -- кстатида.

Магнитные диски в raid1?

раз в месяц ? выглядит не страшно )

выглядит не страншно, но разрабы жалуются, просят ускорить восстановление

А если попробовать LVM Snapshot. Открывать Бд для тестинга. Откатывать изменения на LVM. И накатывать свежие WAL.

можно попробовать запускать rsync с последним бекапом, но тут время восстановление не получится точно задать, завит от того, как много было изменено в базе ну и, тут могу ошибаться, если в таблице хоть 1 строчка поменялось, то файл по сути будет уже другой и будет переписан rsync весь, но это не точно )

надо пробовать. я думал у кого то уже есть опыт такой. и подскажет путь правильный

Вы, кстати, подумайте -- что у вас бэкап ресторится по 16 часов, это означает выкинутый бизнес-день если что. Можэт, там денег в хранилку бэкапов или её сеть надо докинуть.

попробуйте еще подождать ) вам ответили только несколько человек, возможно тот у кого есть подобный опыт с базами подобных объемов просто еще спит или активно работает и ответит позже

Главное тогда делать thin lvm volume. Снэпшоты классических вольюмов убивают скорость и вместе с ней идею тэстирования скорости на корню.

ну вот как раз чичиас обновили сеть на 10g, обновлять еще и хранилку на ssd - имхо бизнес когда увидит ценник, скажут ну вас нахер ))

Во-первых -- можно дисков добавить в raid10. И чтобы страйпы могли параллелиться (prefetch там побольшэ). Во-вторых -- посмотреть, вдруг там не в диск и не в сеть как таковую, а в допустим tcp/ip упирается или fs тупит.

ну так поверхностно глянули инфру - пока обнаружили затык на сети, ибо копровать фул бекап - очень долго

По идее один ствол 10g -- это большэ гигабайта в секунду и меньшэ трёх часов на копирование 10T.

Можно иметь два инстанса над ZFS - один постоянно докатывается WAL-ами, второй для девелопмента. Как надо обновить девел - старый убиваем, реплику останавливаем, делаем ZFS snapshot, ZFS clone и над новым ZFS поднимаем и промотим postgres

интересное предложение.

По сути, это DLE https://gitlab.com/postgres-ai/database-lab

Тут больше плюшек.

pgbackrest —delta restore может быть полезен, так как зачастую тащить будете не все 10TB а только измененные файлы. Но желательно чаще чем раз в месяц, так как за месяц много данных могут измениться. ... Restore a Backup in Quick Start required the database cluster directory to be cleaned before the restore could be performed. The delta option allows pgBackRest to automatically determine which files in the database cluster directory can be preserved and which ones need to be restored from the backup — it also removes files not present in the backup manifest so it will dispose of divergent changes. This is accomplished by calculating a SHA-1 cryptographic hash for each file in the database cluster directory. If the SHA-1 hash does not match the hash stored in the backup then that file will be restored. This operation is very efficient when combined with the process-max option. Since the PostgreSQL server is shut down during the restore, a larger number of processes can be used than might be desirable during a backup when the PostgreSQL server is running. https://pgbackrest.org/user-guide.html#restore/option-delta

спс, почитаю