Réglages

Compte Claude

Compte Backblaze

Identifiants communs à tous les projets ; chaque projet ne choisit qu'un bucket.

Sous-domaines des projets

Une adresse par projet plutôt qu'un port : projet.dev.exemple.com. Le domaine doit pointer sur cette machine par un enregistrement DNS générique (*.dev.exemple.com) ; o2Chat écrit la configuration nginx et la recharge à chaque démarrage de stack. Vide : les projets s'ouvrent par leur port.

Utilisateurs

Restaurer la base de données

Sauvegardes d'un client hors de portée

Quand la production d'un client n'est joignable ni par VPN ni par SSH, on inverse le sens : c'est son serveur qui pousse ses sauvegardes vers Backblaze, et o2Chat les y lit. Aucun port à ouvrir chez lui, aucun accès à nous confier.

  1. Deux buckets chez Backblaze

    Un pour les dumps, un pour les filestores — le second doit porter filestore dans son nom, c'est ainsi que le sélecteur rapproche une archive de son dump. Un seul bucket pour les deux fonctionne aussi : dumps et archives partagent alors le même dossier.

    Pense à poser une règle de cycle de vie sur chaque bucket (« garder les n derniers jours ») : c'est Backblaze qui fait le ménage, le script n'efface jamais rien à distance.

  2. La clé que le client utilisera

    Une clé d'application dédiée, qui écrit sans pouvoir lire ni effacer : même égarée, elle ne donne accès à aucune sauvegarde. Elle n'est affichée qu'une fois — Backblaze ne la redonne jamais.

    Une clé Backblaze ne se restreint qu'à un seul bucket : pour deux buckets, génère deux clés — ou n'en restreins aucune.

  3. Le script sur le serveur du client

    Un script shell autonome : il découvre les projets Docker de la machine, sort les bases et les filestores en flux (sans copie intermédiaire) et les envoie chez Backblaze.

    Prérequis sur sa machine : Docker, et le client Backblaze (pipx install b2).

    sudo install -m 750 o2-backup.sh /usr/local/bin/o2-backup
sudo o2-backup install

    Puis les clés, la découverte des projets, et une vérification qui n'envoie rien :

    sudo o2-backup b2
sudo o2-backup detect --write
sudo o2-backup check

    detect lit les conteneurs en marche et écrit /etc/o2-backup/projects.conf — un projet par ligne, à corriger à la main si la machine héberge des montages inhabituels.

  4. Un premier envoi, puis le rendez-vous quotidien

    sudo o2-backup run
    sudo o2-backup schedule --at 02:30

    Un timer systemd (ou une ligne de cron à défaut), un verrou qui empêche deux sauvegardes de se chevaucher, et le journal dans /var/log/o2-backup.log.

  5. Côté o2Chat

    Dans Réglages → Compte Backblaze, la clé de lecture de l'installation. Puis, dans les réglages de ce projet, le bucket et le nom de fichier — celui-ci préremplit la recherche du sélecteur de sauvegardes.

    Les objets arrivent sous cette forme, dump et filestore partageant dossier et horodatage — c'est ce qui permet de proposer d'office la bonne archive :

    odoo-database/   batimax-19/batimax_19-20260821-0230.dump
odoo-filestore/  batimax-19/batimax_19-20260821-0230_filestore.tar.gz

Journaux des conteneurs

Coche les conteneurs dont tu veux suivre le journal.


  




  

    
Stack Docker du projet

    
  

  

  

  


  

  
  
  
  


  

    
    
    
    
  




  

    
Modifications

    
  

  

  

    

    

  

  




  

    

      
Publier et déployer

      
    

    


    
  


  

    

      
      
    

    

    
    


    

    

    
    


    

      
      
      
    

  


  

  



  

    
Supprimer le projet

    
  

  

  

  
  

    
    

    

      
      
      
    

  




  

    

      
Identifiants du dépôt

      
    

    

    

      
      
    

    
Ces identifiants servent une seule fois, pour ce clonage.
      Ils ne sont ni enregistrés en base, ni inscrits dans la configuration du dépôt.