fren
Connexion

Sauvegarder les données d'une application

3 min de lecture07 novembre 2026

Une sauvegarde non testée est une hypothèse. Pour une application Python, les données se répartissent entre fichiers téléversés, base de données et configuration. L'objectif est d'obtenir une copie cohérente, lisible ailleurs que sur le serveur, et dont la restauration a déjà été vérifiée.

1. Inventorier ce qui compte

Donnée Emplacement courant Méthode
Fichiers utilisateurs dossier uploads/ archive tar
Base SQLite fichier .db ou .sqlite3 sauvegarde native SQLite
MySQL ou PostgreSQL serveur de base mysqldump ou pg_dump
Configuration variables du panneau export chiffré, hors dépôt
Code dépôt Git clone ou archive de version

Les logs, caches, environnements virtuels et fichiers __pycache__ ne méritent pas d'être sauvegardés : ils sont recréables et alourdissent l'archive. En revanche, un jeton ou une clé d'application est une donnée critique : sans lui, l'application restaurée ne redémarre pas.

2. Copier de façon cohérente

Copier un fichier de base pendant une écriture peut produire une image incohérente. Utilisez la méthode propre à chaque moteur.

SQLite dispose d'une commande de sauvegarde qui gère le mode WAL :

Bash
sqlite3 /var/www/mon-app/app.db ".backup '/tmp/app.db'"

MySQL et MariaDB, sur des tables InnoDB :

Bash
mysqldump --single-transaction --routines --triggers \
  --default-character-set=utf8mb4 \
  -u utilisateur -p VOTRE_BASE > /tmp/base.sql

PostgreSQL :

Bash
pg_dump -Fc -U utilisateur VOTRE_BASE > /tmp/base.dump

Pour les fichiers, créez une archive en excluant l'inutile :

Bash
tar -czf /tmp/app-fichiers.tar.gz \
  --exclude='.venv' --exclude='__pycache__' \
  -C /var/www mon-app

Sur l'hébergement d'applications, utilisez le gestionnaire de fichiers du panneau ou l'accès SFTP s'il est proposé. Si le panneau propose une sauvegarde de base, déclenchez-la depuis l'interface prévue ; sinon, exportez la base avec l'outil mis à disposition. N'inventez pas de commande shell si le panneau n'en fournit pas.

3. Sortir la copie du serveur

Une archive laissée dans le même disque ne protège ni d'une suppression accidentelle ni d'une panne. Téléchargez-la, puis copiez-la vers une autre machine :

Bash
scp /tmp/app-fichiers.tar.gz utilisateur@machine-de-sauvegarde:/sauvegardes/

Conservez trois copies, sur deux supports, dont une hors site. Si l'archive contient des données personnelles, chiffrez-la avant transfert avec age ou gpg. Nommez les fichiers avec la date et l'application, par exemple mon-app-2026-11-07.tar.gz.

4. Restaurer et tester

Restaurez d'abord dans un emplacement isolé, jamais par-dessus la production :

Bash
mkdir -p /tmp/restauration
tar -xzf mon-app-2026-11-07.tar.gz -C /tmp/restauration

Pour la base, créez une base de test, importez le dump, comparez le nombre de lignes des tables principales et ouvrez l'application. Vérifiez les permissions des fichiers restaurés. Une restauration qui échoue silencieusement est plus dangereuse qu'une absence de sauvegarde, car elle donne une fausse assurance.

5. Automatiser et vérifier

  • Planifiez la copie quotidienne avec cron sur un VPS, ou utilisez la sauvegarde du panneau si elle est proposée.
  • Conservez par exemple sept copies quotidiennes et quatre hebdomadaires.
  • Surveillez l'échec de la tâche : une sauvegarde vide ou de taille anormale doit alerter.
  • Refaites un test de restauration après chaque changement majeur de schéma.

Les sauvegardes incluses dans une offre ne remplacent jamais une copie hors site testée.

Publicité

Cet article vous a-t-il aidé ?

À lire aussi