Ta bibliothèque de photos est probablement synchronisée sur Google Photos, sans autre copie. En cas de perte de compte, piratage ou suspension, cette bibliothèque disparaît. Voici comment en récupérer une copie indépendante grâce à Google Takeout, jusqu’à un disque local.
Pourquoi Google Takeout, et pas rclone directement
Depuis fin mars 2025, l’API que rclone utilise pour Google Photos a été restreinte par Google : rclone ne peut plus télécharger que les photos qu’il a lui-même envoyées, pas l’ensemble d’une bibliothèque déjà existante. rclone n’est donc plus une option pour extraire directement tes photos. Google Takeout reste la méthode recommandée pour un export complet, avec les métadonnées d’origine.
Étape 1 : créer l’export avec Google Takeout
Dans les paramètres de ton compte Google Photos, va dans Exporter vos données > Sauvegarder
Crée une exportation, choisis ce que tu veux sauvegarder (l’ensemble de ta bibliothèque par exemple)
Vérifie la destination : par défaut, Google Takeout propose d’envoyer un lien de téléchargement par e-mail. Remplace cette destination par Envoyer à Drive. Il y a d’autres options, pas pertinentes pour moi : Dropbox, OneDrive, Box). Nextcloud n’est pas proposé.
Choisis « Exporter une fois », format .zip, taille de fichier 2 Go
Clique sur « Créer une exportation »
Attends l’e-mail de fin de traitement, le délai peut aller jusqu’à plusieurs heures selon le volume de ta bibliothèque
Étape 2 : récupérer l’export dans un dossier Google Drive dédié
L’export atterrit dans un dossier Takeout créé automatiquement par Google, mélangé au reste de ton Drive. Mieux vaut le déplacer dans un dossier dédié avant de passer à la suite :
Ouvre Google Drive, dossier Takeout. Il est à la racine de « Mon Drive »
Déplace ce dossier Takeout là où ça te semble pertinent
Étape 3 : synchroniser ce dossier avec un disque local
Google Photos et Google Drive sont deux services Google distincts : un problème sur l’un (compte Photos suspendu, par exemple) n’affecte pas nécessairement l’autre. Mais pour être vraiment protégé, il faut une copie qui sorte de l’écosystème Google, sur un support que tu maîtrises entièrement.
La méthode la plus simple : installer le client de synchronisation Google Drive sur ton PC (Windows ou macOS), et le laisser synchroniser ce dossier dédié vers un dossier local sur ton disque dur. Une fois la synchronisation terminée, tu disposes d’une copie physique de tes photos sur ta machine, indépendante de toute connexion internet ou de la disponibilité de Google Photos.
Ce qui reste à faire
Cette copie locale reste, pour l’instant, sur le même PC que celui utilisé au quotidien pour accéder à Google Drive. Une indépendance complète de l’écosystème Google viendra d’une copie supplémentaire sur un support totalement déconnecté : disque dur externe débranché en dehors des sauvegardes, ou gravure sur DVD pour un archivage à très long terme. Cette étape suivante n’est pas encore réalisée à l’heure où j’écris cet article, elle fera l’objet d’un complément le moment venu.
Conclusion
En cas de problème sur Google Photos, tant que Google Drive reste accessible, la bibliothèque de photos existe encore, à cet endroit précis. Et depuis l’étape de synchronisation locale, elle existe aussi sur le disque dur du PC, sans dépendre de la disponibilité d’aucun service Google. C’est un exemple concret du principe décrit dans Les limites cachées des solutions cloud : le cloud seul ne suffit jamais, une copie locale reste le seul vrai filet de sécurité.
Le cloud donne une impression de capacité illimitée, où il suffirait de lancer une commande pour que tout se transfère sans effort. La réalité est bien différente. Aucune solution n’est parfaite. Voici trois limites rencontrées sur trois services différents (Dropbox, Google Drive, Nextcloud), et la conclusion qui en découle : ne jamais dépendre uniquement du cloud pour tes données importantes.
Cet article fait partie de la série Projets Ubuntu, consacrée à mon Mini PC sous Ubuntu et son infrastructure Docker.
Dropbox : une API très sensible à la concurrence
En migrant plusieurs dizaines de milliers de fichiers Dropbox vers Google Drive avec rclone, le débit s’est effondré à quelques centaines de kilo-octets par seconde, alors que la connexion utilisée tenait sans problème plusieurs centaines de mégabits. La cause : l’API Dropbox tolère très mal un grand nombre de requêtes simultanées sur de nombreux petits fichiers, contrairement à Google Drive qui encaisse ce type de charge sans broncher. La solution qui a fonctionné : synchroniser d’abord Dropbox sur un disque local avec le client de bureau habituel, puis transférer ce disque vers Google Drive avec rclone, sans jamais repasser par l’API Dropbox pour ce volume de fichiers.
Google Drive : un quota de requêtes partagé par défaut
Sans configuration particulière, rclone se connecte à Google Drive avec un identifiant d’application qui lui est propre, partagé par tous les utilisateurs de rclone dans le monde qui n’ont pas configuré leurs propres identifiants. Le quota de requêtes par minute de cet identifiant partagé peut donc être atteint à cause de l’usage d’autres personnes, totalement indépendamment du volume que tu transfères toi-même. Ça se traduit par une erreur de ce type, sans rapport apparent avec ce que tu es en train de faire :
RATE_LIMIT_EXCEEDED
La solution : créer son propre projet Google Cloud, avec ses propres identifiants OAuth, pour disposer d’un quota qui n’appartient qu’à toi et non plus partagé avec le reste du monde. La démarche complète (création du projet, activation de l’API, génération des identifiants, reconfiguration de rclone) fait l’objet d’un article dédié, à paraître.
Nextcloud : une limite structurelle sur les gros fichiers via WebDAV
Cette troisième limite est la plus difficile à diagnostiquer, parce qu’elle ne vient ni d’un quota, ni d’une mauvaise configuration, mais d’un bug connu et documenté du protocole utilisé.
Le contexte : transférer un export Google Photos (Google Takeout) depuis Google Drive vers un espace Nextcloud, avec des fichiers ZIP d’environ 2 Go chacun. Commande de départ :
Le fichier temporaire créé par Nextcloud pendant l’envoi (.upload.part) reste verrouillé, rclone considère alors le transfert comme échoué et redémarre l’envoi du fichier entier depuis zéro. Résultat : plus d’une heure passée à recommencer plusieurs fois le même fichier de 2 Go, sans jamais aboutir.
Deux pistes ont été testées avant de trouver la vraie cause :
Mettre à jour rclone vers une version récente, pour bénéficier du découpage automatique des gros fichiers en petits blocs (chunking) lors de l’envoi vers Nextcloud, une fonctionnalité absente des versions plus anciennes
Ajuster la taille de ces blocs avec l’option --webdav-nextcloud-chunk-size, en restant sous la limite d’upload fixée par l’hébergeur (visible dans les paramètres PHP, « Taille maximum d’un fichier pour l’envoi »)
Aucune des deux n’a résolu le problème de fond : même avec une version récente et des blocs correctement dimensionnés, le même verrou 423 Locked est réapparu lors de l’assemblage final des blocs côté serveur. En creusant du côté des tickets techniques du projet rclone, la cause est confirmée par les développeurs eux-mêmes : il n’existe aucun moyen fiable de vérifier si cet assemblage, effectué côté serveur Nextcloud, est encore en cours ou a échoué. Si l’assemblage prend un peu de temps, ce qui est normal pour un gros fichier, rclone peut l’interpréter comme un échec et relancer tout l’envoi. C’est un problème ouvert depuis plusieurs années, qui touche spécifiquement les gros fichiers envoyés à un serveur Nextcloud via le protocole WebDAV.
Autrement dit : ni une mauvaise configuration, ni une version obsolète, mais une limite structurelle qui touche cette combinaison précise d’outil et de protocole, pour ce type de fichier volumineux. La règle qui en découle : garder les fichiers sous 500 Mo à 1 Go pour un envoi vers Nextcloud, avec --transfers 1, et désactiver le découpage en blocs quand le fichier tient dans la limite d’upload de l’hébergeur. Pour les fichiers plus gros, comme un export Google Takeout, une autre méthode est nécessaire, elle fait l’objet d’un article dédié.
La conclusion commune : le cloud ne remplace jamais une sauvegarde locale
Ces trois limites n’ont techniquement rien en commun : une API sensible à la charge, un quota partagé par défaut, un bug de verrouillage sur un protocole de transfert. Mais elles partagent le même enseignement : aucune automatisation cloud à cloud n’est garantie de bout en bout. Un transfert peut caler à mi-chemin, pour une raison qui n’a parfois rien à voir avec la taille des données ou la qualité de la connexion.
C’est pour ça qu’une copie locale, sur un disque que tu maîtrises entièrement, reste indispensable en complément de toute sauvegarde cloud. Pas comme solution de confort, mais comme filet de sécurité pour le jour où un transfert automatisé n’ira pas au bout, ou pour le jour où il faudra tout simplement sortir d’un service cloud, avec ou sans sa coopération.
Tu synchronises déjà tes fichiers en temps réel entre plusieurs appareils, mais une synchronisation n’est pas une sauvegarde : une erreur ou une suppression accidentelle se propage aussi vite que le reste. Voici comment mettre en place une sauvegarde périodique automatisée d’un service cloud vers un autre, avec un script simple et fiable.
y, puis saisis le mot de passe Nextcloud (il sera masqué et stocké de façon obscurcie dans rclone.conf, pas en clair)
bearer_token>
Laisse vide, valide
Edit advanced config?
n
Keep this remote?
y
q) Quit config
q
Pour vérifier que c’est ok :
rclone lsd nextcloud:OBSIDIAN-sync
Tu dois voir le contenu de ton dossier OBSIDIAN-sync dans Nextcloud.
Étape 2 : configurer un remote vers la destination, limité à un dossier particulier
Par prudence, plutôt que de donner à rclone un accès à l’intégralité de ton espace de stockage de destination, il est possible de limiter un remote à un seul dossier, appelons le « folder », grâce à son identifiant unique.
Récupérer l’identifiant du dossier
Ouvre le dossier cible dans Google Drive, depuis un navigateur
Copie la chaîne de caractères qui suit folders/ dans l’URL, par exemple :
Choisis de créer un nouveau remote « gdrive-scope », sélectionne drive comme type de stockage, laisse les champs client_id et client_secret vides (valeurs par défaut), puis, à l’étape des réglages avancés (réponds y à la question Edit advanced config?), renseigne le champ root_folder_id avec l’identifiant récupéré à l’étape précédente.
Autoriser l’accès sans navigateur local (connexion SSH)
Si tu configures ce remote depuis une session SSH sans interface graphique, l’assistant propose une autorisation manuelle : il faut alors lancer rclone authorize "drive" sur une machine disposant d’un navigateur, se connecter avec le compte Google concerné, puis copier le jeton généré dans le terminal SSH en attente.
Vérifier l’accès
bash
rclone lsd gdrive-scope:
Cette commande devrait lister directement le contenu du dossier ciblé, sans que tu aies besoin de préciser de chemin.
Étape 3 : le script de sauvegarde
Le script copie le contenu source dans un dossier temporaire, le compresse en une seule archive, puis envoie cette archive vers la destination. Il prend en paramètre le nom du sous-dossier à sauvegarder, ce qui permet de le réutiliser pour plusieurs contenus différents avec une seule et même logique. En cas de besoin, l’archive se décompresse normalement pour retrouver les fichiers d’origine.
Attention, il faudra que tu modifies SOURCE_REMOTE (nextcloud:chemin-source/) et DEST_REMOTE (gdrive-scope:destination/) et tu remplaces USER par ton nom d’utilisateur dans le mini PC
#!/bin/bash
# Sauvegarde d'un dossier source (cloud A) vers un dossier destination (cloud B)
# Usage : backup-cloud-to-cloud.sh <nom-du-dossier>
# Exemple : backup-cloud-to-cloud.sh mon-dossier
set -e
FOLDER_NAME="$1"
if [ -z "$FOLDER_NAME" ]; then
echo "Erreur : nom du dossier manquant. Usage : backup-cloud-to-cloud.sh <nom-du-dossier>"
exit 1
fi
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
TMP_BASE="/home/USER/tmp/cloud-backup"
TMP_DIR="${TMP_BASE}/${FOLDER_NAME}"
ARCHIVE_NAME="${FOLDER_NAME}_${TIMESTAMP}.tar.gz"
ARCHIVE_PATH="${TMP_BASE}/${ARCHIVE_NAME}"
SOURCE_REMOTE="nextcloud:chemin-source/${FOLDER_NAME}"
DEST_REMOTE="gdrive-scope:destination/${FOLDER_NAME}/"
echo "=== Sauvegarde ${FOLDER_NAME} - $(date) ==="
# Nettoyage préalable au cas où une exécution précédente aurait échoué
rm -rf "$TMP_DIR"
mkdir -p "$TMP_DIR"
# Copie depuis le cloud source vers un dossier temporaire local
echo "Copie depuis la source..."
rclone copy "$SOURCE_REMOTE" "$TMP_DIR" --transfers 4 --checkers 8 --fast-list
# Compression en une seule archive
echo "Compression..."
tar -czf "$ARCHIVE_PATH" -C "$TMP_BASE" "$FOLDER_NAME"
# Upload de l'archive unique vers la destination
echo "Upload vers la destination..."
rclone copy "$ARCHIVE_PATH" "$DEST_REMOTE" --transfers 1
# Nettoyage
rm -rf "$TMP_DIR"
rm -f "$ARCHIVE_PATH"
echo "=== Terminé - $(date) ==="
Si ce script tourne sur une machine où tu utilises sudo pour d’autres tâches, ne l’utilise jamais avec rclone. La commande sudo rclone réécrit le fichier de configuration rclone.conf avec les droits root lors du renouvellement d’un jeton d’accès, ce qui casse ensuite l’utilisation normale de rclone en tant qu’utilisateur courant. Seule une éventuelle commande tar nécessitant des droits élevés (rare dans ce cas précis, puisque le script travaille dans le dossier personnel de l’utilisateur) justifierait sudo, jamais rclone lui-même.
Étape 4 : planifier avec cron
Pour une sauvegarde hebdomadaire, chaque dimanche à 4h du matin :
La fréquence gagne à être adaptée à la criticité du contenu : un document en cours d’écriture active justifie un rythme hebdomadaire, un dossier de veille alimenté plus occasionnellement peut se contenter d’un rythme mensuel.
Assure-toi que le dossier de logs existe avant la première exécution planifiée :
bash
mkdir -p /home/USER/scripts/logs
Étape 5 : tester avant de laisser cron s’en charger
Un test manuel permet de vérifier le bon fonctionnement avant de dépendre entièrement de la planification automatique :
Vérifie ensuite, dans l’interface web du service de destination, que l’archive est bien apparue au bon endroit, avec un nom cohérent incluant l’horodatage.
Ce que ce schéma permet au-delà de ce cas précis
Ce principe (remote limité à un dossier, compression en une seule archive, upload unique, planification cron) se réutilise pour n’importe quelle paire de services cloud supportés par rclone, pas seulement Nextcloud vers Google Drive. C’est un schéma générique de sauvegarde périodique, applicable à d’autres contenus que des notes ou des documents.
Pour aller plus loin
Si ce projet t’intéresse, deux articles complémentaires détaillent la suite :
La sauvegarde automatique mise en place dans l’article précédent ne vaut que si on sait s’en servir le jour où on en a besoin. Cet article décrit la procédure complète de restauration d’un container Docker depuis une sauvegarde Google Drive – testée sur Stirling PDF, Nginx Proxy Manager et Portainer.
Avant de commencer : vérifie que tu as bien une sauvegarde récente dans Google Drive. La commande suivante liste les dates disponibles :
Note la date de la sauvegarde que tu veux restaurer – tu en auras besoin à l’étape 4.
Vue d’ensemble de la procédure
Noter l’état actuel du container (point de comparaison)
Arrêter et supprimer le container
Renommer le dossier local (précaution de sécurité)
Restaurer les fichiers depuis Google Drive
Relancer le container
Vérifier que tout fonctionne
Nota : dans tout ce qui suit, tu remplaceras USER par ton nom d’utilisateur linux.
Procédure standard (Stirling PDF et containers similaires)
Étape 1 – Noter l’état actuel
Avant de toucher quoi que ce soit, note les éléments qui te permettront de vérifier que la restauration a bien fonctionné :
les réglages personnalisés du logiciel (utilisateurs, mots de passe, configuration)
les favoris, l’historique, tout ce qui est propre à ton usage
Vérifie l’empreinte des fichiers locaux actuels :
ls -la /home/USER/docker/nom-du-logiciel/
pour chaque sous-dossier :
ls -la /home/USER/docker/nom-du-logiciel/sous-dossier/
Vérifie aussi, pour chaque sous-dossier également, que la sauvegarde Drive contient bien les fichiers critiques et que leurs tailles correspondent :
sudo rclone --config /home/USER/.config/rclone/rclone.conf ls "gdrive:/daily/YYYY-MM-DD/nom-du-logiciel/sous-dossier/"
Les tailles en octets doivent correspondre à celles des fichiers locaux. Ce qui importe c’est que les fichiers principaux (base de données, configuration) soient de taille identique – pas besoin de vérifier les logs. Si c’est le cas, tu peux continuer en confiance.
Étape 2 – Arrêter et supprimer le container dans Portainer
Si tu restaure Portainer, va voir le cas particulier plus bas.
Depuis ton navigateur, ouvre Portainer :
Va dans Stacks dans le menu de gauche
Clique sur la stack du logiciel à restaurer
Clique sur Stop puis sur Delete this stack
Confirme la suppression
Le logiciel n’est plus accessible. C’est normal, on va le reconstruire depuis la sauvegarde.
Étape 3 – Renommer le dossier local (précaution)
Plutôt que de supprimer définitivement le dossier local, on le renomme. Si quelque chose se passe mal pendant la restauration, on peut revenir en arrière immédiatement.
NPM contient des données critiques : tes certificats Let’s Encrypt et ta configuration de proxy. La procédure standard s’applique, avec deux différences importantes.
Différence 1 – commande de restauration
Les certificats Let’s Encrypt dans letsencrypt/live/ sont des liens symboliques (symlinks) qui pointent vers les vrais fichiers dans letsencrypt/archive/. Sans l’option --copy-links, rclone refuse de les copier et la restauration échoue au démarrage avec l’erreur cannot load certificate.
La commande de restauration doit donc inclure --copy-links :
que tes proxy hosts sont bien présents dans l’interface NPM
que le cadenas vert s’affiche sur pdf.DOMAINE.com (certificat SSL actif)
Si les certificats ont expiré pendant une longue interruption, NPM les renouvellera automatiquement au redémarrage.
Cas particulier – Portainer
Portainer est un cas spécial car il s’auto-gère. On ne peut pas le restaurer depuis son propre interface puisqu’il sera arrêté pendant la procédure. Toute la restauration se fait en ligne de commande.
1 – Noter l’état actuel
ls -la /home/USER/docker/portainer/
ls -la /home/USER/docker/portainer/data/
Vérifie que la sauvegarde contient bien les fichiers critiques :
sudo rclone --config /home/USER/.config/rclone/rclone.conf ls "gdrive:/daily/YYYY-MM-DD/portainer/data/"
Tu dois voir portainer.db, portainer.key et portainer.pub avec des tailles cohérentes.
2 – Arrêter et supprimer Portainer en ligne de commande
5 – Redonner les droits root et relancer Portainer
Les fichiers dans portainer/data/ doivent appartenir à root – Portainer les gère en root et refuse de démarrer autrement. C’est une étape indispensable après restauration :
Ouvre Portainer dans ton navigateur (https://[IP-DU-BEELINK]:9443).
Si Portainer retrouve ton tableau de bord habituel sans te demander de créer un nouveau mot de passe, la restauration est réussie. Vérifie que tes stacks sont bien présentes dans l’onglet Stacks.
Nettoyage
rm -rf /home/USER/docker/portainer-BACKUP-TEST
En cas de problème
Le logiciel démarre mais ne retrouve pas les données Vérifie que les chemins dans le docker-compose.yml correspondent bien aux dossiers restaurés. Un chemin mal copié suffit à pointer vers un dossier vide.
« Can’t follow symlink without -L/–copy-links » Ce message apparaît lors de la restauration de NPM. Ajoute --copy-links à la commande rclone de restauration – voir la section NPM ci-dessus.
« Permission denied » au démarrage du container Les fichiers restaurés par Rclone appartiennent à USER, mais certains containers ont besoin que leurs dossiers appartiennent à root. C’est systématiquement le cas pour Portainer. Tape :
Portainer affiche « New Portainer installation » Les fichiers de données n’ont pas les bons droits après restauration. Arrête le container, refais sudo chown -R root:root /home/USER/docker/portainer/data, puis relance avec docker run.
Tu veux restaurer une version plus ancienne Remplace simplement YYYY-MM-DD par la date souhaitée dans la commande de l’étape 4. Les sauvegardes hebdomadaires sont dans gdrive:/weekly/YYYY-Wxx/ et les mensuelles dans gdrive:/monthly/YYYY-MM/.
Dans le prochain article
Maintenant que la sauvegarde et la restauration sont opérationnelles et testées, on verra comment installer un nouveau container en suivant dès le départ les bonnes pratiques – sans avoir à corriger la configuration après coup.
Il est prudent de sauvegarder régulièrement la base de données et les fichiers d’un site WordPress. J’ai testé de nombreuses solutions avant de m’arrêter depuis 6 mois sur Updraft Plus, en version gratuite. Updraft Plus est vraiment très bien pour réaliser des sauvegardes planifiées. Je l’ai essayé en ftp et sur dropbox
Installer et activer Updraft Plus
Comme n’importe quelle extension.
Planifier les sauvegardes Updraft Plus
Dans le menu Réglages / Sauvegardes Updraft Plus, onglet réglages :
Fichiers : bimensuel, 4
Base de données hebdo, 10
Sur dropbox
exclure de sauvegarde :
Je laisse tel quel, avec à exclure des sauvegardes :
« backup*,*backups,backwpup*,wp-clone,snapshots »
et « upgrade,cache, updraft,backup*, *backups,mysql.sql,debug.log »
Dans les réglages avancés, je vérifie que « supprimer la sauvegarde locale » est bien coché.
Enregistrer.
Régler la connexion à Dropbox
Lorsqu’on enregistre les réglages précédents, une fenêtre s »ouvre :
Updraft Plus : Réglage pour Dropbox
Cliquer sur le lien puis se connecter à son compte dropbox.
Ensuite cliquer sur le bouton « complete setup », qui nous ramène dans notre tableau de bord WordPress. La première sauvegarde commence automatiquement.
Utilisation d’une sauvegarde FTP pour transférer d’un hébergement à un autre
En transférant des sauvegardes d’un site par FTP on a un gain considérable :
pas besoin de gérer la taille des fichiers zip : Updraft plus s’en charge (il découpe l’ensemble des fichiers à sauvegarder en autant de « lot » que nécessaire) ;
Pas besoin de transiter par mon ordinateur : adieu les délais liés à une connexion ADSL poussive, adieu les problèmes de caractères spéciaux !
Le seul inconvénient est que le transfert est réalisé en FTP, sans encryption, lorsqu’on utilise la version gratuite du site.
Régler les paramètres FTP du « remote storage »
Dans les « settings » de Updraft Plus, cocher FTP comme « remote storage ».
Régler les paramètres FTP comme suit :
FTP server:
ftp://oifw.vps.infomaniak.com
FTP login:
ohwt_flo1
FTP password:
VotreMotDePasse
Remote path:
/updraft/
Passive mode:
coché
Ici les login et password donnent accès au répertoire /ald-utils/Flo-test/ et dans ce répertoire j’ai créé le répertoire /ald-utils/Flo-test/updraft .
Cliquer sur le bouton : « Test FTP Settings » pour vérifier les réglages.
Ensuite la sauvegarde se fait. Updraft plus gère la création de fichiers zippés de taille correcte. Par exemple 10 fichiers zippés nommés nomfichier-uploads.zip, nomfichier-uploads1.zip à nomfichier-uploads9.zip
Restaurer les fichiers Updraft Plus
Ensuite pour les décompresser dans le bon endroit, utiliser la fonction restauration de Updraft plus :
placer les fichiers de backup dans le répertoire wp-content/updraft du site cible
Dans le site cible, aller dans réglages / sauvegardes UpdraftPlus
Dans l’onglet sauvagardes existantes, cliquer sur le lien « Scanner le dossier local pour recherche de nouveaux lots de sauvegarde ». On voit alors apparaître la sauvegarde ajoutée manuellement
Commentaires récents