Nécessité de pg_start_backup pour du log-shipping

Bonjour à tous,

Je travaille avec un de mes clients, la CNAF pour ne rien cacher, sur un
projet de mise en oeuvre de log shipping.
L'objectif est de sécuriser encore un peu plus les productions pour par
exemple être capable de ne pas perdre une journée d'activité des
utilisateurs si, par exemple, vers 16h30, un DBA étourdi faisait un
malencontreux DROP DATABASE, SCHEMA, TABLE ... ou si un FS se trouvait
cassé !

Actuellement, les nombreuses bases sont physiquement hébergées sur des
baies de disques EMC via un SAN. Pour les sauvegardes, la CNAF dispose
d'un jeu de mirroirs des disques, utilisant la fonctionalité TIime-Finder
Clone des baies. En temps normal, les mirroirs (CLONEs) conservent l'image
des bases à la veille au soir. En fin d'après-midi, ces CLONE sont mis en
état "synchronisation". Puis vers 18h, la synchronisation est coupé
(SPLIT), les mirroirs restant alors dans un état figé pendant 24h. Ce sont
ces CLONEs qui sont ensuite utilisés pour les sauvegardes sur cartouche,
pendant que la production tourne sur les "vrais bases". Ils contiennent
bien sûr tous les fichiers des clusters, tablespaces et pg_xlog compris.
Lorsqu'il est nécessaire de restaurer une base, le CLONE concerné est
restauré et le cluster redémarré. Comme le SPLIT a été fait sans arrêt du
cluster, au redémarrage, celui-ci se retrouve dans un état instable,
similaire à celui obtenu après un crash du serveur. Mais après la recovery
initiale, ça repart !

Pour le projet de log shipping, l'idée est d'archiver les WAL pour être
capable, le cas échéant, de les ré-appliquer (complètement ou en PITR) sur
des images de bases présentes sur les CLONEs.
Les premiers tests réalisés montrent que 1) ça marche (mais nous n'en
doutions pas ! ), 2) la volumétrie des logs à archiver (après compression
avec pg_lesslog) est tout à fait raisonable.

J'en arrive donc à ma question !
La documentation PostgreSQL sur l'archivage en continu indique qu'il faut
utiliser les commandes pg_start_backup et pg_stop_backup. Mais celles-ci
sont elles utiles ici ?

Sur ce point, ma compréhension du fonctionnement de postgres est la
suivante :
- entre le retour de la commande pg_start_backup et le lancement de
pg_stop_backup, les fichiers de données sont figés et les mises à jours
s'empilent dans les WAL ; pour nous, tout étant dans le même espace
disque, ce sont toujours des mises à jours de fichiers qui peuvent
intervenir même au moment du SPLIT.
- un fichier backup_label_file est créé ; il ne nous est pas d'une grande
utilité !
- au stop_backup, un nouveau log est utilisé ; pas d'impact pour nous.
- un fichier backup_history_file est créé avec le label fourni au
pg_start_backup (nous ne voyons pas d'info spécialement intéressant à y
mettre, l'endroit de stockage de la sauvegarde état toujours le même), les
heures d'exécution des 2 fonctions et les identifiants des WAL contenant
les transactions de la période start_backup / stop_backup.
Je ne vois donc rien d'essentiel.

Mais est-ce que je passe à côté de quelque chose ?

Cordialement.