Exploitation
Sauvegarder et restaurer ORKA
Protégez les données de votre plateforme ORKA et préparez-vous à restaurer rapidement votre environnement en cas d’incident.
Une sauvegarde n’est réellement utile que si elle fonctionne, peut être restaurée et a déjà été testée. Ce guide vous accompagne dans la mise en place d’une stratégie simple, fiable et adaptée à un environnement de production.
01
Une sauvegarde doit pouvoir être restaurée
Créer une archive ou un fichier SQL ne suffit pas. Une stratégie de sauvegarde fiable repose sur trois principes : sauvegarder régulièrement, conserver plusieurs versions et tester réellement la restauration.
Sauvegarder
Les données doivent être copiées régulièrement sans dépendre d’une intervention manuelle.
Externaliser
Une copie doit être conservée en dehors du serveur qui héberge ORKA.
Tester
La restauration doit être vérifiée régulièrement sur un environnement isolé.
Sauvegarde automatique depuis ORKA
Un module de sauvegarde automatique accessible depuis le panneau d’administration est prévu pour fin 2026 ou début 2027.
Il permettra de planifier les sauvegardes, gérer leur rotation et superviser leur exécution sans utiliser directement la ligne de commande.
En attendant sa disponibilité, ORKA s’appuie sur les outils standards Linux présentés dans ce guide.
02
Identifier les éléments critiques
Une plateforme ORKA ne se résume pas au code de l’application. Les données métier, les documents téléversés et la configuration locale doivent être sauvegardés ensemble.
Base MariaDB ou MySQL
Elle contient les utilisateurs, les situations, les risques, les incidents, les alertes et l’ensemble des données saisies dans ORKA.
backend/var/
Ce répertoire contient notamment les documents téléversés et les fichiers générés par l’application.
backend/.env.local
Ce fichier contient les paramètres spécifiques à votre installation : base de données, messagerie, LDAP et autres intégrations.
Fichiers ORKA
Une archive complète facilite la reconstruction rapide du serveur après une panne majeure.
Ne sauvegardez pas uniquement le code
Le code ORKA peut être réinstallé. Les données, les documents et la configuration locale sont en revanche propres à votre organisation.
03
Définir une stratégie simple
Pour une installation standard, une politique quotidienne complétée par une copie hebdomadaire et une externalisation régulière offre déjà un bon niveau de protection.
| Élément | Fréquence recommandée | Conservation |
|---|---|---|
| Base de données | Quotidienne | 7 à 30 jours |
| Documents et fichiers ORKA | Quotidienne | 7 à 30 jours |
| Sauvegarde complète | Hebdomadaire | 4 à 12 semaines |
| Copie hors serveur | Quotidienne | Selon votre politique interne |
04
Préparer le répertoire de sauvegarde
Nous allons créer trois répertoires distincts pour séparer la base de données, les fichiers applicatifs et les archives complètes.
Créer l’arborescence
Commande
$ sudo mkdir -p /backup/sql
$ sudo mkdir -p /backup/files
$ sudo mkdir -p /backup/fullVérifier les répertoires
$ tree /backup
/backup
├── files
├── full
└── sql
3 directories, 0 filesContrôle
Les trois répertoires doivent apparaître sans message d’erreur.
05
Sauvegarder la base de données
La base MariaDB ou MySQL contient les données fonctionnelles de votre plateforme. Elle doit être sauvegardée avant les fichiers afin d’obtenir un point de restauration cohérent.
Créer le dump SQL
Commande
$ mysqldump \
--single-transaction \
--routines \
--triggers \
-u orka_user \
-p \
orka > /backup/sql/orka_$(date +%Y%m%d_%H%M).sqlSaisissez le mot de passe de l’utilisateur SQL lorsqu’il vous est demandé. La commande ne retourne généralement aucun message lorsque tout se déroule correctement.
Vérifier le fichier obtenu
$ ls -lh /backup/sql
total 48M
-rw-r--r-- 1 root root 48M Jul 29 02:00 orka_20260729_0200.sqlContrôle
Le fichier SQL doit être présent et sa taille doit être cohérente avec le volume de données contenu dans ORKA.
Un fichier vide n’est pas une sauvegarde
Vérifiez systématiquement la taille du fichier. Un dump de quelques octets indique généralement un problème de droits, d’authentification ou de connexion.
06
Sauvegarder les fichiers ORKA
Cette archive contient les documents téléversés ainsi que la configuration locale nécessaire à la reconstruction de l’environnement.
Créer l’archive
Commande
$ sudo tar -czf \
/backup/files/orka_files_$(date +%Y%m%d_%H%M).tar.gz \
-C /var/www/orka \
backend/.env.local \
backend/varContrôler l’archive
$ ls -lh /backup/files
total 312M
-rw-r--r-- 1 root root 312M Jul 29 02:10 orka_files_20260729_0210.tar.gzVérifier le contenu sans restaurer
Commande de contrôle
$ tar -tzf /backup/files/orka_files_20260729_0210.tar.gz | headbackend/.env.local
backend/var/
backend/var/uploads/
backend/var/uploads/documents/
backend/var/log/
backend/var/cache/07
Automatiser les sauvegardes
Une sauvegarde manuelle finit toujours par être oubliée. L’objectif est donc d’exécuter automatiquement les opérations chaque nuit.
Évitez le mot de passe dans le crontab
Un mot de passe écrit directement dans une commande cron peut être visible par d’autres utilisateurs ou apparaître dans les historiques.
Créer un fichier d’identification MariaDB
[client]
user=orka_user
password=VOTRE_MOT_DE_PASSE
host=localhostProtéger le fichier
Commande
$ sudo chmod 600 /root/.my.cnfPlanifier les sauvegardes
# Base SQL chaque jour à 02 h 00
0 2 * * * mysqldump --single-transaction --routines --triggers orka > /backup/sql/orka_$(date +\%Y\%m\%d_\%H\%M).sql
# Fichiers ORKA chaque jour à 02 h 30
30 2 * * * tar -czf /backup/files/orka_files_$(date +\%Y\%m\%d_\%H\%M).tar.gz -C /var/www/orka backend/.env.local backend/varLe caractère % dans cron
Dans une commande cron, les caractères
% doivent être précédés d’un antislash :
\%.
08
Supprimer les anciennes sauvegardes
Sans politique de rétention, les archives s’accumulent jusqu’à saturer le disque. Dans cet exemple, nous conservons les fichiers pendant trente jours.
Vérification avant suppression
$ find /backup/sql -type f -mtime +30 -print
$ find /backup/files -type f -mtime +30 -printVérifiez d’abord la liste obtenue. Lorsque le résultat est conforme, ajoutez la suppression au crontab.
# Nettoyage chaque jour à 04 h 00
0 4 * * * find /backup/sql -type f -mtime +30 -delete
5 4 * * * find /backup/files -type f -mtime +30 -deleteTestez toujours sans -delete
Une erreur de chemin dans une commande
find peut supprimer des fichiers
qui ne devaient pas l’être.
09
Restaurer ORKA
Une restauration doit être réalisée pendant une fenêtre de maintenance. Les utilisateurs ne doivent pas continuer à modifier les données pendant l’opération.
Attention aux données existantes
La restauration d’un dump SQL remplace l’état actuel de la base par celui contenu dans la sauvegarde.
Restaurer la base de données
Commande
$ mysql -u orka_user -p orka \
< /backup/sql/orka_20260729_0200.sqlRestaurer les fichiers
Commande
$ sudo tar -xzf \
/backup/files/orka_files_20260729_0210.tar.gz \
-C /var/www/orkaRétablir les droits
Commande
$ sudo chown -R orka:www-data /var/www/orka
$ sudo find /var/www/orka -type d -exec chmod 2755 {} \;
$ sudo chmod -R 775 /var/www/orka/backend/varVider le cache et redémarrer les services
Commande
$ cd /var/www/orka/backend
$ sudo -u www-data php8.4 bin/console cache:clear --env=prod
$ sudo systemctl restart php8.4-fpm
$ sudo systemctl restart nginx // Clearing the cache for the prod environment
[OK] Cache for the "prod" environment was successfully cleared.10
Vérifier la restauration
Le redémarrage des services ne suffit pas. Il faut vérifier que les fonctions essentielles d’ORKA sont réellement opérationnelles.
La page de connexion est accessible.
Un administrateur peut se connecter.
Les données métier sont présentes.
Les documents téléversés sont consultables.
Les tableaux de bord se chargent correctement.
Aucune erreur critique n’apparaît dans les journaux.
Consulter les derniers journaux
Commandes de contrôle
$ sudo journalctl -u php8.4-fpm -n 50 --no-pager
$ sudo journalctl -u nginx -n 50 --no-pager
$ tail -n 50 /var/www/orka/backend/var/log/prod.logLa restauration est validée
Une restauration n’est considérée comme terminée qu’après validation de l’application, des données, des documents et des journaux.
11
Bonnes pratiques de sauvegarde
À faire
- Automatiser les sauvegardes.
- Conserver plusieurs versions.
- Externaliser au moins une copie.
- Chiffrer les sauvegardes sensibles.
- Surveiller l’espace disque.
- Tester régulièrement une restauration.
- Sauvegarder avant chaque mise à jour.
À éviter
- Conserver une seule sauvegarde.
- Tout stocker sur le serveur ORKA.
- Ignorer les erreurs de cron.
- Oublier le fichier
.env.local. - Ne jamais vérifier la taille des archives.
- Considérer un dump non testé comme fiable.
La règle 3-2-1
Conservez au moins trois copies de vos données, sur deux supports différents, dont une copie située hors du serveur principal.
12
Dépannage courant
Le fichier SQL est vide
Vérifiez les identifiants MariaDB, les droits de
l’utilisateur SQL et l’espace disponible dans
le répertoire /backup/sql.
La commande tar retourne « Permission denied »
Exécutez la commande avec sudo et
vérifiez que l’utilisateur dispose d’un accès en
lecture sur les répertoires ORKA.
Les fichiers restaurés ne sont pas accessibles
Réappliquez le propriétaire
orka:www-data puis les permissions
du répertoire backend/var.
ORKA affiche une erreur après restauration
Videz le cache Symfony, redémarrez PHP-FPM et
consultez backend/var/log/prod.log.
Le disque de sauvegarde est plein
Vérifiez la rotation des archives, supprimez les anciennes sauvegardes après contrôle et déplacez les copies historiques vers un stockage externe.
Guide terminé
Votre stratégie de sauvegarde est opérationnelle
Votre plateforme ORKA dispose désormais d’une procédure claire pour sauvegarder ses données, conserver plusieurs versions et restaurer l’environnement après un incident.
La prochaine étape consiste à planifier un test régulier de restauration et à externaliser les archives vers un stockage indépendant.