Volumes persistants et snapshots sur Dockup

Les volumes persistants et les snapshots répondent à deux problèmes différents. Un volume conserve les fichiers lors du remplacement d’un conteneur et des déploiements. Un snapshot capture le volume à un instant donné afin que les opérateurs puissent inspecter, conserver ou restaurer cet état ultérieurement.

Le système de fichiers du conteneur est remplaçable. Tout ce qui doit survivre à un déploiement — uploads, médias générés, index, artefacts de packages ou fichiers gérés par l’application — doit utiliser un emplacement persistant explicite.

Quelles données applicatives doivent être stockées de manière persistante ?

Utilisez un volume lorsque l’application gère des fichiers qui ne peuvent pas être recréés facilement ou de manière fiable depuis une autre source.

Données	Volume ?	Meilleure alternative lorsqu’elle est disponible
Uploads utilisateur	Oui	Object storage si l’architecture l’utilise
Miniatures générées	Parfois	Les régénérer à partir des originaux
Index de recherche	Parfois	Le reconstruire depuis la base de données source
Artefacts de build	Généralement non	Les recréer lors du déploiement
Logs applicatifs	Généralement non	Système de logs du runtime
Répertoire de données PostgreSQL	Pas comme volume applicatif	PostgreSQL managé
Cache temporaire	Non	Redis ou stockage éphémère
Base de données SQLite locale en production	Risqué	Base de données managée pour la concurrence et les sauvegardes

Un volume doit avoir un propriétaire et un chemin de montage clairement définis. Deux processus sans lien qui écrivent dans le même répertoire compliquent la restauration et l’analyse des permissions.

Avant d’ajouter du stockage, estimez la taille initiale, le rythme de croissance, les exigences de conservation et l’objectif de restauration. L’espace disque est facturé en fonction du solde du plan, à la minute : la capacité inutilisée et la croissance incontrôlée des fichiers ont donc un coût.

Comment créer et inspecter un volume Dockup ?

Répertoriez les volumes existants pour le service concerné :

dockup volume list production/web --json

Ajoutez un volume avec un nom, un chemin absolu dans le conteneur et une taille en gigaoctets :

dockup volume add production/web \
  --name uploads \
  --path /app/uploads \
  --size 20 \
  --json

L’application doit écrire dans /app/uploads. Écrire dans /uploads ou dans un autre répertoire local ne redirige pas automatiquement les données vers le montage.

Après le déploiement, vérifiez que l’application écrit bien dans le chemin de montage absolu déclaré, et non dans le système de fichiers remplaçable du conteneur.

Inspectez l’utilisation réelle du disque avec l’ID de volume renvoyé :

dockup volume usage <volumeId> production/web --json

Comparez l’utilisation réelle à la taille allouée et aux métriques de l’application. Déclenchez une alerte avant que le système de fichiers soit plein ; un volume saturé peut entraîner des écritures partielles, des échecs d’upload ou des plantages de l’application.

Vérifiez les attentes en matière de propriété des fichiers. L’utilisateur d’exécution du conteneur doit pouvoir lire et écrire dans le chemin de montage sans accorder de permissions plus larges que nécessaire.

Comment les snapshots de volume protègent-ils les données ?

Un snapshot créé à la demande capture le contenu du volume :

dockup volume snapshot <volumeId> production/web --json

Répertoriez les snapshots disponibles :

dockup volume snapshots <volumeId> production/web --json

Les snapshots lisent le volume en mode lecture seule et n’obligent pas l’application à écrire dans un répertoire de snapshot spécial. Ils sont utiles avant une migration de fichiers risquée, une réécriture massive de médias ou une modification applicative qui transforme les données stockées.

Un snapshot de volume n’est pas automatiquement cohérent du point de vue de l’application. Si l’application écrit activement plusieurs fichiers liés, le snapshot peut les capturer à des instants légèrement différents. Pour une base de données managée, utilisez le système de sauvegarde de la base de données managée plutôt que de créer un snapshot de son répertoire de données brut.

Définissez les situations dans lesquelles l’application doit être mise au repos. Une courte période de maintenance ou de suspension des écritures peut être appropriée avant un snapshot important. Notez l’ID du snapshot, sa raison d’être et le point de restauration attendu.

Comment planifier la conservation des snapshots ?

Choisissez la fréquence et la durée de conservation des snapshots en fonction des exigences de restauration, et non par habitude. Créez un snapshot à la demande avant chaque migration de fichiers, nettoyage ou modification de format risqué, puis notez l’ID de snapshot renvoyé.

dockup volume snapshot <volumeId> production/web --json
dockup volume snapshots <volumeId> production/web --json

Besoin de restauration	Pratique recommandée pour les snapshots	Limitation
Annuler une migration de fichiers	Créer un snapshot immédiatement avant la modification	N’inclut pas les écritures ultérieures
Conserver des points historiques	Conserver des points de restauration identifiés conformément à la politique	La conservation doit être réévaluée régulièrement
Protéger des écritures fréquentes	Ajouter une sauvegarde au niveau applicatif adaptée aux données	Un snapshot ponctuel n’assure pas une protection continue
Archivage réglementaire	Utiliser un workflow d’archivage dédié	Les snapshots opérationnels peuvent ne pas satisfaire aux exigences

Vérifiez que les snapshots attendus existent réellement. Une politique de conservation écrite ne prouve pas qu’un point de restauration exploitable a été créé.

Comment restaurer un snapshot de volume en toute sécurité ?

Une restauration remplace le contenu actuel du volume et redémarre le conteneur :

dockup volume restore \
  <volumeId> \
  <snapshotId> \
  production/web \
  --json

Il s’agit d’une opération perturbatrice qui modifie l’état du système. Avant de restaurer :

1. Confirmez le service, l’ID de volume et l’ID de snapshot exacts.
2. Expliquez quels fichiers actuels seront remplacés.
3. Arrêtez ou limitez les nouvelles écritures lorsque cela est possible.
4. Créez un snapshot récent de l’état actuel s’il peut être nécessaire.
5. Notez la compatibilité de l’application et du schéma.
6. Obtenez une approbation explicite pour la production.
7. Planifiez les vérifications post-restauration.

Après la restauration, vérifiez l’état du conteneur et le comportement de l’application :

dockup status production/web --json
dockup logs production/web --json

Testez des fichiers représentatifs, les permissions, les index et les références de l’application. Une commande de restauration réussie prouve que le snapshot a été appliqué ; elle ne prouve pas que chaque enregistrement applicatif pointe vers un fichier valide.

Le modèle de garde-fous de production pour les agents IA doit considérer la restauration comme une opération soumise à approbation, même s’il s’agit d’une opération de récupération.

Comment les volumes doivent-ils se comporter lors d’un déploiement et d’un rollback ?

Un déploiement remplace les conteneurs applicatifs tandis que le volume monté reste en place. Une nouvelle image peut ainsi accéder aux fichiers existants, mais cela crée une obligation de compatibilité.

Une nouvelle version de l’application ne doit pas transformer de manière irréversible les fichiers stockés avant que sa version ne soit validée. Si elle modifie les formats de fichiers ou l’organisation des répertoires, utilisez si possible une migration reprenable et rétrocompatible.

Un rollback applicatif relance un ancien déploiement :

dockup deployments production/web -n 20 --json
dockup rollback <deploymentId> production/web --json

Le volume ne revient pas automatiquement à son état précédent avec l’image. Une ancienne version de l’application peut être incapable de lire les fichiers transformés par la nouvelle version. Coordonnez le rollback de l’image avec la restauration d’un snapshot uniquement lorsque les deux opérations sont nécessaires et approuvées.

Cette séparation est importante :

Action de récupération	Modifie l’image ?	Modifie les données du volume ?
Déployer une nouvelle version	Oui	Non, sauf si l’application les migre
Annuler un déploiement	Oui	Non
Restaurer un snapshot	Non	Oui
Restaurer et effectuer un rollback	Oui	Oui

Le processus de déploiement sans interruption protège le basculement du trafic, pas la compatibilité des formats de données.

Qu’est-ce qu’un runbook d’exploitation du stockage durable ?

Attribuez un responsable à chaque volume de production. Le runbook doit contenir :

• Cible du service et ID du volume.
• Chemin de montage et utilisateur d’exécution attendu.
• Taille allouée et seuil d’alerte.
• Description des données et possibilité de reconstruction.
• Planification et conservation des snapshots.
• Dernier snapshot vérifié.
• Politique d’approbation des restaurations.
• Étapes de validation de l’application.
• Notes de compatibilité entre l’image et les données.
• Politique de croissance et de suppression.

Inspectez régulièrement l’utilisation :

dockup volume usage <volumeId> production/web --json

Le CPU, la RAM et le disque sont mesurés à la minute. Le plan Free offre un crédit initial de 10 $, tandis que le plan Pro recommandé coûte 20 $ par mois et inclut 20 $ de crédit d’utilisation.

Exercice de restauration d’un snapshot

N’attendez pas un incident pour découvrir que personne ne sait quel snapshot choisir. Réalisez un exercice contrôlé sur un service hors production ou une copie approuvée :

1. Créez des fichiers de test facilement reconnaissables.
2. Créez un snapshot.
3. Modifiez les fichiers.
4. Restaurez le snapshot.
5. Vérifiez le contenu et les permissions.
6. Observez le redémarrage du conteneur.
7. Notez la durée et les points d’échec.

Un exercice de restauration transforme les volumes persistants et les snapshots, d’une simple case à cocher en une capacité de récupération testée.

Pour la conception initiale d’un service, consultez Du dépôt Git à la production. Pour les détails des commandes, utilisez la référence de la CLI Dockup.

Définir les objectifs de restauration des fichiers

Le RPO indique la quantité de données récentes que l’entreprise peut perdre. Le RTO indique la durée maximale acceptable pour une restauration. Un snapshot quotidien conservé pendant sept copies peut convenir à un cache média interne, mais pas à un produit d’upload utilisateur qui promet une durabilité quasi instantanée.

Documentez ces deux valeurs et mesurez la durée réelle d’une restauration. La vitesse de création du snapshot, la taille des données, le redémarrage du conteneur, la validation des fichiers et la réindexation de l’application contribuent tous à la durée de récupération.

Contrôler la suppression et la croissance des fichiers

Le stockage persistant peut être saturé parce que l’application ne supprime jamais les fichiers temporaires ou remplacés. Ajoutez une politique de conservation au niveau de l’application et distinguez la suppression logique de la suppression physique immédiate. Une courte fenêtre de récupération peut justifier de retarder la suppression définitive.

Avant d’exécuter un nettoyage massif :

1. Mesurez l’utilisation actuelle du volume.
2. Générez la liste des éléments à supprimer.
3. Créez un snapshot.
4. Exécutez le nettoyage par lots limités.
5. Vérifiez les références de l’application.
6. Confirmez la récupération d’espace attendue.

Les volumes persistants et les snapshots jouent ainsi un rôle préventif, et pas uniquement un rôle lors d’un incident.

Vérifier l’inventaire des snapshots

Examinez régulièrement les ID de snapshot, les dates de création, la conservation et le dernier test de restauration réussi. Une tâche configurée mais ne disposant d’aucun snapshot récent et exploitable n’est pas un système de récupération.

Attribuer les droits de restauration

Définissez qui peut approuver une restauration en production et qui effectue la validation post-restauration. Séparer l’approbation de l’exécution réduit le risque que l’urgence fasse contourner la vérification de la cible et du snapshot.

Commencer par un déploiement vérifiable

Créez un volume hors production, prenez un snapshot, modifiez un fichier de test et effectuez un exercice de restauration avant d’y stocker des données de production irremplaçables.

Commencez gratuitement sur app.dockup.ai. Le plan Free coûte 0 $ par mois, inclut un crédit initial de 10 $ et prend en charge un workspace, trois bases de données et trois déploiements.

FAQ

Un volume Dockup survit-il à un déploiement ?

Oui. Le volume reste persistant lorsque les conteneurs du service sont remplacés, à condition que l’application continue d’utiliser le chemin de montage configuré.

Un snapshot de volume est-il une sauvegarde adaptée à PostgreSQL ?

Non. Un snapshot à chaud du répertoire de données d’une base peut ne pas être cohérent du point de vue transactionnel. Préférez le système de sauvegarde de la base de données managée pour les bases de données managées.

Que se passe-t-il lorsqu’un snapshot de volume est restauré ?

Le contenu actuel du volume est remplacé par celui du snapshot sélectionné et le conteneur est redémarré. L’opération doit donc être approuvée et vérifiée.

Dockup peut-il planifier des snapshots de volume ?

Oui. La commande de planification des volumes prend en charge les snapshots quotidiens avec un nombre de copies conservées, et la planification peut être désactivée explicitement.

Le rollback d’une application annule-t-il également les modifications de son volume ?

Non. L’historique des déploiements de l’application et l’historique des snapshots du volume sont distincts. Coordonnez les deux uniquement lorsque le plan de récupération l’exige.