Как делать инкрементальный бэкап без WAL-файлов?

НЯП, никак. Диффы над бэкапами — это то, чего я бы избегал.

делать тупо текстовый diff с текущим, который и сохранять

Сэкономив таким образом место ты СИЛЬНО продлишь простой в случае если нужно будет разворачивать из бэкапа.

Чтобы сделать нормальный дифференциальный бекап базы, нужны её логи репликации за соответствующий период. У обычного юзера их, очевидно, нет. Сгенерировать их с помощью селектов и последующего сравнения их выдачи, конечно, можно, но это будет ужасный оверхед, который перекроет любые выгоды от такого решения. Так что сомневаюсь, что кто-то делал это в готовом виде.

Используй для хранения бекапов ФС со встроенной дедупликацией и продолжай хранить бекапы в обычном виде :-)

Я бы не стал делать бекапы зависимыми друг от друга. Так как один одна из причин потребности в нескольких бекапах - сбой заметили не сразу и успела забекапиться фигня какая-то. А так они в любом случае не должны храниться на том же носителе, что и основная БД. Если ёмкости носителя бекапов хватает, проблемы нет. Если не хватает, то я бы снижал гранулярность бекапов. Например, в течении последней недели хранил каждый день, затем последний месяц только каждую неделю, затем последний год только каждый месяц, затем только каждый год (пример условный, адаптировать под требования конкретной системы).

хранить предыдущий бэкап и делать тупо текстовый diff

но сохранять только изменённые строки, может такой инструмент уже существует?

borg? Не на уровне строк в БД конечно, но он пытается определять какие участки файла изменились.

Есть только удалённый доступ как юзера, без доступа на сервер

Это никак не мешает настроить репликацию. Реплицированная БД сама по себе бэкап, ну и WAL там тебе будет доступен.

Есть только удалённый доступ как юзера, без доступа на сервер.

1. Поднимаете свой узел постгреса.

2. Заливаете туда текущую резервную копию, взятую pgdump’ом.

3. У вас есть сервер с актуальными данными, в котором вы можете делать что угодно. Готово. Вы великолепны.