Mise à niveau PostgreSQL 14 en 2026 : combien d’espace disque prévoir pour pg_upgrade ?

À retenir — aucun multiplicateur fixe ne permet de calculer l’espace nécessaire à pg_upgrade pour toutes les instances PostgreSQL 14. Relevez l’occupation réelle des répertoires de données, des tablespaces et de WAL, puis établissez le besoin selon le mode choisi et l’emplacement cible. Si l’espace semble insuffisant, ne sélectionnez pas --link dans l’urgence : vérifiez d’abord qu’une sauvegarde externe peut être restaurée et envisagez une répétition de la migration dans un environnement séparé.

Cette méthode s’adresse aux DBA responsables d’instances PostgreSQL 14 qui préparent une mise à niveau avant la fin de son support. Elle concerne aussi les responsables techniques qui doivent valider la capacité disponible, ainsi que les ingénieurs chargés de comparer les effets de copy, link et clone sur le stockage et le retour arrière.

Calculer l’espace disque pour pg_upgrade sous PostgreSQL 14

Il n’existe pas de réserve universelle que l’on puisse exprimer comme un multiple de la taille logique de la base. Le besoin varie selon les fichiers présents, les systèmes de fichiers, l’emplacement des tablespaces et le mode de migration. PostgreSQL distingue notamment les bases et leurs fichiers, les journaux WAL et les tablespaces, qui peuvent résider à l’extérieur du répertoire principal (organisation des fichiers PostgreSQL, documentation des tablespaces).

La taille calculée par une requête SQL n’est donc pas nécessairement la capacité à prévoir sur chaque volume. Des tablespaces peuvent se trouver sur des montages différents de celui de PGDATA, tandis que les fichiers WAL peuvent eux-mêmes être placés ailleurs. L’espace libre constaté sur un volume ne compense pas une insuffisance sur un autre volume utilisé par la migration.

Avant de choisir une méthode, dressez un inventaire des chemins et des volumes concernés. Notez le répertoire de données de l’instance source, les chemins de chaque tablespace et leur occupation réelle, ainsi que l’emplacement du répertoire WAL. Relevez également les chemins envisagés pour le nouveau cluster, ses tablespaces et ses journaux. Pour chaque système de fichiers, consignez l’espace utilisé et l’espace libre ; un total global à l’échelle du serveur masque les contraintes de montage.

Des outils comme du, df et findmnt permettent de rapprocher les répertoires de leur système de fichiers. du -sh donne une mesure lisible du chemin examiné, tandis que df -h indique l’espace disponible sur le volume qui le contient. L’option -x de du peut éviter de parcourir les autres systèmes de fichiers montés sous ce chemin ; si vous l’utilisez, mesurez ces montages séparément. Les emplacements des tablespaces peuvent aussi être contrôlés à l’aide de pg_tablespace_location, fonction décrite dans la documentation des fonctions d’administration.

Quelle réserve supplémentaire prévoir pour pg_upgrade ? Elle dépend du mode retenu. copy duplique les fichiers concernés dans le nouveau cluster ; link réutilise certains fichiers au moyen de liens physiques ; clone peut éviter une duplication immédiate lorsque le système de fichiers prend en charge le mécanisme requis. Dans tous les cas, évaluez aussi la place nécessaire aux fichiers temporaires et aux WAL pendant votre procédure. La marge doit être déterminée à partir des observations de votre instance et de la migration testée, pas d’un chiffre trouvé pour une autre base.

La fin de prise en charge de PostgreSQL 14 est indiquée au 12 novembre 2026 par la politique officielle de prise en charge des versions. Cette échéance renforce l’intérêt de planifier l’opération, mais ne change ni l’occupation des fichiers ni les conditions de stockage propres à l’instance.

pg_upgrade --check vérifie-t-il que le disque est assez grand ? Ne le considérez pas comme une validation de capacité. Mesurez l’espace libre de chaque montage utilisé par les répertoires source et cible, les tablespaces et WAL, puis comparez ces mesures aux besoins du mode retenu.

Choisir le mode selon l’espace libre et le retour arrière

Le choix dépend de la priorité de l’équipe : limiter l’espace supplémentaire, garder les fichiers du cluster source disponibles pendant les vérifications ou déplacer l’opération vers une cible indépendante. Ces méthodes n’ont ni le même besoin en stockage ni les mêmes possibilités de retour arrière. La compatibilité du système de fichiers et la version de PostgreSQL cible doivent être vérifiées avant de figer le plan.

Si les clusters partagent un système de fichiers et que l’espace est limité : évaluer link

Le mode link réutilise les fichiers concernés en créant des liens physiques au lieu d’en copier une seconde version. Il peut donc réduire l’espace supplémentaire demandé par rapport à une copie complète. Cette option dépend toutefois des conditions de système de fichiers décrites dans la documentation du mode --link. En particulier, les fichiers à relier doivent satisfaire les restrictions liées à leur emplacement : des chemins sur des systèmes de fichiers distincts ne peuvent pas être reliés par liens physiques. Vérifiez donc les répertoires réels, y compris ceux des tablespaces, plutôt que de vous fier uniquement à leur arborescence apparente.

L’économie d’espace a une contrepartie pour le retour arrière. Après le démarrage du nouveau cluster en mode link, le cluster source ne peut plus être utilisé comme auparavant. Si la nouvelle instance échoue après avoir commencé à fonctionner, il ne suffit pas de redémarrer l’ancienne en supposant que rien n’a changé. Il faut définir à l’avance une procédure de retour cohérente, disposer d’une sauvegarde indépendante et avoir vérifié sa restauration.

pg_upgrade --link économise-t-il de l’espace sans compliquer le retour arrière ? Il évite de recopier certains fichiers, mais ne supprime pas le risque opérationnel. Retenez cette méthode seulement si les contraintes du système de fichiers sont respectées, si la sauvegarde externe a été restaurée lors d’un essai et si l’équipe sait comment revenir à un état cohérent. Si l’une de ces conditions n’est pas remplie, l’espace libéré ne justifie pas à lui seul le choix du mode.

Si la priorité est de conserver le cluster source : comparer copy et clone

Le mode copy, utilisé par défaut, copie les fichiers vers le nouveau cluster. Les fichiers source et cible coexistent alors pendant la préparation et les vérifications. Le calcul doit tenir compte de leur présence simultanée sur les volumes concernés, notamment si les nouveaux tablespaces sont placés sur des montages différents. Conserver l’ancienne instance disponible peut faciliter les contrôles, mais seulement si l’espace mesuré le permet.

Le mode clone peut limiter la duplication physique lorsque le système de fichiers fournit une fonction de clonage adaptée. Le nouveau cluster peut alors s’appuyer sur un mécanisme de copie sur écriture, ce qui peut permettre de garder le cluster source disponible sans réserver immédiatement l’espace d’une copie complète. Cette possibilité n’est pas garantie sur tous les systèmes d’exploitation et tous les systèmes de fichiers. Vérifiez les conditions de la version cible dans la documentation et testez le mécanisme sur la machine qui réalisera la migration.

Quel mode est le plus prudent entre copy et link ? copy convient lorsque la priorité est de conserver les fichiers source disponibles pendant la validation et que les mesures confirment une capacité suffisante. link peut être envisagé lorsque l’espace est contraint, mais ses conséquences sur le retour arrière exigent une préparation plus stricte. clone constitue une autre possibilité seulement si le système de fichiers et la version utilisée prennent effectivement en charge les conditions requises.

Les options disponibles et leurs restrictions doivent être lues dans la documentation correspondant à la version cible, et non déduites d’un guide destiné à une autre version. La documentation de pg_upgrade pour PostgreSQL 17 illustre pourquoi cette vérification doit être rattachée au programme et à la version effectivement prévus. Un nom de mode ne suffit pas à établir sa compatibilité avec les montages de votre serveur.

Préparer une migration vers une cible indépendante

Lorsque la nouvelle instance se trouve sur une autre machine ou un autre stockage, calculez séparément la capacité disponible à la source et à la cible. L’espace libre de l’ancien serveur ne compense pas un volume cible trop petit. Pour éviter ce piège, séparez les éléments du calcul en fonction de leur emplacement et de leur rôle dans la migration.

Côté source, relevez les données et les tablespaces qui doivent rester disponibles pendant la préparation, ainsi que les journaux nécessaires à la méthode choisie. Côté cible, estimez l’occupation attendue du nouveau cluster et de chacun de ses tablespaces. Ajoutez les fichiers temporaires et les journaux exigés par le chemin de migration retenu. Si ce chemin n’est pas pg_upgrade local, évaluez séparément les copies intermédiaires, les besoins de synchronisation et la durée pendant laquelle des WAL doivent être conservés.

Une répétition dans un environnement indépendant est particulièrement utile si l’équipe ne sait pas encore si l’espace ou le déroulement de la migration est suffisant. Reproduisez autant que possible les chemins, les montages et les volumes observés en production, puis exécutez la procédure sur une copie représentative des données. La répétition permet de relever les besoins de votre instance et de votre méthode ; elle ne justifie pas de reprendre une quantité mesurée dans un autre contexte.

Faut-il traiter les tablespaces comme un simple supplément de PGDATA ? Non. Un tablespace peut se trouver sur un montage distinct : identifiez son chemin, mesurez son occupation et déterminez son emplacement cible, puis vérifiez le volume correspondant. La documentation des tablespaces décrit leur rôle d’emplacements configurables pour les fichiers de base de données ; cette organisation impose de les inclure dans le relevé au lieu de les assimiler au répertoire principal.

Une autre stratégie de migration peut demander un calcul différent de celui de pg_upgrade. Une copie logique, une réplication ou un transfert de fichiers peuvent créer des copies intermédiaires et solliciter les journaux selon des modalités propres à la méthode. Choisissez donc le chemin avant de finaliser l’estimation : c’est lui qui détermine quelles données doivent coexister, sur quels volumes et pendant quelle période.

Intégrer sauvegarde et retour arrière au budget

La capacité utilisée pour la migration, celle nécessaire pour conserver l’ancien cluster et celle réservée aux sauvegardes répondent à des objectifs distincts. Le démarrage réussi du nouveau cluster ne démontre ni que l’ancienne instance peut être réactivée, ni que les données pourront être restaurées après une erreur.

Avant l’opération, vérifiez que la sauvegarde se trouve hors de la machine concernée, qu’elle couvre les données nécessaires et qu’une restauration a été menée jusqu’à un état exploitable. La documentation PostgreSQL sur la sauvegarde et la restauration décrit les approches disponibles ; la page consacrée à la sauvegarde au niveau du système de fichiers expose les précautions propres à cette méthode. Une copie placée sur le même serveur ne protège pas contre la perte de ce serveur.

Une configuration redondante, qu’elle repose sur une réplication ou sur un miroir logiciel, ne remplace pas une sauvegarde externe. La réplication peut maintenir une copie disponible, mais une suppression propagée ou une corruption répliquée peut aussi affecter les copies en ligne. De même, le miroir logiciel répond à un besoin de redondance des données sur des supports ; il ne prouve pas que l’équipe sait restaurer la base après un incident.

Le plan de retour doit couvrir les étapes applicatives, pas seulement les fichiers PostgreSQL. Définissez comment interrompre ou limiter les écritures pendant la bascule, comment modifier les connexions de l’application, quelles vérifications effectuer après le changement et à quelles conditions revenir à l’état précédent. Si l’application a écrit dans le nouveau cluster, la procédure doit prendre en compte ces nouvelles écritures : une ancienne copie de données ne suffit pas nécessairement à reconstruire un état cohérent.

Utilisez cette liste avant de fixer la date de migration :

• [ ] Mesurer chaque répertoire de données et chaque tablespace sur son volume réel.
• [ ] Repérer le montage qui contient WAL et relever son occupation pendant une période représentative.
• [ ] Inscrire les chemins source et cible, puis vérifier l’espace libre sur chacun des systèmes de fichiers concernés.
• [ ] Choisir entre copy, link, clone ou une autre méthode après avoir contrôlé les conditions de la version cible et du système de fichiers.
• [ ] Exécuter pg_upgrade --check sans le traiter comme une validation de capacité.
• [ ] Vérifier qu’une sauvegarde conservée hors de la machine a été restaurée avec succès.
• [ ] Documenter le changement de connexion applicative et les critères qui déclenchent un retour arrière.
• [ ] Répéter la procédure dans un environnement isolé si l’espace ou les conséquences d’un échec restent incertains.

Une capacité suffisante ne garantit pas à elle seule la réussite, mais elle évite qu’une opération soit interrompue alors que les données anciennes et nouvelles doivent coexister. Si la place manque, comparez le risque et le coût d’un autre mode à ceux d’une cible distincte ; ne transformez pas une économie de stockage en dépendance à une seule copie.

Vérifier les ressources avant de programmer la bascule

Une fois les volumes recensés et le mode choisi, confrontez ces besoins à la capacité réellement disponible sur l’infrastructure envisagée. Vérifiez l’espace utile par montage, l’emplacement possible des tablespaces et la conservation des sauvegardes externes. Ne déduisez pas la capacité exploitable d’une simple fiche de serveur : elle dépend de la disposition des données, de la redondance prévue et des copies que l’équipe doit conserver.

Pour une location, examinez la configuration disponible et les modalités de facturation avant de programmer le transfert. La page de configuration des serveurs et les modalités de facturation permettent de vérifier ces éléments auprès de XFP Cloud. Ces pages ne remplacent pas l’inventaire technique : confirmez que les capacités et emplacements proposés correspondent à vos besoins. Ne considérez pas le choix d’un serveur comme une garantie de durée de migration ou de protection des données.

La décision finale doit intégrer le coût de l’espace supplémentaire, la possibilité de conserver l’ancien cluster, le temps nécessaire aux contrôles et le coût d’une restauration réellement testée. Si ces conditions ne sont pas réunies, reportez la bascule et réalisez d’abord un essai sur une cible indépendante. Une opération mieux préparée vaut mieux qu’un mode choisi uniquement parce qu’il paraît réduire l’espace requis.

Une machine virtuelle partagée ou une instance infonuagique peut convenir à une charge temporaire ou à une équipe qui privilégie l’élasticité ; en revanche, les ressources partagées, les options de stockage facturées séparément et le contrôle parfois limité des systèmes de fichiers peuvent compliquer une migration dont la capacité doit être prévisible. Pour une base durable qui exige des ressources matérielles dédiées et une organisation du stockage définie par l’équipe, la location d’un serveur physique AMD auprès de XFP Cloud peut être plus adaptée. Commencez par réunir l’inventaire des volumes, les exigences de restauration et le mode envisagé, puis comparez-les à la configuration réellement disponible avant de programmer la bascule.