Les objets fondamentaux de l'application
Presque tout ce que vous manipulez dans Fulgurite peut être rattaché à l'une des briques ci-dessous.
Dépôt
Backend Restic connu par l'application, avec son chemin, son secret, son seuil d'alerte et sa politique de notification.
Backup job
Tâche qui décrit quoi sauvegarder, vers quel dépôt et avec quelles options : horaires, rétention, hooks, retries, notifications et exécution locale ou distante.
Copy job
Tâche de réplication via restic copy vers une autre destination, utile pour l'offsite ou une deuxième cible.
Snapshot
État sauvegardé dans un dépôt. Il peut être exploré, comparé, téléchargé, retagué, supprimé ou restauré.
Restauration
Opération de récupération locale ou distante, complète ou partielle, historisée avec statut, destination, logs et auteur.
Scheduler et worker
Le scheduler décide quoi lancer à chaque passage du cron central. Le worker traite la file interne et certaines tâches de fond.
Cycle de vie d'une sauvegarde dans Fulgurite
Comprendre ce cycle rend beaucoup plus lisibles les décisions d'architecture du produit.
- Création d'un dépôt. Vous enregistrez un backend Restic avec son secret.
- Création d'un job. Vous décrivez les sources, la cible, les options de rétention, les notifications et la politique de retry.
- Déclenchement. Le job part manuellement ou via le cron central selon le fuseau horaire de planification configuré.
- Production d'un snapshot. Le dépôt s'enrichit, l'application rafraîchit ses indexes et son statut runtime.
- Consultation. L'utilisateur explore le snapshot, recherche un fichier ou compare deux versions.
- Restauration. Il restaure tout ou partie du snapshot en local ou à distance, puis l'opération est ajoutée à l'historique.
Rôles, permissions et scopes
Fulgurite combine une logique de rôle, une matrice de permissions et des périmètres de visibilité plus fins sur les dépôts et les hôtes.
| Niveau | Ce qu'il porte | Exemples |
|---|---|---|
| Rôle | Position hiérarchique du compte. Les rôles système sont comparés par niveau. | viewer, operator, restore-operator, admin |
| Permission | Droits applicatifs précis utilisés pour afficher ou autoriser les actions. | repos.manage, restore.run, scheduler.manage |
| Scope repo / host | Restriction de visibilité sur un sous-ensemble de dépôts ou d'hôtes. | Un opérateur peut gérer seulement certains dépôts. |
repo_scope et host_scope filtrent silencieusement les ressources visibles. Un utilisateur scopé ne voit ni dans l'interface, ni via l'API, les dépôts ou les hôtes qui sortent de son périmètre : l'application n'affiche pas d'erreur « accès refusé », ces ressources sont simplement absentes de la liste qui lui est renvoyée. C'est une conception voulue, utile pour cloisonner des équipes sur une même instance.Glossaire rapide
Cron central
Entrée cron système unique qui appelle le moteur de planification. Il n'existe pas une ligne cron par job.
Worker dédié
Processus CLI chargé du traitement de la file interne, avec heartbeat, détection des workers obsolètes et gestion systemd possible.
Notification policy
Configuration déclarative des canaux à utiliser pour un profil d'événement donné, avec héritage possible.
Retry policy
Stratégie de reprise d'un job en cas d'erreur, décidée à partir d'une classification des sorties et codes de retour.