Self-host sans backup, c'est juste de l'illusion
Installer Nextcloud sur son VPS ne libère pas des GAFAM. Sans stratégie de backup, ça remplace une dépendance par une responsabilité que la plupart ne tiennent pas.
Tu as un Nextcloud qui tourne sur ton VPS. Tes photos, tes fichiers, ton calendrier, tes contacts. Tout est chez toi. Tu te sens libre.
Tu te sens libre jusqu'au jour où le disque du VPS lâche, où tu tapes une mauvaise commande, ou où ton hébergeur a un incident sur ta zone. À ce moment-là tu réalises que tu n'avais pas un cloud souverain. Tu avais un single point of failure avec un mot d'ordre marketing dessus.
Le self-host sans stratégie de backup, ce n'est pas se libérer des GAFAM. C'est juste signer un nouveau contrat de dépendance, sauf que cette fois la cause c'est toi.
Le piège
Quand on installe Nextcloud sur son propre serveur, on coche mentalement la case "données contrôlées". C'est faux. La seule chose dont on est protégé, c'est le tracking commercial. Le risque opérationnel, lui, est devenu personnel et plus dangereux.
Sur Google Drive, si ton disque externe local crame, tes photos restent. Sur ton Nextcloud self-hosted, si ton VPS pète, tes photos sont mortes. Tu as échangé une dépendance contre une responsabilité, et la plupart des gens qui font ce switch ne le réalisent pas avant l'incident.
Ce que je viens de mettre en place
Ce soir j'ai fini la chaîne de backup pour mon instance Nextcloud. Trois niveaux.
1. Borg côté VPS, daily à 3h du matin. Géré par AIO, le wizard officiel Nextcloud. Repo chiffré, déduppé, snapshot quotidien complet. C'est rapide parce que borg ne sauvegarde que les chunks qui ont changé. Mais ça reste sur le VPS, donc si le VPS meurt c'est mort aussi.
2. Pull rsync sur mon PC local, daily. Le repo borg du VPS est aspiré vers un dossier sur ma machine. Si le VPS disparaît demain, j'ai tout en local. Le pull est incrémental donc 8 Go la première fois, puis quelques Mo par jour. Le script vérifie en plus que le borg AIO a bien tourné dans les 48 heures. Si le côté VPS est cassé, je suis prévenu avant que mon backup local devienne obsolète.
3. Mirror manuel sur disque externe. Quand je branche mon disque externe, je copie le repo borg dessus. Trois copies, trois lieux. C'est la règle 3-2-1 du backup en version perso, low-cost.
Ce qui m'a appris à faire ça
Pas la théorie. Une fois j'ai perdu un projet client à 80% terminé parce que je faisais "des git push" en pensant que ça suffisait comme backup. Ça suffit jusqu'à ce que ton repo héberge le mauvais état et que ton local n'ait plus rien à pousser pour réparer.
Depuis ce jour-là j'ai un principe simple. Si une donnée n'existe que dans un endroit, elle n'existe pas. Et "un endroit" inclut "deux disques sur la même machine", "deux conteneurs sur le même VPS", "deux régions du même cloud provider".
Le vrai self-host
Le vrai self-host ne consiste pas à installer un service alternatif. Ça consiste à porter la responsabilité de bout en bout. Hébergement, mises à jour, sécurité, et surtout backup. Si tu fais que la première étape, tu fais du self-host esthétique. Tu te donnes l'impression de la souveraineté sans en payer le coût opérationnel.
La bonne nouvelle, c'est que la deuxième étape est faisable en un week-end. Borg, rsync, un script bash, un cron. Pas besoin d'une solution enterprise à 200 euros par mois. T'as besoin de t'asseoir une fois, de poser la chaîne, et de tester un restore.
Le test de restore, c'est l'étape que tout le monde saute. C'est aussi celle qui distingue un backup réel d'un dossier de chunks chiffrés qui va te donner une fausse sécurité pendant deux ans, avant le jour où tu en auras vraiment besoin.
TL;DR
Si tu self-host sans backup automatique avec test de restore régulier, tu n'es pas plus libre qu'avant. T'es juste plus exposé.