Si vous utilisez un Mac et un iPhone, vous savez que l'app Photos d'Apple c'est un peu beaucoup une prison dorée. C'est génial tant qu'on reste chez Apple, mais dès qu'on veut sortir ses photos pour en faire une vraie sauvegarde sur un NAS ou un disque externe, ça devient vite compliqué.
Y'a bien une option "Exporter les originaux non modifiés" qui fait le job, mais elle n'inclut pas vos retouches, vos recadrages et la structure des dossiers est souvent inexistante. Du coup, on se retrouve avec un vrac de fichiers IMG_1234.JPG pas très sexy.
Mais vous me connaissez, j'suis toujours dans les bons coup et j'ai une bonne nouvelle pour vous. Rui Carmo, un développeur qui en a eu marre (comme nous), a codé un petit outil en Swift baptisé PhotosExport. Ça fonctionne en ligne de commande et ça va piocher directement dans votre librairie Photos pour extraire vos fichiers proprement.
Par défaut, l'outil se concentre sur l'année en cours, mais avec les options --year et --end-year, vous pouvez remonter le temps et tout récupérer d'un coup.
PhotosExport crée une hiérarchie Année/Mois (genre 2024/01/) et renomme chaque fichier avec un timestamp précis. Ça évite les collisions de noms (avec un petit suffixe si besoin) et ça met de l'ordre dans le chaos.
Ce qui est cool, c'est que si vous ajoutez l'option --metadata, il tente aussi d'exporter les infos (lieux, dates, données techniques...) dans un fichier JSON à côté de l'image. C'est du "best effort" (car il ne va pas forcément récupérer la reconnaissance des visages ou des trucs trop spécifiques à Apple), mais ça permet de garder une trace des infos essentielles si un jour vous changez de crémerie.
Attention quand même, il y a un petit prérequis : il faut être sous macOS 13 (Ventura) ou plus récent. Et au premier lancement, macOS va vous demander d'autoriser l'accès à vos Photos (le fameux TCC). C'est normal, c'est pour la sécurité.
L'installation se fait via make build si vous avez Xcode ou les outils de développement. Ensuite, vous lancez la commande, et hop, ça mouline. Le mode incrémental est pas mal aussi car il ignore les fichiers qui existent déjà dans le dossier de destination, ce qui permet de relancer l'outil sans tout réécrire.
Vous pouvez même imaginer scripter ça pour que ça tourne régulièrement vers votre NAS, à condition de bien gérer les permissions d'accès au niveau du terminal ou du script (ce qui peut être un peu sioux avec les sécurités d'Apple, mais ça se fait).
Si vous cherchez aussi à sécuriser le reste de votre vie chez Apple, jetez un œil à ma méthode pour
sauvegarder vos données Apple Notes
ou encore comment
sauvegarder votre iPhone sur un disque externe
. C'est toujours mieux d'avoir une copie locale, car on ne sait jamais ce qui peut arriver à un compte iCloud (Genre si Donald Trump décide de tout couper...).
Bon, on va pas se mentir, j’étais pas parti pour l’écrire cet article. Mais faut dire que j’ai un peu merdé dans les grandes largeurs pour le live, donc bon, sachant qu’en plus je traite d’un angle particulier de l’usage de ce cher Plakar, autant en faire un billet, ça sera le premier (et j’espère pas le seul) de 2026. On y croit ?
Plakar est une solution développée en France par une petite équipe apparemment friande des jeux de mots, puisqu’au delà de son nom même, le site est hébergé par la société Kandbaz. Voilà voilà…
Des confrères blogueurs ont déjà fait quelques présentations de l’outil (exemple: Adrien), principalement pour s’en servir sous Linux. Il se trouve que j’ai une machine Windows qui a besoin d’être sauvegardée, en vue d’une mise à jour de firmware de SSD qui devrait bien se passer, mais on doit toujours faire une sauvegarde avant de faire ce genre de choses. Mieux vaut prévenir que guérir comme on dit. Et la présentation en live aurait du se passer plus ou moins tranquille, mais bon, j’ai pas percuté la micro-coupure pendant plus d’une heure (habitué à ne pas avoir d’activité dans le chat), donc, je vous remet le processus sur « papier numérique ».
Je ne redétaille pas l’installation de Garage parce qu’on l’a faite en live sans souci.
Petit rappel rapide des caractéristiques de l’outil
On a donc un outil principalement en ligne de commande, qui repose sur un concept voisin de celui de Borg, qui nécessite la configuration d’un dépôt et propose un chiffrement natif des sauvegardes. Ce dépôt, local ou distant, peut être contacté de différentes manières, natives (SFTP/SSH) ou via des intégrations supplémentaires à installer au besoin. C’est le cas notamment du support S3.
Le setup
En soit, c’est très bien documenté : une fois l’outil installé, vous ajoutez le package directement, mais vous tombez sur un mur que je n’aime pas : créer un compte Plakar pour accéder aux intégrations. J’ai une petite idée de pourquoi ça peut avoir du sens (les intégrations concernent en général des solutions d’entreprise), mais ça me gonfle plus que profondément quand ça concerne des particuliers, qui se font déjà violer en permanence, donc pas la peine d’en rajouter (on a la même avec BitWarden, ou El Gato et son Stream Deck Marketplace pour l’intégration… d’OBS, qui est pourtant mis en avant comme native – c’est donc faux). Fort heureusement, l’outil propose de builder l’intégration depuis les sources qui sont disponibles sur Github, comme le reste des sources de l’outil, et ça sans création de compte. C’est facile… si on est sous Linux.
J’avoue que pour l’instant les installations sont un peu brutes de décoffrage, mais le support Windows est vraiment frais, donc je ne vais pas trop me formaliser là-dessus. Le fait que ça doit déjà proposé pour une version 1.0 est déjà assez cool. Par contre, concernant la compilation des intégrations, c’est plus ardu : il faut disposer de Go (dans la version qui est demandée par Plakar), de Make (à priori à part Chocolatey pas de moyen indépendant), et peut-être d’autres outils, mais je me suis heurté à un mur à cause de ça. La solution, comme d’hab’, aura demandé un pas de côté.
La cross compilation à la rescousse
Une des particularités de Go, c’est qu’on peut nativement compiler pour un autre système d’exploitation que celui sur lequel on se trouve. Et la chaine de compilation nécessaire est plus facile à déployer sous Linux; ça tombe bien, WSL est là pour ça. Après l’installation de la même version de Plakar que sous Windows, j’ai donc installé build-essential (pour être sûr d’avoir un max d’outils, donc Make), installé la version 1.24.12 de Go via asdf-vm (je vous renvoie vers la doc de Stéphane Robert qui a tout expliqué au sujet de cet outil trop pratique). Et pour la compilation d’un autre OS, c’est simple : on configure une variable d’environnement, GOOS, éventuellement l’architecture (oui, parce que c’est aussi possible), l’extension de fichier dans la variable EXT (parce que sous Windows, il faut un .exe pour qu’il soit exécutable – oui c’est débile en 2026, mais que voulez-vous, l’IA c’est plus intéressant à intégrer que moderniser un OS don personne ne voulait à la base) et on lance la compilation de l’intégration via la commande plakar ad-hoc. Vraiment, c’est aussi simple que ça :
$ export GOOS=windows
$ export EXT=.exe
$ plakar pkg build s3
info: fetching https://plugins.plakar.io/kloset/recipe/v1.0.0/s3.yaml
/usr/bin/make -C /tmp/build-s3-v1.0.7-161840773 EXT=.exe
3fe849cb: OK ✓ /manifest.yaml
3fe849cb: OK ✓ /s3Importer.exe
3fe849cb: OK ✓ /s3Exporter.exe
3fe849cb: OK ✓ /s3Storage.exe
3fe849cb: OK ✓ /
Plugin created successfully: s3_v1.0.7_windows_amd64.ptar
$ ls -l
.rw------- 1 42M seboss666 16 Jan 22:29 s3_v1.0.7_windows_amd64.ptar
On peut donc désormais copier le fichier ptar sous Windows (il faudra que je creuse ce format qui semble un peu maison), et on peut l’installer avec la bonne commande :
> .\plakar.exe pkg add ./s3_v1.0.7_windows_amd64.ptar
> .\plakar.exe pkg list
s3@v1.0.7
La sauvegarde ? Ben ça fonctionne
On peut donc attaquer le dur. J’ai juste suivi la doc de l’intégration, à savoir créer le kloset l’initialiser, et lancer le backup d’un dossier vers ce kloset là :
.\plakar.exe store add garage s3://192.168.1.201:3900/backup-pc access_key=<accesskey> secret_access_key=<secret_key> use_tls=false
.\plakar.exe at "@garage" create
repository passphrase:
repository passphrase (confirm):
.\plakar.exe at "@garage" ls
repository passphrase:
.\plakar.exe at "@garage" backup C:\\Users\\Seboss666\\Pictures\\blog
repository passphrase:
e363f7fa: OK ✓ /C:/Users/Seboss666/Pictures/blog/Firefox_groupe_onglets.png
e363f7fa: OK ✓ /C:/Users/Seboss666/Pictures/blog/Firefox_profils.png
e363f7fa: OK ✓ /C:/Users/Seboss666/Pictures/blog/docker-docker-everywhere.jpg
e363f7fa: OK ✓ /C:/Users/Seboss666/Pictures/blog/418-error-page.png
e363f7fa: OK ✓ /C:/Users/Seboss666/Pictures/blog/cross.svg
(...)
.\plakar.exe at "@garage" ls
repository passphrase:
2026-01-16T21:40:31Z e363f7fa 42 MiB 0s /C:/Users/Seboss666/Pictures/blog
Bonus, on peut vérifier l’état du backup depuis un autre PC, ou un autre OS, donc je suis retourné sur WSL, j’ai viré les variables d’environnement pour builder l’intégration pour Linux cette fois, et rebuildé/ajouté l’intégration. On reprend ensuite la même commande pour ajouter le Kloset, mais pas besoin de l’initialiser, on peut directement lister son contenu en fournissant la bonne passphrase :
$ plakar store add garage s3://192.168.1.201:3900/backup-pc access_key=<access_key> secret_access_key=<secret_key>
$ plakar at "@garage" ls
repository passphrase:
2026-01-16T21:40:31Z e363f7fa 42 MiB 0s /C:/Users/Seboss666/Pictures/blog
On peut donc faire à peu près ce qu’on veut dès lors : restauration complète ou partielle, création de nouveaux backups, etc.
Verdict
Donc oui, tout a fonctionné pratiquement du premier coup. J’ai quand même tâtonné au départ concernant le build de l’intégration, à vouloir « make » direct à partir du dépôt git. Mais dans ce cas, on se retrouve avec les trois binaires, sans infos sur la construction du fameux ptar (on est là encore dans le simili-jeu de mots, vraiment…), ce qui est plutôt dommage. Il m’aura fallu quelques minutes pour me résigner à utiliser plakar directement. Il faudrait aussi un peu plus de retour sur les commandes qui se déroulent bien (sans erreur). Autant quand on se plante, on le sait, mais quand on se plante pas, voir juste un retour à la ligne est un peu frustrant et déroutant.
Il y a question aussi sur les performances de la sauvegarde testée. j’ai testé sur un dossier de 108 images, et un des développeurs s’est étonné sur BlueSky du temps que ça a pris. J’avoue que pour l’instant, je n’ai pas creusé le sujet, il y a des chances que ça soit dû aux performances S3 elle-mêmes, à NTFS, une combinaison de tout ça. Garage est censé être performant, mais bon, on est sur un processeur ARM assez poussif quand même, qui doit déjà gérer le transfert réseau, donc on est pas à l’abri que ça soit un problème purement chez moi.
En tout cas, pour un jeune logiciel, la qualité de la documentation et l’implémentation Windows déjà opérationnelle (même si encore un peu buggée chez certains, en lien notamment avec les différences slash/antislash à cause de Windows), en bonus une interface web pour parcourir les backups, il m’a très agréablement surpris. On ne peut souhaiter que ça mature comme il faut et que l’entreprise trouve son équilibre (la stabilité financière et l’open-source, hein…). Et moi que je regarde d’un peu plus près le statut du live la prochaine fois (ou que je configure l’enregistrement en plus du stream)…
Salut à tous ! On en parlait il y a peu sur vBlog, et c’est désormais officiel : une version bêta du plugin XCP-ng pour Veeam est disponible sur le forum R&D de Veeam ! Une excellente nouvelle après l’annonce, en mai 2024, du support de Proxmox par Veeam. En à peine plus d’un an, XCP-ng rejoint la fête et confirme son statut d’alternative potentielle et sérieuse dans l’écosystème de la virtualisation.
UNRAID c’est bien. Mais UNRAID sauvegardé c’est mieux. Enfin… à moins de refaire mon boulet… Et je ne parle pas des données telles que photos, films, musiques, etc, au moins sécurisées par la parité, mais bien de celles liées à l’OS (configuration globale, plugins…) ou aux Dockers eux-mêmes (images, configs…).
Si on peut installer X outils de sauvegarde indépendants (Kopia, Duplicati, Restic…), je pense qu’on est surtout très nombreux à utiliser le plugin Appdata Backup (qui ne devrait plus être maintenu, mais) qui fait le boulot avec du backup incrémental des données des Dockers et du /boot. Surtout qu’on peut lui ajouter des scripts avant/après chaque étape, histoire de personnaliser à fond tout ça.
Cependant, 2 précautions valent mieux qu’une, et l’outil UNRAID Config Guardian de stephondoestech permet de créer des sauvegardes récurrentes (cron en variable du Docker) des configurations d’UNRAID et des Dockers (qui tournent, pas les stoppés pour l’instant). De surcroît avec un script de restauration d’urgence pour tout remettre en place simplement et rapidement. Utilisé en parallèle du plugin Appdata Backup, cet outil se concentre sur l’OS même, sa configuration, ses plugins et sort un gros compose.yml pour remettre en branle tous les Dockers.
« UCG » permet de lister les containers et leurs volumes/variables
et d’en faire une sauvegarde via un chemin local. Ce dernier pouvant être un disque dur, une clé USB, un montage de NAS/FTP, un montage rClone…
Et ce ne sont que des configurations, ça ne prend donc pas de place à stocker.
Avant-hier matin, mercredi 13 août, suite à une mise à jour vers Ubuntu 22 de mon serveur, j'ai eu la mauvaise surprise de ne pas le voir redémarrer...
Subissant en plus un rhume carabiné, je me suis un peu décomposé en voyant mes systèmes de supervision m'alerter lorsque la vingtaine …
Ce qu'oublie Korben (volontairement ou non), c'est la taxe sur la copie privée qui permet aux consommateurs de réaliser ces téléchargements contrairement aux IA qui pompent tout sans vergogne.
Je ne serais pas étonné d'ailleurs que le texte de cet article ait été rédigé par une de ces IA tant le propos est creux et ressemblant à celui des industriels qui inondent les médias.
— Permalink
Connexion
