Catégorie : Geek

Je suis toujours dans mes sauve­gardes. Je veux avoir une copie de tout dans mes sauve­garde, données des services en ligne incluses.

Je pensais faire ça faci­le­ment avec Pocket. Ils ont une API, assez simple.

En pratique je me retrouve à faire essen­tiel­le­ment de l’in­gé­nie­rie inverse. La docu­men­ta­tion indique des choses qui n’existent pas ou ne fonc­tionnent pas, et ne donne aucune infor­ma­tion sur des éléments essen­tiels qu’on reçoit (genre la gestion des erreurs).

Authen­ti­fi­ca­tion

Contrai­re­ment aux méca­nismes OAuth habi­tuels, leur autho­rize ne renvoie pas de code tempo­raire à échan­ger. Pour récu­pé­rer l’access_token, il faut le deman­der avec le request_token obtenu lors de l’échange serveur à serveur initial.

Ce request_token semble ne pas avoir de durée de vie. Il n’a en tout cas pas de refresh_token asso­cié.

Méca­nisme de régu­la­tion

L’API indique des limi­ta­tions à 320 appels par heure. C’est d’au­tant plus impor­tant que pour télé­char­ger mes plus de 29 000¹ items par pages de 30 maxi­mum, je vais forcé­ment dépas­ser le nombre de requêtes que je peux faire en une heure.

Il y a un méca­nisme auto­ma­tique prévu pour la régu­la­tion mais le serveur n’en­voie pas les entêtes prévues pour ça. Je sais juste qu’au bout d’un moment j’ob­tiens des erreurs 403 et que ça semble venir de là.

Je vais devoir gérer ça à la main. Pour l’ins­tant je note l’heure de chaque requête dans un tableau. Quand mon tableau fait 320 éléments, je retire le premier élément et attend l’heure de cet élément + 1 heure avant de conti­nuer.

Pagi­na­tion

Le méca­nisme pour la pagi­na­tion est assez famé­lique : 30 items maxi­mum par requête, plus un offset pour passer à la page suivante. C’est une mauvaise méthode pour itérer à travers des milliers d’items et ça ne trompe pas : Les requêtes sont effec­ti­ve­ment de plus en plus lentes au fur et à mesure des pages. C’est visible et c’est pénible.

Le serveur prévoit de renvoyer un champ total qui permet de savoir s’il reste encore des éléments. Les réponses du serveur ne me renvoient malheu­reu­se­ment pas ce champ alors je vais juste itérer jusqu’à obte­nir une réponse vide sans erreur.

Il y a aussi un champ since qui permet de limi­ter la recherche aux éléments plus récents qu’une certaine date. J’ima­gi­nais pouvoir me baser là dessus pour la pagi­na­tion : Parcou­rir du plus vieux au plus récent, iden­ti­fier la date du plus récent et repar­tir de là à la prochaine itéra­tion. C’est d’ailleurs la procé­dure recom­man­dée pour beau­coup de services qui veulent éviter les problèmes que pose le parcours par offset. Malheu­reu­se­ment ça n’est pas utili­sable pour la pagi­na­tion : les items retour­nés ne sont correc­te­ment ordon­nés ni par date d’ajout ni par date de modi­fi­ca­tion.

Étran­ge­ment, il semble que la limite de 30 items par page ne soit pas forcée. Il semble que ça fonc­tionne avec beau­coup plus, mais que ça génère aussi plus d’er­reurs. Le meilleur compro­mis semble effec­ti­ve­ment dans les 25 à 30 items par page.

Dernière spéci­fi­cité, j’ai l’im­pres­sion de temps de réponse plus longs et d’er­reurs plus fréquentes quand je vais du plus vieux au plus récent. Je n’ai pas véri­fié cette impres­sion avec des chiffres mais autant rester sur l’ordre par défaut : du plus récent au plus vieux.

Docu­men­ta­tion incom­plète

J’ai dit qu’il me manquait les entêtes de régu­la­tion et le champ total à la racine de la réponse. À l’op­posé, j’ai quelques champs qui ne sont pas dans la docu­men­ta­tion.

Le status semble être un entier avec, 0 pour une erreur, 1 pour OK, 2 quand il n’y a rien à affi­cher depuis une mise à jour. Quand status est à 0, le champ error contient le message d’er­reur.

Il y a aussi un maxAc­tions, dont je ne connais pas le sens.

Données irré­cu­pé­rables sur le serveur

Pour une raison ou une autre, certaines de mes données semblent corrom­pues ou irré­cu­pé­rables sur leur serveur (comme quoi la sauve­garde est utile ;-)..

J’ai 20 items qui provoquent systé­ma­tique­ment une erreur 504. Je peux récu­pé­rer ceux avant, ceux après, mais pas ceux là². C’est vrai peu importe le sens de parcours (mais les offset ne sont logique­ment pas les mêmes dans les deux sens).

Je n’ai pas plus d’ex­pli­ca­tion. Je ne peux même pas connaitre les iden­ti­fiants concer­nés pour deman­der leur suppres­sion.

Poten­tiel­le­ment ce sont des données qui ne peuvent plus être réhy­dra­tées sur leurs serveurs, soient qu’il manque des infor­ma­tions essen­tielles, soit que leurs compo­sants ne savent pas complé­ter ce qui manque (le serveur du lien sauve­gardé qui répond bizar­re­ment ?).

Erreurs aléa­toires

Même avec une pagi­na­tion basique, dans l’ordre par défaut, j’ai des erreurs fréquentes, aléa­toires.

La plupart des 403 semblent liées à la limi­ta­tion du nombre de requêtes, mais pas forcé­ment toutes.

La plupart des 504 semblent liées à mes données irré­cu­pé­rables mais il est arrivé que ça finisse pas passer quand même.

Les 502, en géné­ral il suffit de relan­cer la même requête, mais parfois l’er­reur semble persis­ter un moment.

Auto­ma­ti­sa­tion

Je parcours fina­le­ment tout par page de 30 et je mets à jour à chaque page le fichier de sauve­garde (pour les données récu­pé­rées) et le fichier de confi­gu­ra­tion (pour le nouvel offset de la prochaine requête). Si j’ai des erreurs inat­ten­dues, je pour­rai relan­cer de là où j’en étais.

Si j’ai une page en erreur, je reprends tous les items de la page mais en allant les cher­cher mais 1 par 1 à partir de leur offset respec­tif. Parfois je ne retrouve pas l’er­reur et ça permet de récu­pé­rer tout. Parfois l’er­reur persiste sur un des éléments. Dans ce dernier cas l’idée c’est de pouvoir récu­pé­rer tous les bons items de la page et d’igno­rer l’unique qui est en erreur.

Ça n’est pas parfait — si j’ai une erreur répé­tée mais tempo­raire sur un item, il sera ignoré silen­cieu­se­ment dans la sauve­garde — mais je n’ai pas mieux.

Une fois le parcours tota­le­ment fait une fois, je peux utili­ser le since pour faire du diffé­ren­tiel.

Le code est sur https://github.com/edas/pocket-backup

RGPD à la rescousse

J’ai quand même prévu de faire une requête RGPD pour deman­der un export de mes données. On verra s’ils arrivent à me récu­pé­rer les 20 items qui sont en erreur perma­nente.

Si oui, je tente­rai de les effa­cer pour reprendre un fonc­tion­ne­ment sans erreur. Sinon, je tente­rai peut-être de réini­tia­li­ser le compte ou migrer ailleurs.

---

1. Oui, tout ça. J’en suis moi-même étonné. J’ai tracé des usages depuis au moins fin 2010 mais je me demande si je ne l’uti­li­sais pas au début de mon passage à Yahoo! en 2007–2008 du temps où ça s’ap­pe­lait Read It Later. Ça fait une moyenne de 4 à 6 items par jour suivant la date rete­nue. ↩︎
2. Je me les note pour moi-même : aujourd’­hui ce sont les offset 14053, 14481, 17689, 18291, 18629, 19389, 20363, 20815, 20996, 20999, 21512, 21923, 22275, 22283, 22346, 23386, 23841, 24189, 24414, 27441. ↩︎

Nettoyer les écuries d’Au­gias c’est de la nioniotte à côté du projet de rapa­trier toutes mes données en local pour les sauve­gar­der.

Ce que j’ai déjà

1. Où sauve­gar­der en local
2. Sauve­gar­der Gmail et Amélio­rer ma sauve­garde Gmail.
3. Sauve­gar­der les SMS et les histo­riques d’ap­pel
4. Sauve­gar­der Google Drive et Google Photos
5. Sauve­gar­der Github
6. Sauve­gar­der mes sites web
7. Sauve­gar­der Stan­dard Notes
8. Sauve­gar­der les calen­driers Google
9. Sauve­gar­der les contacts Google
10. Sauve­gar­der Bitwar­den
11. Sauve­gar­der Pocket

---

Ce qui manque encore

Je vais étendre la liste au fur et à mesure. Il me manque encore pas mal de choses, et pas le plus simple. Au moins :

• Les favo­ris Fire­fox Sync
• Les abon­ne­ments RSS Inorea­der
• Les abon­ne­ments, listes et peut-être messages Masto­don
• Les abon­ne­ments, listes et peut-être messages Bluesky
• Abon­ne­ments et messages Insta­gram
• Les messages Tele­gram
• Les messages What­sapp
• Les messages Signal
• Mes abon­ne­ments Newpipe (local Android)
• Mon histo­rique et docu­ments Docto­lib
• Mes contacts Linke­din, peut-être les messages aussi
• Mes histo­riques Spotify, Netflix, etc.
• Les discus­sions privées Slack
• Les factures et histo­riques d’un peu partout (boutiques en ligne, abon­ne­ments divers, edf, sncf, hôtel, inter­net, télé­phone, etc.)
• Les rele­vés sécu et mutuelle
• Les rele­vés banque

Je regrette qu’on n’ait pas un vrai gros projet Open Source dont l’objec­tif est d’avoir des connec­teurs pour tous les services en ligne de façon à rapa­trier toutes nos données en local.

Cozy Cloud aurait pu faire ça mais la direc­tion prise ne se centrait pas sur les connec­teurs et le projet commer­cial n’a pas pu trou­ver sa place.

---

Auto­ma­ti­sa­tion en trois niveaux

Proba­ble­ment qu’il me faudra faire évoluer mes outils. Je ne peux pas lais­ser les mots de passe de tout et n’im­porte quoi en clair.

J’ima­gine trois niveaux :

1. Les sauve­gardes auto­ma­tiques. J’ai des token Oauth voire des mots de passe en clair dans les fichiers de confi­gu­ra­tion. C’est valable quand les données ne sont pas sensibles et que je tiens à ce que ça sauve­garde « sans moi »
2. Les sauve­gardes que je lance­rai à la main, quand les données ou les mots de passe sont sensibles. Je pense faire des programmes qui s’in­ter­facent direc­te­ment avec le coffre Bitwar­den, que je déver­rouille­rai dans la session pour l’oc­ca­sion.
3. Ce qui va être une énorme galère à coder : les service en ligne sans API ouverte avec de l’of­fus­ca­tion sur l’au­then­ti­fi­ca­tion, ainsi que les services en ligne derrière un 2FA non auto­ma­ti­sable ou un capt­cha complexe à mimer. Là j’ima­gine une exten­sion navi­ga­teur qui sauve­garde ce dont j’ai besoin quand je passe sur le site.

---

Copie en ligne

Bon, chaque chose en son temps.

Avant tout ça il faudra déjà que je branche BorgBase ou BackB­laze pour avoir une copie chif­frée en ligne, parce que pour l’ins­tant ça ne fait que reco­pier en local.

Avec dans les 3 To, ça me pren­dra bien un bon mois pour faire la première synchro­ni­sa­tion. Je sais envoyer plus vite mais je doute qu’on me libère des Gb/s pour moi tout seul.

Je conti­nue mes sauve­gardes.

Le coffre avec tous mes mots de passe est parti­cu­lier. J’ai fait le choix de le stocker en ligne pour synchro­ni­ser tous mes appa­reils mais perdre tous mes mots de passe n’est pas une option.

Bitwar­den a effec­ti­ve­ment une copie locale sur tous les appa­reils mais ça ne me couvre pas si quelque chose est supprimé sur le serveur et que la suppres­sion se réplique alors sur tous mes appa­reils.

J’ai besoin d’une vraie copie locale, à moi.

Je n’ai cepen­dant pas besoin que la copie soit en clair. Plus exac­te­ment, les données sont trop sensibles et je préfère n’avoir que la copie chif­frée. Je sais que je trou­ve­rais comment la déchif­frer à la main en cas de besoin (je l’ai déjà fait par le passé).

Je pour­rais utili­ser la ligne de commande offi­cielle et synchro­ni­ser le coffre avec une clé d’API. Il n’y a pas besoin du mot de passe maitre pour ça. Je ne maitrise cepen­dant pas où il stocke le coffre et j’avais moyen­ne­ment envie de ça sur des tâches de sauve­garde.

J’ai réim­plé­menté ça à la main avec un programme généré par IA. Il télé­charge les para­mètres de login, le profil utili­sa­teur et le coffre (chif­fré).

---

C’est du Rust parce que j’es­pé­rais utili­ser le SDK offi­ciel. Malheu­reu­se­ment ils n’ex­portent pas les appels bas niveau que je souhaite. J’ai perdu bien trop long­temps à le comprendre et à batailler. J’ai fini par faire mon implé­men­ta­tion à la main.

Si j’avais su que je fini­rais avec juste quelques appels HTTP, ça ne serait pas en Rust. Tant pis.

Je conti­nue mes sauve­gardes mais je n’ai pas trouvé d’ou­til adapté pour aller télé­char­ger les contacts google. J’en suis même étonné.

Je suis passé quelques minutes par IA et j’ai pu récu­pé­rer ce qui m’in­té­res­sait avec https://github.com/edas/google-contacts-backup

Le programme récu­père le format brut en prove­nance de Google, avec juste une sauve­garde en base64 des images en lien.

---

J’au­rais préféré un outil plus abouti qui sache ne reté­lé­charge que ce qui a changé. On verra une prochaine fois.

Si toute­fois vous connais­sez un outil un peu smart, glis­sez-moi le nom en commen­taire.

Je conti­nue mes sauve­gardes.

Les calen­driers Google c’est fina­le­ment plus simple que le reste. Dans les para­mètres de chaque calen­drier, tout à la fin, il y a une adresse ics privée.

Je peux me conten­ter de faire un appel régu­liè­re­ment et sauve­gar­der ça.

/opt/homebrew/bin/wget -nv -O /path/to/target.ics https://calendar.google.com/calendar/ical/xxxxx/private-xxxxx/basic.ics

Le plus gros calen­drier fait tout juste 2 Mo. Il change tous les jours mais ça reste encore un poids accep­table.

---

Il faut juste bien penser à le faire pour chaque calen­drier, y compris ceux que je crée­rai dans le futur. Ça doit pouvoir s’au­to­ma­ti­ser via les API Google Calen­dar mais je ne suis pas certain que ça vaille le coup pour l’ins­tant.

Je conti­nue mes sauve­gardes.

Stan­dard Notes j’ai beau­coup de choses dessus, surtout que j’y ai rapa­trier mes anciennes notes de nvalt puis de Simple Note.

Il y a un méca­nisme spéci­fique de backup dans Stan­dard Notes, donc un qui permet d’en­voyer une archive par email toutes les semaines. Chez moi ça envoyait en plusieurs exem­plaires, et sans reti­rer le chif­fre­ment.

Il y en a un autre qui permet de garder une trace locale. Je pour­rais l’ac­ti­ver sur mon poste quoti­dien et faire en sorte que cette trace locale soit ensuite récu­pé­rée par Google Drive ou Treso­rit. En pratique j’ai toujours eu des ennuis dès que je chaîne les outils de synchro­ni­sa­tion. Je préfère éviter.

J’ai trouvé sn-cli, qui fait ce que j’es­pé­rais.

#!/bin/sh
APP=$1
OUT=$2
EMAIL=xxxx
PASS='xxxx'

SN_EMAIL=$EMAIL SN_PASSWORD=$PASS $APP get items > $OUT/standardnotes.items.json
SN_EMAIL=$EMAIL SN_PASSWORD=$PASS $APP get notes > $OUT/standardnotes.notes.json
SN_EMAIL=$EMAIL SN_PASSWORD=$PASS $APP get tags > $OUT/standardnotes.tags.json

Ça me demande de lais­ser mon mot de passe en clair sur le disque de sauve­garde (qui lui est chif­fré). Pas idéal mais ce n’est pas un jeu de données très sensible alors ça peut passer.

---

Plus tard je segmen­te­rai proba­ble­ment deux types de sauve­gardes, une auto­ma­tique et une que je lance­rai à la main qui utili­sera la CLI bitwar­den avec une session unique­ment le temps de la sauve­garde. Ce jour là ça bascu­lera peut-être dans mes sauve­gardes à la main. Ça reste accep­table entre temps.

Toujours dans mes sauve­gardes.

J’en ai profité pour passer quelques sites statiques basiques direc­te­ment sur Github. Ils seront sauve­gar­dés avec Github.

C’est moins évident pour les word­press et ce qui a une base de données. Là j’ai fait un sous-réper­toire « data » pour chaque projet avec un script cron qui y fait un dump quoti­dien.

J’ai ensuite un rsync qui va cher­cher régu­liè­re­ment les données qui sont censées bouger (fichiers télé­char­gés, dump de base de données).

J’ai enfin un script cron qui sauve­garde la confi­gu­ra­tion du serveur web (nginx, php) sur le serveur lui-même, et là aussi un rsync pour la rapa­trier en local.

C’est fait à la main mais c’est proba­ble­ment suffi­sant;

Bon, pas tout Github, juste les projets auxquels je parti­cipe.

Il y a moyen de faire ça manuel­le­ment avec git clone --mirror. Je voulais quelque chose qui aille au moins lister mes projets pour les synchro­ni­ser auto­ma­tique­ment sans que j’ai besoin de les ajou­ter manuel­le­ment à mes scripts de sauve­garde.

J’ai trouvé git-sync (atten­tion, il y a beau­coup d’ou­tils du même nom) qui fait exac­te­ment ce que je veux.

La confi­gu­ra­tion

# Repository settings
include_forks: true # Include forked repositories
include_wiki: true # Include wiki's
include_repos: [] # Include specific repositories
exclude_repos: [] # Exclude specific repositories
include_orgs: [] # Include repositories from specific organizations
exclude_orgs: [] # Exclude repositories from specific organizations
raw_git_urls: [] # Raw valid git URLs

# Authentication
username: username
tokens: [xxxxxx]

# Server settings
backup_dir: /path/to/backup-dir
clone_type: mirror # Default: bare
concurrency: 5
retry:
  count: 3
  delay: 10 # in seconds
platform: github
server:
  domain: github.com
  protocol: https
notification:
  enabled: false

Et pour lancer git-sync --config /path/to/config.yaml

Au premier essai ça a synchro­nisé énor­mé­ment de choses. Ça liste tous les dépôts où vous êtes membres, donc aussi tous les dépôts privés qui vous ont été parta­gés. Je me suis rendu compte qu’il y en avait un paquet pour moi, et j’ai pu faire un peu de ménage. Ça m’a aussi permis de marquer comme archives un paquet de vieux dépôts inuti­li­sés, et de suppri­mer des trucs vides ou à peine commen­cés.

---

Je n’ai pas besoin de sauve­gar­der tout ça très fréquem­ment. Une fois par semaine devrait suffire. Main­te­nant, comme ça ne télé­charge que ce qui change, j’exé­cu­te­rai peut-être en quoti­dien.

Je conti­nue toujours sur mes sauve­gardes.

Pour Google Drive j’au­rais pu utili­ser le client offi­ciel mais j’ai besoin qu’il synchro­nise même quand je n’ai pas de session ouverte. J’ai­me­rais aussi pouvoir gérer plusieurs utili­sa­teurs faci­le­ment.

J’ai fouillé et trouvé rclone qui fait ça pour moi.

La procé­dure pour créer ses propres clés d’API est un peu pénible mais le reste fonc­tionne assez faci­le­ment. J’ai créé une clé d’API pour chaque compte. Rétros­pec­ti­ve­ment je ne suis pas certain que ça valait le coup.

L’ou­til est dispo­nible sous home­brew

brew install rclone

Ma config

[gdrive-x]
type = drive
client_id = xxx.apps.googleusercontent.com
client_secret = xxx
scope = drive
token = {"access_token":"xxxx","token_type":"Bearer","refresh_token":"xxx","expiry":"xxx"}
team_drive = 

[gphotos-x]
type = gphotos
client_id = xxxx.apps.googleusercontent.com
client_secret = xxxx
include_archived = true
read_only = true
start_year = 1970
token = {"access_token":"xxxx","token_type":"Bearer","refresh_token":"xxx","expiry":"xxx"}

Et mon script de lance­ment

/opt/homebrew/bin/rclone --config=/path/to/rclone.conf --log-level NOTICE --fast-list --drive-skip-shortcuts sync gdrive-x: /path/to/gdrive-x/

/opt/homebrew/bin/rclone --config=/path/to/rclone.conf --retries-sleep 10s --log-level NOTICE --fast-list --exclude /media/all/** --exclude /media/by-year/** --exclude /media/by-day/** --exclude /upload/** sync gphotos-survol: /path/to/gphotos-x/

Le fonc­tion­ne­ment par défaut sur Google Photos implique beau­coup de doublons. La même image est sauve­gar­dée dans les albums où elle est, plus dans /media/all, dans l’an­née concer­née de /media/by-year, dans le mois concerné de /media/by-month et dans le jour concerné dans /media/by-day.

On peut faci­le­ment exclure une partie de ces réper­toires (j’ai gardé la répar­ti­tion par mois, ils décon­seillent de garder celle par jour qui impose trop d’ap­pels à Google Photos). Toutes les images ne sont pas toute­fois dans des albums donc soit on a des doublons, soit on perd la notion d’al­bums.

Il faut penser à exclure /upload aussi pour ne pas avoir d’er­reur inutiles. Ce réper­toire ne sert que pour envoyer des images à Google.

La partie Photo est longue. Il est facile d’ou­tre­pas­ser les quotas qui sont assez réduit sur ce produit, même avec sa propre clé d’API. En cas de diffi­cul­tés on peut faire une première passe avec les options suivantes : --tpslimit 0.3 --tpslimit-burst 10 --low-level-retries 1 --retries 1 --transfers 1 --checkers 1. Atten­tion, dans ce cas ça va réel­le­ment durer des plombes.

---

Je vais faire lancer ça entre une fois par jour et une fois par semaine, ça suffira très bien pour juste un filet de sécu­rité.