apcom solutions SA · infrastructure 2026

Parc serveurs

Deux VPS et un stockage objet, chez Infomaniak (Suisse). Chaque cible est sauvegardée une fois par jour sur Swiss Backup, dans un datacenter distinct, chiffrée côté client.

2 VPS + 1 cloud objet 3 coffres Swiss Backup 100% Suisse · Infomaniak Chiffré côté client
Le parc

Carte du concept serveur

Production à gauche (Infomaniak), sauvegardes à droite dans un datacenter distinct (Swiss Backup 02). Chaque flèche = une sauvegarde quotidienne chiffrée. Survol d'une machine : isole son flux. Chaque fiche plus bas regroupe tout sur un serveur : capacités et sauvegarde.

Parc opérationnel · Infomaniak
CORPUS
VPS · dev & services internes
MORDOR
VPS · production
MAMOUT
Cloud objet · fichiers applicatifs
03:30restic · chiffré
03:30restic · chiffré
04:00via MORDOR
Parc de rétention · Infomaniak Swiss Backup (site séparé)
coffre corpus
SBI-GL504089 · ~1,3 Go
coffre mordor
SBI-GL079059 · /etc
coffre mamout
SBI-GL257484 · objets
CORPUS
Développement & services internes
Processeur 4 vCPU · EPYC-Rome
Mémoire 12 Go
Disque 8,1 / 19 Go
45% utilisé
OS Ubuntu 24.04 LTS
Hôte ov-e26632
IP 195.15.213.158
État actif
Sauvegarde Swiss Backup
Coffrecorpus · SBI-GL504089
ContenuVaultwarden, Forgejo, Odoo (dumps à chaud), SituLab, configs
Quandtous les jours à 03:30 UTC
MORDOR
Production
Processeur 4 vCPU · EPYC-Genoa
Mémoire 12 Go
Disque 2,3 / 19 Go
13% utilisé
OS Ubuntu 24.04 LTS
Hôte ov-fba72b
IP 179.237.127.114
État prêt (migration Kreativ / Tizoo)
Sauvegarde Swiss Backup
Coffremordor · SBI-GL079059
Contenu/etc (dumps + données ajoutés à la migration)
Quandtous les jours à 03:30 UTC
MAMOUT
Stockage objet · fichiers applicatifs
Type Public Cloud OpenStack
Modèle Objet (S3 / Swift)
Région dc4-a (Suisse)
ID espace 24974
Capacité élastique
Projets GLiM cloud · GLiM mutualisée
État bascule GLiM en cours · 0 objet
Sauvegarde Swiss Backup
Coffremamout · SBI-GL257484
Contenuconteneurs objet des 2 projets
Commentporté par MORDOR (rclone → restic)
Quandtous les jours à 04:00 UTC
Pourquoi ces choix

  • Autonomie & administration complète : accès root, on maîtrise l'OS, les versions, la configuration — pas de boîte noire.
  • Scalabilité à la volée : vCPU, RAM et disque augmentables en live, selon les besoins réels, sans refonte ni migration.
  • Politique Docker : chaque service tourne dans son conteneur isolé → déploiement reproductible, mises à jour maîtrisées, retour arrière simple, pas de dépendances qui s'entrechoquent.
  • Souveraineté : tout reste sur notre infrastructure, en Suisse.

  • Séparation des métiers : le calcul reste sur le VPS, le stockage de fichiers part sur l'objet. Chacun son rôle, chacun son dimensionnement.
  • On sort les fichiers des logiciels : plus de fichiers lourds qui gonflent le disque du VPS → serveur léger, rapide, sauvegarde du VPS plus petite.
  • Standard S3 / Swift : accessible par API, norme S3 universelle → interopérable, portable, pas de verrou propriétaire.
  • Capacité élastique : la volumétrie grandit sans toucher au serveur.
Deux parcs Infomaniak complémentaires : opérationnel + rétention

Tout est chez Infomaniak, réparti sur deux parcs aux rôles distincts. Le parc opérationnel (VPS + Public Cloud) fait tourner les services : Infomaniak y garantit la disponibilité, mais pas la sauvegarde — « Infomaniak ne réalise pas de sauvegarde automatique des données Client » (CGU Public Cloud, art. 7.2). Le parc de rétention (Swiss Backup) assure, lui, la récupération.

Parc opérationnel — ce qu'Infomaniak garantit (inclus)
ServeurTypeLocalisationRedondance / disponibilitéSauvegarde incluseChiffrement au reposSLA mensuel
CORPUS VPS Cloud Suisse (Genève) Infra redondée, haute dispo matérielle aucune (snapshots ≠ sauvegarde) aucun (assuré au parc de rétention) 99,99%
MORDOR VPS Cloud Suisse (Genève) Infra redondée, haute dispo matérielle aucune (snapshots ≠ sauvegarde) aucun (assuré au parc de rétention) 99,99%
MAMOUT Public Cloud · stockage objet (Swift) Suisse (Genève) Multi-copies (durabilité) · Ceph bloc : 3 réplicas aucune (art. 7.2) AES-256 (Infomaniak) 99,90%
Datacenters propriété d'Infomaniak, en Suisse · certifiés ISO 27001, 9001, 14001, 50001. Snapshot Infomaniak à la demande : avant une maintenance ou une mise à jour risquée, on fige un point de retour instantané (rollback rapide sur le parc opérationnel). Mais le snapshot reste local : il protège de la panne matérielle, pas d'une suppression, d'une corruption ou d'un ransomware. Ce n'est pas une sauvegarde.
Parc de rétention — Swiss Backup (service Infomaniak, site distinct de l'opérationnel)
  • Quoi : une copie chiffrée, versionnée et hors-site de ce qui est irremplaçable (bases, dépôts, coffre, fichiers, configs).
  • Où : un datacenter Infomaniak distinct de la production (Swiss Backup 02), en Suisse — 1 coffre isolé par serveur.
  • Comment c'est chiffré : restic, AES-256, côté client. La clé ne quitte jamais nos serveurs (gardée dans Vaultwarden) : Infomaniak ne peut pas lire le contenu.
  • Pourquoi : parce qu'Infomaniak ne sauvegarde pas (art. 7.2) et que la redondance n'est pas une sauvegarde.
3
copies
2
supports
1
hors site
Contre quoi ça protège
MenaceParc
opérationnel		Parc
rétention
Panne matérielle
Indisponibilité (SLA)
Suppression accidentelle
Corruption / bug applicatif
Ransomware / compromission
Erreur humaine (ex. drop base)
Sinistre du datacenter prod
Perte d'accès au compte
Jusqu'où je peux restaurer

Conséquence directe du parc de rétention : la rétention des coffres (identique sur les 3) fixe la profondeur de récupération. En remontant dans le temps, la finesse diminue : fin de journée, puis fin de semaine, puis fin de mois.

14 jours · un point chaque jour puis 8 semaines · un point par semaine (le dimanche) puis 12 mois · un point par mois (fin de mois)
CORPUS
depuis le 12.10.2026
chaque jour14 j
1 / semaine8 sem.
1 / mois12 mois
MORDOR
depuis le 12.10.2026
chaque jour14 j
1 / semaine8 sem.
1 / mois12 mois
MAMOUT
depuis le 13.10.2026
chaque jour14 j
1 / semaine8 sem.
1 / mois12 mois
aujourd'hui− 14 j− 2 mois− 1 an
Les 3 derniers snapshots sont conservés quoi qu'il arrive (garde-fou anti-purge). Ci-dessus = la profondeur cible. L'historique réel se constitue jour après jour : les coffres viennent d'être ouverts (12–13.10.2026), la zone « mois » se remplira au fil des mois.
Horaires (UTC · Suisse = UTC+1/+2) — créneaux décalés pour ne pas se chevaucher
00h 06h 12h 18h 24h 03:30 UTC Sauvegarde + rétention — CORPUS & MORDOR 04:00 UTC Sauvegarde + rétention — MAMOUT (via MORDOR · rclone → restic) 06:00 UTC Veille A — contrôle des rétentions des 3 coffres (snapshots · volume · restic check)
systemd timer · Persistent : rattrape la passe si la machine était éteinte. Chaque passe de sauvegarde applique aussi sa politique de rétention (restic forget --prune) ; la Veille A vérifie, deux heures après, que les rétentions des trois coffres sont saines. Déclenchement manuel possible à tout moment (ex. avant une maintenance) : une sauvegarde Swiss Backup complète à la demande, en plus de la passe quotidienne.
Organisation

Qui héberge quoi

Un métier par machine, séparation nette : CORPUS ne reçoit aucune application client, MORDOR aucun outil interne, MAMOUT aucun logiciel. Chaque VPS repose d'abord sur un socle commun, posé avant tout service.

Répartition par métier
VPSRôleHébergeÉtat
CORPUS Socle interne & gouvernance APCOM Vaultwarden · Forgejo (KERNEL/code) · Odoo GLiM · SituLab signserver · nginx + Let's Encrypt en service
MORDOR Production applicative clients Logiciels & applications migrés de Kreativ Medias / Tizoo en montage
MAMOUT Stockage objet Fichiers sortis des applications (S3 / Swift) câblé, vide
Socle commun à tout VPS (posé avant tout service)
  • Docker + Compose — services conteneurisés, isolés et reproductibles.
  • nginx + Let's Encrypt — reverse proxy, terminaison TLS, routage des domaines.
  • restic — sauvegarde déportée Swiss Backup (voir SWISSBACKUP.md).
  • Agent de veille — relevé sauvegarde + dette techno pour le hub CORPUS.
  • ufw + fail2ban — pare-feu et protection anti-force brute.
  • Headscale (contrôleur VPN auto-hébergé sur CORPUS, vpn.apcom.app) + clients Tailscale — réseau privé maillé souverain (relais DERP embarqué) ; les panneaux d'administration ne sont accessibles que par lui, jamais exposés sur Internet.
Mises à jour : 100 % manuelles

Aucune mise à jour automatique, y compris sécurité (pas d'unattended-upgrades). Toute mise à jour — système ou image Docker — est planifiée à partir du rapport mensuel de dette technologique ci-dessous. La décision reste humaine.

Trajectoire de migration (Kreativ Medias / Tizoo → MORDOR)
Phase 1 les logiciels migrent vers le VPS (MORDOR) ; les fichiers sortent des logiciels vers MAMOUT. Phase 2 les applications migrent vers MORDOR. Détail : SERVEURS/ORGANISATION_VPS.md · sources : KREATIV_PLESK.md, TIZOO.md, VPSFLEX-edirekt.md.
Panneau d'administration — open source, un par machine (fin de Plesk)

Sous Docker, pas d'équivalent Plesk monolithique : les rôles se séparent (un reverse proxy route les domaines vers les conteneurs ; un panneau observe et pilote). Choix 100 % open, un panneau par machine selon sa nature, accès réservé au réseau privé souverain Headscale (contrôleur auto-hébergé sur CORPUS, clients Tailscale). Mail non hébergé : boîtes dirigées vers les services e-mail Infomaniak (APCOM revendeur).

CORPUSPortainer CE — vue d'ensemble & pilotage des conteneurs ; nginx + Let's Encrypt conservés (non invasif, zéro risque sur l'existant). MORDORCoolify — PaaS open : déploiement d'apps, domaines, SSL, bases et sauvegardes DB vers Swiss Backup (S3) ; pose le reverse proxy dès l'origine (serveur vierge). Coolify retenu plutôt que Dokploy : plus mature, communauté & documentation plus larges, multi-serveurs SSH prêt pour une vision macro ultérieure.
Exploitation

Veille & entraînement plan · à mettre en œuvre

Trois dispositifs pilotés depuis un hub unique, CORPUS, qui voit les trois coffres : une veille quotidienne des sauvegardes, une veille mensuelle de la dette technologique, et un exercice de restauration trimestriel en équipe.

Hub de veille · CORPUS

CORPUS voit les trois coffres (le sien en local, MORDOR par SSH, MAMOUT par SSH → MORDOR) et porte un conteneur Docker unique, exposé à vigi.apcom.app, qui héberge les deux logiciels de veille (A + B) et sert deux pages web : une page publique « état de nos services » (feux vert/rouge, sans nommer client, instance ni domaine) et une page privée par login où les développeurs consultent le détail et les rapports des deux veilles. Principe : aucun journal ni rapport dans le KERNEL — tout est stocké et servi par vigi.apcom.app. Prérequis : clé SSH restreinte CORPUS → MORDOR · relais SMTP d'un serveur existant · destinataires admin (à définir).

OBSERVÉ Veille A — 3 coffres restic • CORPUS — en local • MORDOR — par SSH • MAMOUT — SSH → MORDOR (rclone) snapshot · volume · restic check · succès + état des rétentions (forget --prune) Veille B — tous les VPS (a) système — apt, sécurité, noyau, reboot (b) Docker — image:tag en service vs version disponible collecte locale + SSH vers les autres VPS CORPUS hub de veille Docker · conteneur unique vigi.apcom.app logiciel de veille A + B Veille A sauvegardes · rétention quotidienne timer ~06:00, après backups Veille B dette technologique mensuelle timer mensuel vigi.apcom.app — ACCÈS WEB Page publique — état de nos services CORPUS tourne MORDOR tourne MAMOUT tourne Rétention OK · dernier Swiss Backup JJ.MM.AAAA hh:mm:ss Feux vert / rouge sans nommer client, instance ni domaine Page privée — login développeur Détails + rapports Veille A (journal des contrôles) Détails + rapports Veille B (dette techno) historique complet, par cible et par VPS Email admins uniquement si ALERTE — zéro bruit quotidien
Veille A · sauvegardes (quotidienne)

Chaque jour, après les passes de backup, CORPUS contrôle les trois coffres à l'identique : âge du dernier snapshot, volume rapatrié, intégrité (restic check), succès/échec de la passe.

  • Verdict par cible : OK / ALERTE.
  • Journal uniforme (1 ligne/jour/cible) stocké et servi par vigi.apcom.app — page privée ; rien dans le KERNEL.
  • Email aux admins seulement si ALERTE — zéro bruit quotidien.
ALERTE = échec, aucun snapshot < 24 h, check KO, ou volume nul inattendu.
Veille B · dette technologique (mensuelle)

Une fois par mois, un rapport sur l'obsolescence de tous les VPS, pour planifier (jamais appliquer automatiquement) :

  • Système : paquets à mettre à jour, correctifs de sécurité, redémarrage requis, noyau.
  • Docker client : image + tag en service vs version disponible, images en retard / EOL.
Rapport mensuel servi par vigi.apcom.app (page privée) + email · deux sections : MAJ serveurs à planifier / MAJ images & logiciels à planifier. Rien dans le KERNEL.
Exercice de restauration · trimestriel (« game day » non destructif)

Une fois par trimestre, l'équipe prouve qu'elle sait remonter un projet réel depuis Swiss Backup. On ne détruit rien : on déclare « ce projet est perdu », on le restaure en parallèle (chemin / nom / instance temporaire), on compare au vivant, on mesure le temps réel (RTO), on nettoie.

1 Choisir une cible réelle (en rotation) et déclarer la perte.
2 Restaurer en parallèle + démarrer une copie de test.
3 Prouver, mesurer, nettoyer, consigner le compte-rendu.
La production n'est jamais touchée · Protocole complet : SERVEURS/PROTOCOLE_RESTAURATION.md
Services

Services par machine

ServiceRôleMachineTechniqueÉtat
VaultwardenCoffre à mots de passeCORPUSSQLiteen service
ForgejoDépôts Git & gouvernance (KERNEL)CORPUSPostgreSQL 16 · 1,8 Goen service
Odoo GLiMERP / gestionCORPUSOdoo 19 · PostgreSQL 16en service
SituLab signserverServeur de signatureCORPUSservice dédiéen service
Nginx + Let's EncryptReverse proxy & TLSCORPUSnginxen service
GLiM — version cloudPhase 1 : externalisation fichiers → MAMOUT + patch codeMAMOUT → MORDOROpenStack Swift/S3en cours
GLiM — version mutualiséePhase 1 : externalisation fichiers → MAMOUT + patch codeMAMOUT → MORDOROpenStack Swift/S3en cours
Parc à migrerTizoo & Kreativ Medias : logiciels → VPS, fichiers → MAMOUT, puis applications → MORDORMAMOUT / MORDOR—à venir
Bascule en 2 temps : 1) fichiers externalisés vers MAMOUT + adaptation du code (en cours) · 2) applications déplacées sur MORDOR (à venir).