На вид выглядит как: отделить процессы сетапа кластера, сетапа доступов и т.п. от процесса дампа баз. Для бекапа баз по одному процессу на базу. При восстановлении уметь отдельно создать площадку с Галерой под базы и отдельно уметь раскатать базы. Уметь это отдельными, не связанными действиями. Базы бекапить или поштучно своими скриптами, с обработками ошибок и т.д. или поискать готовое решение. Поставить на мониторинг процесс возникновения новых бекапов (добиться работоспособности процесса). Стараться не привязываться к особенностям Галеры, не добавлять зависимостей.

Когда нужно задним числом посмотреть в базы, то удобно иметь возможность раскатки базы в стороне, просто возможность анализа простыми средствами. Поэтому rsync выглядит очень неудобно. Не подлезть посмотреть в бэкап, без манипуляций с специально настроенными нодами и "раскатки" обратно. Возникает возможная привязка к сетапу OS ноды, вместо сетапа просто только MSQL базы. Поэтому ценна возможность получить каждый дамп отдельно независимым tar.gz или подобное.

Может не прав. Возникло подозрение о желании решения, но не обрабатывать ошибки. Чтобы решение не могло закончится с ошибкой. Ошибки нужно обрабатывать. Нужно иметь работоспособный процесс на этот случай (в т.ч. отработка оповещений из мониторинга). Всегда.

> скрипт как-то не корректно завершался, вероятно не возвращая чего-то

Замены слов "как-то" и "чего-то" содержат в себе ответ или вопрос о причинах. Причины могут быть в выбранной комбинации действий, что относится к обработке ошибок или выбору другой комбинации у себя. А могут быть в особенностях Марии и Галеры.

mydumper: https://github.com/maxbube/mydumper/releases
myloader  для восстановления (сам почитаешь)

mydumper -h $SQL_HOST -P $SQL_PORT -u $SQL_USER -p $SQL_PASS --regex '^(?!(mysql\.[^u].*|sys\.|sys-schema.*\.|PERCONA_SCHEMA\.))' \
--outputdir=$CUR_BACKUP_PATH \
--compress \
--threads=$(($(grep -Ec "processor" /proc/cpuinfo)+2)) \
--compress-protocol \
--triggers \
--events \
--routines \
--less-locking \
--trx-consistency-only \
--rows=500000 \
--build-empty-files \
--logfile $CUR_BACKUP_PATH/mydumper.log \
--verbose 3

>[оверквотинг удален]
> пришлось пристрелить..
> Четвертый вариант - проходили, со слейвом можно делать что угодно, но запись
> в бин лог не добавляет стремительности всему кластеру, ну и отдельная
> радость от восстановления реплики в случае чего, то еще удовольствие.
> Собственно может кто поделится опытом, как решает схожую задачу, или может урл
> какой почитать укажет, хотя гугл мне пока никак с этим не
> помог. Может кто пробовал реализовать wsrep_sst_backup_mariabackup, или еще какой вариант?
> Помогите люди добрые..
> P.S. SST и IST работают как часы, mariabackup'ом.
> P.P.S. Использую MariaDB 10.4 + galera4

Если хотите PITR, то только со слейва.