**Attention ! la volumétrie du .dump n’a rien a voir avec l’espace disque qu’utilisera la base de données une fois restaurée. En effet, le .dump est un fichier « txt » qui ne contient que les commandes permettant de réalimenter la base. Avec des champs « vides » par exemple occuperont nécessairement un espace dans un SGBD mais pas dans le dump.**
# Restauration d'une base de test La première étape est de vérifier l'espace disque sur le serveur :  Nous constatons ici que le disque dur a une taille de 67 Go utiles et que nous avons une disponibilité de 51 Go. Nous allons donc restaurer notre fichier dump cité plus haut sur ce disque dur au travers de l'interface d'Open-Prod.  Avec la commande `tail -f /var/log/openprod/openprod-server.log`, il est possible de "suivre" les traitements réalisés par Open-Prod sur le moment. Nous trouvons l’information suivante : Le serveur exécute la commande `pg_restore` sur le fichier « /tmp/tmp5SX1l3 », préalablement téléchargé via le navigateur. Une fois restauré, on contrôle à nouveau l'espace disque : **Nous constatons que le fichier dump de 1.13 Go, une fois restauré occupe +/- 12 Go d’espace disque.**
# Impact d'une montée de version (sql-update) De nouveau, une montée de version d’Open-Prod peut fortement impacter l'espace disque de l'environnement. Par exemple, si de nouveaux champs fonctionnels sont mis en place par l’éditeur (ou vos modules) dans un grand nombre d’enregistrements, l’occupation définitive du disque peut arriver à saturation. Naturellement, PostgreSQL va créer des fichiers d’échange temporaire sur disque et il convient que de l’espace disque soit disponible en quantité suffisante lors de l’opération. Si nous poursuivons sur l'exemple précédent, voici l'espace disque suite à un **`sql-update`** sur notre base de donnée : **Après la montée de version de notre base dans un format ancien, notre espace disque disponible est tombé à 7.5 Go, la taille de la base a donc augmenté de 32 Go ! Prenez soin d’avoir toujours le maximum d’espace disque disponible lors d’une montée de version et de tester la taille définitive de la future base sur un serveur de test.**
# Déterminer la volumétrie d’une base de données Il existe de nombreux moyen pour déterminer la taille d’une base de données spécifique. Via la commande `sudo -u postgres psql` puis `\l+` :  Via la commande `du` si on connait le lieu de stockage de nos bases. Ici la base « BDD » correspond au répertoire 94118, soit 42477984 Mo :  Depuis l'interface de pgadmin4 et via la requête **SELECT pg\_size\_pretty( pg\_database\_size('BDD') )**  # Echec de restauration de Base de données Saturer l’espace disque d’un serveur de production va fatalement interrompre/impacter un grand nombre de services. Veiller toujours à avoir de l’espace en adéquation avec la manipulation à réaliser. Par exemple, si on veut dupliquer une base par la production d’un fichier zip, le serveur va occuper l’espace de la base de données initiale plus la base de données compressée (dans le .zip uploadé) et la taille de la base de données de destination. Voici un exemple d'erreur qui peut être rencontrée : Et le log joint : **Si vous obtenez ce type de message lors d’une restauration, contrôler rapidement l’espace à disposition sur le serveur et effectuer le correctif nécessaire.**