Évaluation Solutions Stockage — Cloud Personnel & Archives¶

Date : 2026
Contexte : Évaluation pour remplacer l'approche MergerFS+SnapRAID (qui nécessite l'acquisition d'un disque parity ≥ 4TB non prévue) par une stratégie réaliste basée sur l'infrastructure existante.
Méthode : Analyse multi-agents parallèles, évaluation exhaustive de 8 solutions.

1. Objectifs¶

Contrainte éliminatoire : plain files + no lock-in. Toute solution stockant les fichiers dans un format propriétaire est éliminée d'office.

1.1 Périmètre utilisateurs¶

Deux niveaux d'utilisateurs :

Noyau familial — alice + nico (utilisateurs complets)¶

• Alice accède à ses données + espace commun alice+nico — pas aux données privées de nico
• Nico idem pour ses données privées — Nico est également admin serveur (SFTPGo + accès complet)
• Nico en tant qu'admin accède à tout y compris /mnt/media/ etc.

Autres utilisateurs — accès hypothétique¶

D'autres utilisateurs disposent d'un compte Authelia existant. Leur usage est très hypothétique : ils ne synceront pas leur propre Google Drive (nécessite leur OAuth), ne feront pas de Takeout autonome, et n'utiliseront pas le serveur comme remplacement de Google Drive.

1.2 Nomenclature de la structure de stockage¶

Question : storage/{alice,nico,alicenico,shared} vs storage/cloud/{...} vs storage/shared/{alicenico,all} ?

Décision : structure plate sans préfixe, family à la place de alicenico¶

storage/
  alice/           ← espace complet alice (drive + photos + archives)
  nico/            ← espace complet nico (drive + photos + archives)
  family/          ← espace commun alice+nico
  shared/          ← optionnel : accessible à d'autres utilisateurs

Pourquoi pas de préfixe cloud/ ? Le dataset storage est entièrement dédié aux données personnelles. Ajouter cloud/ crée un niveau de hiérarchie sans valeur sémantique. rclone comme SFTPGo n'en ont pas besoin.

Pourquoi pas storage/shared/{alicenico,all} ? Nommer un sous-dossier alicenico est technique et fragile (si la composition change). Le regroupement shared/ en tant que parent de plusieurs sous-espaces partagés crée une ambiguïté entre l'espace commun alice+nico et un éventuel espace global. Deux namespaces distincts à la racine (family/ et shared/) sont plus lisibles.

Pourquoi family/ plutôt qu'alicenico/ ? - Sémantique et stable : résiste à l'évolution de la composition - Renommable trivialement en ZFS (zfs rename storage/family storage/foyer) à tout moment

Structure ZFS datasets correspondante :

zfs create storage/alice
zfs create storage/nico
zfs create storage/family
zfs create storage/shared   # optionnel

Création d'espaces partagés ad-hoc via web UI : Oui — entièrement faisable depuis l'interface admin SFTPGo sans CLI : 1. Admin crée un répertoire via SFTPGo (ou SSH) 2. Admin crée un virtual folder pointant dessus 3. Admin assigne ce folder aux utilisateurs voulus (individuellement ou via un groupe dédié)

Pour le noyau familial (alice+nico), le groupe owners gère l'héritage automatiquement. Pour des combinaisons ad-hoc ponctuelles, les share links SFTPGo (sans compte requis côté destinataire) sont souvent suffisants et plus simples qu'un groupe dédié.

2. Contexte Google Photos/Drive — Fait Technique Fondamental¶

Google Photos API : morte depuis le 31 mars 2025.

Le backend gphotos de rclone ne peut plus télécharger que les photos qu'il a lui-même uploadées. Aucune solution de sync continue depuis Google Photos n'est possible en 2025/2026.

Seule voie pour les photos : Google Takeout (export manuel ou semi-automatisé trimestriel).

Google Drive API : toujours fonctionnel. rclone sync/copy fonctionne parfaitement avec le backend drive. Le LXC 102 a déjà le OAuth configuré (direction PBS→GDrive pour les backups) — ajouter une direction PULL est trivial.

Drive partagé : un dossier Google Drive partagé entre alice et nico est accessible depuis les deux comptes Google. Pour le sync rclone côté serveur, une seule paire OAuth suffit (compte propriétaire du dossier). Pas besoin de Service Account.

3. Tableau Comparatif Global¶

4. Évaluations Détaillées¶

4.1 SFTPGo — RECOMMANDÉ ★★★★★¶

Score : 8.2/10

SFTPGo est un serveur de fichiers multi-protocole (SFTP, WebDAV, FTPS, HTTP) conçu pour une exploitation sérieuse avec une empreinte minimale.

Points forts¶

Limitations¶

Modèle d'accès multi-utilisateurs — Detail¶

SFTPGo implémente un système de virtual folders pleinement documenté et éprouvé :

• Un virtual folder = mapping entre un chemin disque réel et un chemin virtuel visible par l'utilisateur
• Aucune limite sur le nombre de virtual folders par utilisateur
• Le même virtual folder peut être assigné à plusieurs utilisateurs avec des permissions différentes (lecture, lecture+écriture) et des quotas distincts
• Le dossier home de chaque utilisateur = leur espace privé (chroot)

Structure sur disque (flat, voir section 1.2) :

/mnt/storage/
  alice/
    drive/         ← rclone PULL drive alice
    photos/        ← Takeout alice
    archives/      ← archives personnelles alice
  nico/
    drive/         ← rclone PULL drive nico
    photos/        ← Takeout nico
    archives/      ← archives personnelles nico
  family/
    drive/         ← rclone PULL dossier Drive partagé
    photos/        ← photos de famille (optionnel : post-Takeout)
    archives/      ← archives communes alice+nico
  shared/          ← optionnel : contenu accessible aux autres utilisateurs
  others/          ← optionnel : espaces individuels pour guests
    {username}/    ← inbox par guest (admin y dépose des fichiers)

Vue alice dans SFTPGo :

/                          ← home = /storage/alice/
  drive/
  photos/
  archives/
  family/                  ← virtual folder → /storage/family/  [rw]
  .snapshots/              ← virtual folder → /storage/.zfs/snapshot/  [ro]

Vue nico dans SFTPGo : identique à alice, home privé distinct (/storage/nico/), même virtual folder family/. Nico dispose en plus du rôle admin SFTPGo (gestion des users, groupes, virtual folders via web UI).

Vue nico (admin) dans SFTPGo :

/
  alice/                   ← virtual folder → /storage/alice/    [rw]
  nico/                    ← virtual folder → /storage/nico/     [rw]
  family/                  ← virtual folder → /storage/family/   [rw]
  others/                  ← virtual folder → /storage/others/   [rw]
  shared/                  → virtual folder → /storage/shared/   [rw]
  media/                   ← virtual folder → /mnt/media/        [ro]
  .snapshots/              ← virtual folder → /storage/.zfs/snapshot/ [ro]

Groupes SFTPGo — gestion via web UI :

• Tout configurable depuis l'interface admin SFTPGo (web UI), sans CLI
• Ajouter alice ou nico = créer le compte + l'assigner à owners + owners-shared — aucune autre config
• Nico dispose en plus du rôle admin SFTPGo (case à cocher lors de la création)
• Virtual folder supplémentaire ad-hoc (ex: partage entre alice et un tiers) : créer le folder + assigner individuellement aux deux users concernés

Modèle autres utilisateurs¶

Les autres utilisateurs ont un compte Authelia mais pas de sync automatique (pas d'OAuth Drive, pas de Takeout). Ce que leur compte SFTPGo apporte :

Recommandation pratique : pour un accès ponctuel, préférer les share links SFTPGo — aucun compte SFTPGo requis côté destinataire. Un compte guest ne se justifie que si l'accès est régulier et persistant.

Déploiement¶

Voir le fichier d'implémentation : storage-implementation.md

4.2 Nextcloud — Alternative si preview/collab nécessaire ★★★★¶

Score : 7/10

Nextcloud classique docker-compose (pas AIO) répond à tous les objectifs mais demande un LXC dédié.

Points forts¶

Modèle d'accès multi-utilisateurs — Détail¶

Nextcloud propose deux mécaniques distinctes pour le multi-utilisateur sur des fichiers externes :

1. External Storage avec variable $user

Mount de /mnt/storage/personal/$user/ en tant que stockage externe → Nextcloud substitue $user par le login de l'utilisateur courant. Alice voit /mnt/storage/personal/alice/, nico voit /mnt/storage/personal/nico/.

• ✅ Isolation stricte des données privées
• ✅ Applicable à tous les utilisateurs d'un groupe en une seule règle admin
• ⚠️ Le répertoire doit pré-exister sur le disque (pas de création automatique)
• ⚠️ Variable $user dans le source path : bug connu (GitHub #10948) — le substitute ne fonctionne que dans le mount point (nom affiché), pas toujours dans le path source selon les versions.
• ⚠️ Après dépôt rclone, occ files:scan --path="$user/files/Drive" requis pour que Nextcloud détecte les nouveaux fichiers

2. Group Folders (app officielle)

Crée un dossier commun visible et accessible simultanément par tous les membres d'un groupe Nextcloud.

• ✅ Alice et nico voient le même dossier Shared/ dans leur interface Files
• ✅ Permissions configurables par groupe et par sous-dossier (lecture / lecture-écriture / création / suppression)
• ✅ Versioning Nextcloud s'applique au dossier partagé
• ❌ Le Group Folder ne peut PAS pointer vers un chemin External Storage — il réside impérativement dans le répertoire data/ interne de Nextcloud (GitHub issue #2897, non résolu en 2024)
• ⚠️ Contournement : monter le chemin externe dans data/__groupfolders/ au niveau OS (symlink ou bind mount) — fonctionne mais fragile

3. Accès admin à /mnt/media/

Via la fonctionnalité External Storage (admin) : monter /mnt/media/ comme stockage externe visible uniquement pour l'admin (ou tout groupe désigné). S'affiche comme un dossier Media dans l'interface Files. Après modification externe, occ files:scan requis.

Structure résultante dans Nextcloud :

alice/
  Files/
    Drive/          ← External Storage ($user path)
    Photos/         ← External Storage ($user path)
    Archives/       ← External Storage ($user path)
    Shared/         ← Group Folder (alice + nico)

nico/ → même structure

admin/ (nico)
  Files/
    Media/          ← External Storage → /mnt/media/
    [+ accès panel admin à tous les fichiers]

Limitations critiques pour cette infra¶

Verdict¶

Recommandé uniquement si le preview inline est indispensable et si la création d'un 7ème LXC est acceptable. La gestion du dossier partagé sur stockage externe est plus complexe qu'avec SFTPGo. Sinon, SFTPGo est supérieur pour ce cas d'usage.

4.3 ownCloud Infinite Scale (oCIS) — Conditionnel ★★★¶

Score : 5.5/10

oCIS est architecturalement moderne (Go, microservices, OIDC first-class) mais sa maturité opérationnelle en 2025/2026 reste préoccupante.

Points forts¶

• OIDC first-class : le meilleur intégrateur OIDC parmi tous les candidats
• PosixFS driver : stockage en plain files sur le disque (NE PAS utiliser le driver par défaut)
• Pas de PostgreSQL requis (base embarquée)

Blocants¶

Note : OpenCloud¶

Fork d'oCIS par l'équipe originale. Même architecture (PosixFS disponible, OIDC natif), décrit comme "much more stable and uses less RAM" par la communauté homelab. Si oCIS est évalué, considérer OpenCloud en parallèle.

4.4 Dufs — Backend WebDAV seulement ★★★¶

Score : 6.5/10

Serveur de fichiers ultra-léger (Rust) avec interface web et WebDAV.

Avantages : 5–15 MB RAM, plain files, WebDAV natif, simple à déployer
Blocant : Aucun système de liens de partage — manque un objectif clé
Usage recommandé : Backend WebDAV pour clients desktop/rclone, pas pour l'accès utilisateur final

4.5 Filestash — ÉCARTÉ ★¶

Score : 4.5/10

Éliminé : OIDC/SSO est derrière paywall ($50/month). Limite à 3 utilisateurs en version gratuite. Ne répond pas aux objectifs sans abonnement commercial.

4.6 Pydio Cells — ÉCARTÉ ★¶

Score : 4.5/10

Éliminé : Intégration OIDC avec provider externe (Authelia) est Enterprise uniquement (€3 280/an). Format "flat" par défaut (lock-in propriétaire). CPU idle ~46% rapporté.

4.7 Seafile — ÉCARTÉ ★¶

Score : 3.5/10

Éliminé : Stockage en blocs propriétaires — les fichiers ne sont PAS stockés en plain files sur le disque. rclone ne peut pas déposer des fichiers que Seafile découvrira. CPU idle ~20% constant. Incompatible avec le principe de non-lock-in.

Note : /mnt/storage/seafile/ existe mais reste vide — peut être supprimé.

4.8 Syncthing — ÉCARTÉ ★¶

Score : 2/10

Éliminé : Outil de synchronisation P2P entre appareils, pas un gestionnaire de fichiers cloud. Ne peut pas se connecter à Google Drive. Aucune interface de navigation de fichiers. Aucun lien de partage. Mauvais outil pour ce besoin.

4.9 ZFS — Couche Stockage (pas une solution autonome)¶

Score couche stockage seule : 6.5/10
Score combiné ZFS + SFTPGo : 8/10

ZFS sur l'IronWolf 4TB (sdd) est la fondation recommandée pour remplacer l'ext4 actuel.

À éviter : déduplication ZFS (5 GB RAM par TB de table DDT).

Tooling admin recommandé : - Sanoid : snapshots automatiques (daily×7, weekly×4, monthly×3) — standard éprouvé 15 ans - ZfDash (v1.8.7-beta) : interface web ZFS déployable en Docker, actif en 2025/2026 - Cockpit+ZFS : meilleure UI, mais risqué sur hôte Proxmox/Debian 12 (conflits packages) - WebZFS : trop récent (projet "AI slop" selon Reddit 2025) — non recommandé

5. Conclusion et Suite¶

Solution retenue : ZFS (IronWolf 4TB) + Sanoid + SFTPGo v2.7.1+ + ZfDash
Utilisateurs : alice + nico (admin), espace commun family/, guests via share links
Structure disque : storage/{alice,nico,family}/ — datasets ZFS indépendants

→ Plan d'implémentation complet : storage-implementation.md

Document issu d'une évaluation multi-agents exhaustive des solutions Nextcloud, Seafile, oCIS, SFTPGo, Pydio Cells, Filestash, Dufs, Syncthing et ZFS natif.