Nextcloud auto-hébergé sur un VPS : remplacer Google Drive par un serveur que vous contrôlez

Ce que vous remplacez réellement, et ce que vous ne remplacez pas

Nextcloud est, une fois débarrassé de son marketing, une application PHP qui tient une base de données des métadonnées des fichiers et un répertoire de leur contenu, et qui parle suffisamment de protocoles pour que les appareils ordinaires le traitent comme un compte cloud normal. Cette description sous-estime la part de votre vie numérique qu'il couvre discrètement. La synchronisation de fichiers est la partie visible, et c'est celle pour laquelle on l'installe. Les parties qui s'avèrent importantes six mois plus tard sont celles que personne ne montre en démonstration : les calendriers et les contacts via CalDAV et CardDAV, si bien que les applications natives de votre téléphone cessent de parler à un fournisseur de messagerie ; une photothèque avec envoi automatique de la pellicule, ce qui est, concrètement, ce qui permet à un foyer d'abandonner Google Photos ; et des notes, des tâches et des favoris qui ne sont plus éparpillés dans quatre comptes que vous ne contrôlez pas.

Il vaut la peine d'être précis sur la comparaison, car le cadrage habituel est erroné. Personne ne s'auto-héberge pour économiser sur les gigaoctets — une offre grand public avec deux téraoctets coûte à peu près ce que coûte un VPS milieu de gamme, et cela sans aucun travail. Vous vous auto-hébergez parce que l'alternative est une relation dans laquelle la contrepartie détient les données, fixe les conditions, scanne le contenu pour vérifier sa conformité à ses règles, et traite les demandes judiciaires vous concernant sans aucune obligation de vous en informer au préalable. Supprimer cette contrepartie, voilà tout le produit. Tout le reste est un effet secondaire, agréable pour une part, et de votre nouvelle responsabilité pour l'autre.

Ce que vous n'obtenez pas, et ne devez pas attendre, c'est le socle opérationnel invisible qu'un hyperscaler fournit gratuitement. Il n'y a pas de réplication multirégion à moins que vous ne la construisiez vous-même. Il n'y a pas de réseau de périphérie qui rend un gros téléchargement rapide depuis l'autre bout de la planète. Il n'y a pas de file d'assistance qui retrouve votre fichier quand vous le supprimez et videz la corbeille le même après-midi. Quand le disque se remplit à trois heures du matin, les clients de synchronisation de cinq appareils se mettent à afficher des icônes rouges, et la personne qui répare cela, c'est vous. Ce n'est pas un argument contre le fait de le faire — c'est le cahier des charges du travail que vous acceptez.

La dernière chose à voir avec lucidité, c'est la cadence des mises à jour. Nextcloud publie plusieurs versions majeures par an, les mises à niveau doivent être appliquées une version majeure à la fois, et les applications tierces dont vous êtes venu à dépendre accusent parfois un retard d'une version. Ce n'est pas un travail difficile, et l'outil de mise à jour intégré, associé à un instantané pris au préalable, en fait une affaire de quinze minutes, mais c'est un travail récurrent assorti d'une échéance : une instance en retard de trois versions majeures est une instance que vous ne pouvez pas mettre à niveau en une seule étape, et que vous ne pouvez pas non plus exposer sans risque à Internet.

La machine : dimensionner pour un serveur de fichiers, pas pour un site web

La plupart des guides d'auto-hébergement dimensionnent un serveur en fonction de son application. Ici, l'application n'a presque aucune importance et c'est la bibliothèque qui compte entièrement. Le processus PHP, le serveur web, la base de données et le cache tiennent ensemble confortablement dans un ou deux gigaoctets de RAM sous une charge domestique ; ce qui détermine votre offre, c'est le nombre d'octets que vous placez sur le disque et le nombre de fichiers individuels entre lesquels ces octets sont répartis — deux contraintes distinctes qui échouent chacune d'une manière différente.

Commencez par l'inventaire honnête plutôt que par celui que vous espérez. Les documents et les feuilles de calcul sont négligeables — une décennie d'entre eux dépasse rarement dix gigaoctets. La pellicule du téléphone, elle, ne l'est pas : un téléphone moderne produit entre quinze et quarante gigaoctets par an et par personne, vidéo comprise, et activer l'envoi automatique pour une famille de quatre personnes revient à s'engager sur environ cent gigaoctets par an, qui arrivent que vous y pensiez ou non. Ajoutez ensuite une marge par-dessus la bibliothèque brute : les aperçus générés pour les images et les vidéos, les versions de fichiers conservées pour les documents modifiés, et une corbeille qui, par défaut, conserve les fichiers supprimés pendant jusqu'à trente jours et compte sur le même disque. Un chiffre de travail correspondant à la bibliothèque plus vingt pour cent est réaliste, et ces vingt pour cent sont la part que l'on oublie jusqu'à ce que le disque soit à quatre-vingt-quinze.

La mémoire est la deuxième contrainte, et elle est bien moins coûteuse à satisfaire. Quatre gigaoctets font tourner une instance mono-utilisateur sans drame. Huit est le chiffre confortable pour un foyer ou une petite équipe, car cela permet de donner à PHP-FPM assez de processus pour absorber plusieurs clients de synchronisation qui se réveillent en même temps, d'attribuer à la base de données un véritable pool de mémoire tampon, et de garder encore de la place pour que le cache de pages du système d'exploitation conserve les métadonnées actives en mémoire. Ce chiffre ne change vraiment que si vous ajoutez Nextcloud Office, qui fait tourner un moteur complet de conversion de documents dans son propre conteneur et veut deux à quatre gigaoctets pour lui seul avant même que quiconque n'ouvre une feuille de calcul.

Le CPU ne se fait presque pas sentir en régime permanent, puis compte intensément pendant environ une semaine. Générer les aperçus d'une photothèque existante est la chose la plus lourde que ce serveur aura à faire — chaque image est décodée puis ré-encodée en plusieurs tailles — et sur une petite offre, cette passe initiale peut prendre des jours. Ensuite, servir des fichiers est presque gratuit : le travail est de l'E/S, et le bavardage du protocole de synchronisation coûte plus en allers-retours qu'en cycles. Achetez des cœurs pour l'import, pas pour l'instance en fonctionnement courant, et si l'import est la seule raison qui vous pousserait à monter en gamme, faites-le sur une offre supérieure pendant un mois puis redescendez. La facturation mensuelle sans engagement est précisément ce qui rend cette manœuvre bon marché.

Cette dernière ligne mérite d'être lue deux fois, car c'est là que l'on se trompe le plus souvent sur le format de la machine. Un VPS excelle comme point central de synchronisation et de partage pour l'ensemble de travail que touche un groupe de personnes. C'est en revanche un mauvais contenant pour une archive multimédia : la plus grande offre que nous vendons plafonne à six cent quarante gigaoctets de NVMe local, et dès lors que votre bibliothèque se mesure en téraoctets, la bonne réponse est le matériel dédié, où une paire de disques en miroir vous donne un ou deux téraoctets avec de la redondance en dessous. Décider cela avant de commencer est bien moins douloureux que de déplacer une instance déjà remplie une fois que vous êtes à court de place.

La décision de base de données que l'on prend une fois pour toutes

L'installateur vous proposera SQLite, et cela fonctionnera. Utilisez-le pour une démonstration que vous comptez supprimer, et pour rien d'autre. SQLite sérialise les écritures sur l'ensemble de la base de données, et cette application écrit en permanence — chaque interrogation d'un client de synchronisation, chaque fichier scanné, chaque entrée d'activité — si bien que dès que deux clients sont actifs, les requêtes se mettent en file les unes derrière les autres et l'interface accuse un temps de latence qu'aucun réglage ne fait disparaître. Les prérequis officiels le disent, poliment.

MariaDB et PostgreSQL sont tous deux de premier ordre, et le choix entre les deux relève surtout de la préférence personnelle. MariaDB est ce que fait tourner la plupart des déploiements et ce que suppose la plupart des réponses communautaires, ce qui compte quand on cherche un message d'erreur à minuit ; il faut créer la base de données avec le jeu de caractères UTF-8 à quatre octets pour que les emoji dans les noms de fichiers ne tronquent pas une ligne, et il veut que son isolation transactionnelle soit réglée sur read-committed, ce que la documentation énonce clairement et que l'on saute pourtant. PostgreSQL est discrètement meilleur sous forte concurrence et se montre moins capricieux, au prix d'un bassin de réponses à copier-coller légèrement plus restreint. Les deux sont valables ; faire tourner celui que vous savez déjà sauvegarder est plus valable que l'un ou l'autre.

Installez-la sur la même machine et connectez-vous via un socket Unix. C'est l'un des rares cas où l'architecture évidente est aussi la bonne : une instance unique ne gagne rien à avoir sa base de données sur un autre hôte, et perd un aller-retour réseau sur chacune des nombreuses petites requêtes que l'application effectue. Liez la base de données à l'interface loopback, jamais à l'interface publique — la checklist de durcissement explique pourquoi une base de données en écoute est la manière la plus courante dont un petit serveur est arraché à son propriétaire.

Ce qu'il faut comprendre à propos de cette base de données, c'est qu'elle est modeste en octets et énorme en conséquences. Sa table centrale contient une ligne par fichier et par utilisateur — cent mille fichiers répartis sur quatre comptes représentent quelques centaines de milliers de lignes, ce qui n'est rien pour un moteur moderne, et quelques centaines de mégaoctets sur le disque. Mais cette table est la seule chose qui connaisse la structure de vos données. Perdez la base de données en gardant les fichiers, et vous vous retrouvez avec une arborescence sans partages, sans versions, sans commentaires, sans étiquettes et sans état de synchronisation. Le nouveau scan en ligne de commande reconstruira une arborescence utilisable à partir de cela — un vrai soulagement la première fois qu'on en a besoin — mais il ne ramènera pas un seul lien de partage ni le moindre historique de versions. Sauvegardez toujours les deux ensemble, et considérez la sauvegarde de l'un sans l'autre comme n'étant pas une sauvegarde du tout.

Pourquoi l'installation par défaut semble lente — et les quatre réglages qui corrigent cela

Une instance fraîchement installée est généralement qualifiée de poussive, et ceux qui le disent n'ont pas tort. Ce n'est ni le matériel ni PHP : ce sont quatre réglages par défaut choisis pour une compatibilité maximale sur de l'hébergement mutualisé plutôt que pour une machine que vous contrôlez. Les modifier prend vingt minutes et produit, à elle seule, la plus grande amélioration perçue que quiconque apportera jamais à cette installation.

Le premier concerne les tâches en arrière-plan. Par défaut, elles s'exécutent en mode AJAX, ce qui signifie que la file d'attente n'avance que lorsqu'un humain charge une page dans un navigateur — les aperçus ne sont donc pas générés, la corbeille n'expire pas, les partages fédérés ne sont pas rafraîchis et les index de recherche ne sont pas construits tant que quelqu'un ne passe pas par hasard. Passez à une entrée de cron système exécutant le gestionnaire de tâches toutes les cinq minutes en tant qu'utilisateur du serveur web, exactement comme le décrit la documentation sur les tâches en arrière-plan. La moitié des plaintes mystérieuses du type « Nextcloud ne fait rien » viennent de ce réglage.

Le second concerne le cache et le verrouillage des fichiers. Sans cache partagé, l'application relit en permanence la configuration et les métadonnées des applications, et sans verrouillage transactionnel des fichiers adossé à Redis, elle se rabat sur le verrouillage de lignes dans la base de données — exactement l'endroit où vous ne voulez pas de contention. Installez Redis, faites-le écouter sur un socket Unix plutôt que sur un port TCP pour que rien sur le réseau ne puisse l'atteindre, et dirigez vers lui à la fois le cache distribué et le moteur de verrouillage de fichiers, tout en laissant le cache local rapide sur APCu. La référence de configuration du cache donne le bloc exact.

Le troisième est le cache d'opcode de PHP. Les tailles de tampon par défaut ont été calibrées pour une petite application, et ce n'en est pas une — la page de vue d'ensemble de l'administration vous dira sans détour que le tampon des chaînes internées est presque plein, et un tampon plein signifie que l'interpréteur effectue, à chaque requête, un travail qui pourrait être évité. Augmenter la mémoire de l'opcache et le tampon des chaînes internées, et relever le nombre maximal de fichiers accélérés bien au-delà de la valeur par défaut, coûte quelques centaines de mégaoctets de RAM et se ressent immédiatement à chaque chargement de page. Le quatrième est le gestionnaire de processus de PHP-FPM : le nombre d'enfants par défaut est calibré pour une machine avec bien moins de mémoire que la vôtre, et un foyer avec plusieurs clients de synchronisation viendra faire la queue derrière lui. Dimensionnez le nombre de processus en fonction de votre RAM réelle et de l'empreinte par processus — le seul calcul de cette section qui mérite d'être posé sur le papier.

Un piège connexe mérite son propre paragraphe, car il produit un symptôme déroutant. Le téléversement d'un gros fichier via l'interface web échoue, alors que ce même fichier se téléverse sans problème depuis le client de bureau. Ce n'est pas un bogue : le client de bureau découpe les téléversements en morceaux et les réassemble côté serveur, ce qui lui permet de passer sous chaque limite, tandis que le navigateur envoie une seule grosse requête qui doit survivre aux limites de taille de téléversement et de POST de PHP, à la taille de corps maximale propre au serveur web, et à tout délai d'expiration entre les deux. Si le navigateur est le point d'entrée des gros fichiers dans votre instance, tous ces chiffres doivent être relevés ensemble — en relever un seul sans les autres ne fait que déplacer le composant qui dira non.

Trois choses différentes sont appelées chiffrement, et elles protègent contre trois personnes différentes

C'est la section où la plupart des déploiements auto-hébergés se trompent, et ils se trompent d'une manière compréhensible : trois fonctionnalités sans rapport entre elles partagent un même mot, l'interface d'administration les propose toutes, et en activer davantage semble plus sûr qu'en activer moins. Ce n'est pas le cas. Chacune se défend contre un adversaire précis, chacune a un coût, et l'une des trois est activement nuisible lorsqu'on l'applique au cas auquel on l'applique habituellement.

Le chiffrement intégral du disque est la couche sous-jacente à tout le reste. Il protège les données sur une machine éteinte — un disque retiré d'une baie, un lecteur mis au rebut, une image copiée depuis un stockage froid. Il ne fait absolument rien tant que le serveur tourne, parce que le volume est déverrouillé et que le système d'exploitation le lit comme des fichiers ordinaires. Il est bon marché, invisible, sans aucun effet sur une quelconque fonctionnalité de Nextcloud, et il n'y a aucune bonne raison de s'en passer. Ce qu'il exige, c'est un plan de déverrouillage à distance, car un serveur qui redémarre à quatre heures du matin reste hors service jusqu'à ce que quelqu'un tape une phrase de passe ; le guide sur le chiffrement intégral du disque couvre l'arrangement SSH dans l'initramfs qui rend cela supportable.

Le chiffrement côté serveur est celui auquel il faut réfléchir le plus. Il chiffre le contenu des fichiers avec des clés qui résident sur ce même serveur, gérées par cette même application, et sa véritable raison d'être est de protéger des données que vous placez sur un stockage appartenant à quelqu'un d'autre — un stockage objet, un montage externe loué, un backend tiers. Appliqué à un stockage primaire local sur une machine que vous contrôlez déjà, il ne vous protège que très peu, puisque quiconque peut lire les fichiers peut aussi lire les clés ; et il vous coûte environ un tiers de stockage supplémentaire, complique chaque scénario de récupération, et désactive les fonctionnalités qui ont besoin de lire le contenu des fichiers. La documentation sur le chiffrement est inhabituellement directe sur ce compromis. Si votre stockage est du NVMe local sur un serveur que vous louez seul, laissez-le désactivé et utilisez plutôt la couche disque.

Le chiffrement de bout en bout est la véritable protection, et c'est le seul des trois qui vous protège du serveur lui-même. Les fichiers d'un dossier en bout en bout sont chiffrés par le client avant de quitter l'appareil, et le serveur ne stocke qu'un texte chiffré qu'il ne peut pas ouvrir — exactement ce qu'il faut pour le petit sous-ensemble de contenu où contraindre l'hébergeur ne doit produire aucune donnée lisible. Le prix est sévère et non négociable : ces dossiers n'ont ni interface web, ni recherche côté serveur, ni vignettes, ni partage public, ni récupération possible si vous perdez le mnémonique qui les déverrouille. Ce n'est pas une limitation à contourner par un artifice technique, c'est la définition même de la garantie. Utilisez-le pour le dossier qui en a réellement besoin, et laissez la photothèque familiale en dehors, là où les aperçus fonctionnent et où la vie est agréable.

Les clients, et les parties que les autres utilisateurs touchent réellement

La réussite de ce projet se décide presque entièrement par des gens qui ne se connecteront jamais au serveur, et leur verdict se forme la première semaine autour de trois logiciels. Le client de bureau est celui qui compte le plus. Configurez-le en fichiers virtuels plutôt qu'en copie locale complète — les fichiers apparaissent dans le gestionnaire de fichiers, n'occupent aucun espace tant qu'ils ne sont pas ouverts, et se téléchargent à la demande — car c'est ce qui rend une bibliothèque de deux cents gigaoctets utilisable sur un portable au disque modeste, et c'est le comportement que les gens attendent déjà des clients commerciaux.

L'application mobile porte la fonctionnalité qui convainc les sceptiques : l'envoi automatique de la pellicule. Activez-la pour les membres de votre foyer, pointez-la vers un dossier par utilisateur, et en un mois, le débat sur l'abandon de Google Photos est clos. C'est aussi, et pour exactement la même raison, ce qui remplira votre disque selon un calendrier que vous n'avez pas choisi — d'où le fait que la section de dimensionnement ci-dessus passe son temps sur les photos plutôt que sur les documents. Fixez un quota par utilisateur dès le début — non pas parce que vous comptez le faire respecter, mais parce qu'un quota transforme un disque qui se remplit silencieusement en un message clair sur le téléphone de quelqu'un.

Les calendriers et les contacts sont la victoire discrète, et ce qui reste le plus souvent à moitié configuré. Nextcloud parle CalDAV et CardDAV, que tout téléphone et tout ordinateur prend en charge nativement, si bien que personne n'a besoin d'une nouvelle application — mais la découverte repose sur une paire de redirections à /.well-known/caldav et /.well-known/carddav, qui vivent dans la configuration de votre serveur web plutôt que dans l'application. Faites-les mal et la configuration du compte échoue avec une erreur peu explicite sur iOS, tout en fonctionnant sans problème sur Android. La page de vue d'ensemble de l'administration le signale explicitement, ce qui est une raison de plus pour vider cette liste avant que quiconque d'autre n'arrive.

Deux notes plus modestes font gagner un vrai temps. Le montage WebDAV est pris en charge et se révèle vraiment pratique pour un accès occasionnel depuis une machine sur laquelle vous ne voulez rien installer ; il est aussi lent, car chaque opération est un aller-retour HTTP, ce qui en fait un mauvais choix comme répertoire de travail, mais un bon choix pour récupérer un fichier. Et créez un mot de passe d'application pour chaque appareil plutôt que de distribuer le mot de passe du compte : révoquer un téléphone perdu revient alors à supprimer un seul jeton plutôt qu'à changer un mot de passe et à réauthentifier tous les autres clients que vous possédez. Associez cela à une authentification à deux facteurs sur les comptes, et gardez un compte administrateur que personne n'utilise au quotidien séparé du compte avec lequel vous synchronisez réellement.

Là où la juridiction cesse d'être une abstraction

Pour la plupart des choses que vous pourriez auto-héberger, l'emplacement de la machine est une décision de latence assortie d'une note de bas de page juridique. Pour l'ensemble de vos archives documentaires, vos photographies, vos contacts et votre calendrier, la priorité s'inverse — c'est la seule machine où la question juridique l'emporte sur la question réseau, parce que les données qu'elle contient sont précisément le genre de données pour lesquelles des réquisitions judiciaires sont réellement émises.

Comprenez ce qui change lorsque vous quittez un hyperscaler. Quand vos fichiers vivent chez un grand fournisseur, une demande les concernant est signifiée à ce fournisseur, évaluée par son service juridique au regard de ses propres intérêts, et honorée sous une ordonnance de non-divulgation plus souvent qu'autrement — vous pourriez ne jamais savoir que cela s'est produit. Quand les fichiers vivent sur un serveur que vous louez, il n'existe ni ce service ni ce réflexe, et la demande doit trouver quelqu'un. Ce n'est pas un bouclier magique ; c'est un changement structurel dans qui est sollicité, à quel point cette sollicitation est visible, et combien de friction sépare une demande d'une copie de vos données. Notre explicatif juridique détaille ce qu'est et n'est pas cette friction.

Deux conséquences pratiques en découlent. La première est que la juridiction doit être choisie délibérément plutôt que par réflexe de latence — le comparatif des juridictions et la note sur le dispositif des 14 Eyes détaillent en quoi les quatre emplacements diffèrent, et pour une archive personnelle, la réponse est généralement le socle juridique le plus solide dont vous pouvez tolérer le temps d'aller-retour. La seconde est que l'hébergeur ne peut jamais être contraint de produire que ce qu'il peut atteindre, ce qui explique pourquoi les couches de chiffrement ci-dessus ne sont pas de la décoration : le chiffrement intégral du disque associé au chiffrement de bout en bout sur les dossiers qui en ont besoin fait que la réponse honnête à une demande est une image disque de texte chiffré.

Il y a un compromis de latence, et il est plus faible qu'on ne le craint. La synchronisation est un processus en arrière-plan — personne ne regarde un envoi de photo se faire — de sorte que cent millisecondes d'aller-retour supplémentaires ne coûtent rien de perceptible sur ce que vous faites toute la journée. Là où cela se voit, c'est en ouvrant un document dans l'éditeur web ou en faisant défiler une grande galerie, ce qui est interactif et où ces mêmes cent millisecondes se font sentir à chaque action. Si les humains sont en Europe, Amsterdam ou Zürich garde les deux expériences rapides ; si la posture juridique est tout l'enjeu, Reykjavík vous coûte une quantité notable mais tolérable de réactivité interactive, et rien du tout côté synchronisation.

Une obligation mérite d'être énoncée clairement, car l'auto-hébergement vous la transfère discrètement. Dès l'instant où les fichiers d'autres personnes se trouvent sur votre serveur — les photographies d'un membre de la famille, les documents d'un collègue, les contrats d'un client — vous devenez la partie responsable de ces données, et en Europe, cette responsabilité porte un nom et s'accompagne d'un ensemble d'obligations. Ce n'est pas lourd à l'échelle d'un foyer, et ce n'est pas quelque chose à découvrir en pleine dispute : décidez qui a accès à quoi, dites aux personnes concernées où vivent leurs données, et gardez le compte administrateur hors de l'usage quotidien, de sorte que lire le dossier de quelqu'un d'autre soit un acte délibéré plutôt qu'un accident.

Les sauvegardes, et la restauration qu'il faut répéter

Il y a exactement trois choses à préserver, et toutes trois doivent provenir du même instant : le répertoire de données qui contient le contenu des fichiers, la base de données qui contient chaque élément de métadonnées à leur sujet, et config.php, qui contient l'identifiant de l'instance, les identifiants de connexion à la base de données et — si vous avez activé le chiffrement côté serveur — les valeurs sans lesquelles le reste est illisible. Copiez-en deux sur trois, et vous obtenez un exercice archéologique intéressant plutôt qu'une restauration.

La cohérence est la partie qu'il est facile de rater subtilement. Un fichier copié pendant que la base de données est en cours d'écriture produit une sauvegarde dont les deux moitiés ne concordent pas, et cette discordance refait surface des semaines plus tard sous forme de fichiers qui existent sur le disque mais pas dans l'interface, ou d'entrées dans l'interface qui ne pointent vers rien. La solution simple consiste à passer l'instance en mode maintenance, exporter la base de données, capturer le répertoire de données, puis désactiver le mode maintenance — une courte coupure que personne ne remarque à quatre heures du matin. La documentation sur les sauvegardes détaille la séquence, et un instantané du système de fichiers pris pendant que l'application est mise en pause obtient le même résultat en moins de temps, si votre stockage en propose un.

Envoyez-la ensuite ailleurs, chiffrée avant même de quitter la machine. Restic et Borg chiffrent tous deux côté client et dédupliquent bien un jeu de données qui change sur ses marges, ce qui est la nature d'un serveur de fichiers. Rendez le dépôt distant append-only, de sorte qu'un hôte compromis ne puisse pas supprimer son propre historique — c'est ce qui transforme une sauvegarde en défense contre un rançongiciel plutôt qu'en simple parade à un disque défaillant — et placez l'extrémité distante dans une juridiction différente de l'extrémité locale, puisqu'une copie qui peut être saisie dans la même action que l'original n'est pas vraiment une seconde copie. Conservez la phrase de passe du dépôt quelque part qui n'est pas le serveur.

Les deux fonctionnalités que l'on confond avec des sauvegardes méritent d'être nommées. Les versions de fichiers et la corbeille sont des commodités qui vivent à l'intérieur de la même instance, sur le même disque, dans la même base de données ; elles réparent à merveille un écrasement accidentel et ne survivent absolument à rien de ce qui peut arriver au serveur. De même, les instantanés horaires de l'hébergeur — que chaque offre proposée ici inclut avec une rétention de sept jours — sont excellents pour annuler une mauvaise mise à niveau, mais ne constituent pas une sauvegarde hors site, car ils partagent le sort de l'infrastructure sur laquelle ils reposent. Utilisez les trois. Fiez-vous à celle qui se trouve ailleurs.

Enfin, répétez la restauration, une fois, pendant que tout va bien. Provisionnez un serveur jetable, restaurez-y la base de données et le répertoire de données, corrigez l'entrée de domaine de confiance dans config.php, et connectez-vous. Vous découvrirez quelque chose — un module PHP manquant, un utilisateur de base de données que vous n'avez jamais noté quelque part, une clé de chiffrement qui vivait à un endroit que vous avez oublié — et vous le découvrirez un après-midi où cela vous coûte une heure, plutôt que le jour où cela vous coûte l'archive entière. Si la restauration nécessite aussi un nouveau scan des fichiers pour réconcilier l'arborescence, c'est à cela que sert l'outil en ligne de commande, et le savoir à l'avance est tout l'intérêt de l'exercice.

Partager vers l'extérieur sans exposer l'intérieur

La fonctionnalité qui rend ce système vraiment utile pour d'autres personnes est aussi celle qui place une URL vers vos fichiers sur l'internet public, ce qui justifie cinq minutes de configuration délibérée plutôt que de s'en tenir aux réglages par défaut. Les liens publics devraient porter un mot de passe et une expiration par principe, plutôt que comme une décision au cas par cas — les deux peuvent être imposés à l'échelle de l'instance, ce qui signifie que le réglage est fait une fois par vous, plutôt qu'oublié à chaque fois par quelqu'un d'autre. Les dossiers de dépôt en envoi seul sont le cas sous-estimé : un lien qui accepte des fichiers sans révéler ce qui se trouve déjà dans le dossier remplace tous les pénibles échanges de pièces jointes par e-mail que vous avez actuellement.

Derrière un proxy inverse — ce qui est la façon dont presque tout le monde fait tourner ceci — une seule valeur de configuration cause une quantité disproportionnée de confusion. Si l'application n'est pas informée de quelles adresses faire confiance en tant que proxys, chaque requête semble provenir du proxy lui-même. La limitation de débit compte alors le monde entier comme un seul visiteur, la protection contre la force brute finit par limiter cette unique adresse, et le résultat est une instance qui ralentit mystérieusement ou verrouille des utilisateurs légitimes, tandis que les journaux montrent une seule IP en train de tout faire. Configurer la liste des proxys de confiance et la substitution de protocole, comme le décrit la documentation sur le proxy inverse, corrige les journaux et la protection en une ligne chacun.

La liste des domaines de confiance est l'autre valeur qui mérite d'être comprise plutôt que simplement copiée. C'est une liste blanche des noms d'hôtes sur lesquels l'instance répondra, et elle existe parce que l'application construit des URL absolues — liens de réinitialisation de mot de passe, liens de partage, rappels de fédération — à partir de l'en-tête Host qu'elle reçoit. Laissée ouverte, c'est une façon bien connue de faire pointer vos propres liens ailleurs. Ajoutez les noms d'hôtes que vous utilisez réellement, y compris l'adresse onion si vous en publiez une, et rien d'autre.

Si une partie de tout cela ne devrait pas du tout être accessible depuis l'internet ouvert, ne réglez pas cela avec une règle de pare-feu et un espoir. Deux réponses propres existent : placer l'instance derrière un tunnel WireGuard pour qu'elle ne soit accessible que depuis des appareils détenant une clé, ce qui fonctionne bien pour une archive personnelle et mal pour un partage avec des tiers ; ou la publier comme service onion aux côtés du nom d'hôte clearnet, ce qui permet aux clients de synchronisation de continuer à fonctionner via Tor sans exposer d'adresse du tout. Les deux se cumulent — vous pouvez faire tourner l'un ou l'autre aux côtés d'un nom d'hôte public normal et laisser le contenu sensible vivre derrière le chemin privé.

Quand vous ne devriez pas auto-héberger cela

Un guide qui ne dit jamais cela est en train de vendre quelque chose, alors voici la liste. Si les données appartiennent à une entreprise dont les opérations s'arrêtent en même temps que le serveur de fichiers, vous garantissez une disponibilité avec une seule machine et l'attention d'une seule personne, et un VPS unique n'est pas le bon instrument pour cela. La haute disponibilité pour cette application est véritablement complexe — stockage partagé, base de données répliquée, répartiteur de charge qui comprend les sessions persistantes — et si vous en avez besoin, il vous faut un budget et une seconde personne, pas une offre plus grande.

Si personne ne va faire la maintenance mensuelle, ne commencez pas. Le travail est mince — appliquer les mises à jour, jeter un œil à la page de vue d'ensemble de l'administration, confirmer que la sauvegarde s'est bien déroulée, monter d'une version majeure à la fois quand une nouvelle sort — mais il ne pardonne pas d'être laissé de côté pendant un an. Une instance en retard de plusieurs versions majeures ne peut pas être mise à niveau en une seule étape et ne devrait pas, entre-temps, être exposée à Internet ; et s'extraire de cette position demande plus de travail que n'en aurait demandé la maintenance.

Si votre bibliothèque se mesure en téraoctets et continue de croître, c'est le format qui pose problème, pas la taille. Aucune offre VPS que nous vendons n'atteint un téraoctet de NVMe local, et greffer du stockage objet à l'arrière de l'instance déplace le problème au lieu de le résoudre : la base de données devient encore plus critique, la latence sur chaque opération de fichier augmente, et vous avez discrètement réintroduit un tiers dans une conception dont tout le but était d'en supprimer un. Achetez du matériel dédié avec des disques en miroir, ou acceptez que l'archive et le point central de synchronisation soient deux systèmes différents.

Et si ce que vous voulez réellement, c'est Google Docs — trente personnes qui tapent dans la même feuille de calcul avec des curseurs à la latence inférieure à la seconde — soyez honnête : la suite bureautique auto-hébergée est bonne, mais pas équivalente, et elle veut sa propre mémoire et son propre CPU. Faites-la tourner parce que vous voulez les documents sur votre propre disque, pas parce que vous vous attendez à ce que la collaboration soit identique.

Pour tous les autres — un foyer fatigué de payer un loyer sur ses propres photographies, une petite équipe qui préférerait ne pas voir ses contrats indexés par une entreprise dotée d'un service conformité, un particulier qui veut simplement que ses fichiers se trouvent à l'endroit qu'il a choisi — c'est l'une des choses les plus gratifiantes que l'on puisse installer sur un serveur. Le logiciel est mature, les clients sont bons, les modes de défaillance sont documentés, et le seul qui soit vraiment impitoyable est la sauvegarde qui n'a jamais été testée. Un serveur prend environ une minute à provisionner, les aperçus seront encore en train de se générer pendant que vous finissez de configurer les téléphones, et vous pouvez le payer avec la même posture de confidentialité que celle pour laquelle vous l'achetez.