Puppet, миграция сервера, восстановление существующих постоянных данных

Что меня смущает в инструментах управления конфигурацией, таких как Puppet, так это то, что они великолепны и просты в настройке сервера с нуля, но то, что игнорируется в каждой документации, это тот случай, когда у меня есть существующие данные (например, база данных PostgreSQL), которые я хочу использовать на недавно подготовленный сервер.

Прекрасным примером является миграция между хостинг-провайдерами. Конечно, Puppet настроит новый сервер с (почти) такой же конфигурацией, как и предыдущий, но код установки (манифест Puppet) предполагает, что этот новый сервер баз данных находится в своем происхождении, в то время как существуют ценные бизнес-данные, которые необходимо восстановить.

Настройка инфраструктуры в первый раз, безусловно, стоит автоматизировать, но случаются аварии, и когда возникает необходимость восстановления сервера, у меня остается полуручная настройка:

1. Puppet: настройка сервера до момента инициализации каталогов данных и запуска служб
2. Я в оболочке: Восстановление данных из резервных копий в нужных местах
3. Кукольный: Продолжайте с остальными, то есть запускайте службы

Это не может быть настолько необычным. Первоначальная настройка серверов без существующих данных - одноразовое событие, но их восстановление может происходить много раз, и я ожидаю, что это произойдет хотя бы один раз (поэтому мы создаем резервные копии ценных данных).

Какова обычная практика написания манипуляций Puppet для сценария, когда узел может быть настроен во второй раз и ему необходимо восстановить данные?

Как вы справляетесь с миграцией серверов, управляемых Puppet?

Гуглить это безнадежно. В основном вы сталкиваетесь со страницами, описывающими, как восстановить Puppet DB/ сервер, но эта часть инфраструктуры в основном не является тем, от чего ваш бизнес получает прибыль, верно?

Я понимаю, что на сервере Puppet есть файловый сервер, но хранение резервных данных и настройка надлежащего контроля доступа кажется очень утомительным по сравнению с управлением конфигурацией с манифестами Puppet.

Я предполагаю, что предприятия используют решения для полного сетевого резервного копирования, такие как Bacula или Amanda, или, возможно, индивидуальные решения для резервного копирования на основе Borg, Restic, Burp, Duplicati или plain rsync. Интегрируете ли вы их в свои манифесты с куклами? Как?