mahikeulbody a écrit 1577 commentaires

Il y a je crois un utilitaire btrfs pour ça. Après il faudra vérifier si le fait de créer une entrée dans grup pour les snapshots existants de "/" est mis en place à l'installation du système ou bien si le FS de "/" est re-testé à chaque mise à jour (à moins que ce ne soit Timeshift lui-même qui mette à jour les entrées dans grub ?). J'avoue ne pas avoir creusé car j'ai installé Manjaro directement avec btrfs.

btrfs donne aussi une solution pour le dimensionnement de "/" : il suffit de choisir aussi btrfs pour "/home". Dans ce cas (et sous réserve que les deux points de montage soient sur le même disque), l'installation va créer deux sous-volumes qui se comportent comme deux partitions mais sans dimensionnement prédéfini entre les deux.

et font souvent de l'indexation par défaut.

Pour se prémunir d'éventuels problèmes lors d'une mise à jour, il est, comme indiqué dans le journal, conseillé de consulter le forum (https://forum.manjaro.org/c/announcements/stable-updates/12). Ceci étant dit, j'utilise pour ma part la solution suivante : choisir btrfs comme FS pour "/" à l'installation.

Avant chaque mise à jour, faire un snapshot de "/" avec Timeshift (et supprimer le plus ancien pour ne pas en avoir un trop grand nombre, personnellement je n'en garde que trois). Faire la mise à jour. Dans le cas d'un "/" en btrfs, Manjaro va automatiquement créer une entrée dans le menu de grub (en fait, une entrée par snapshot existant sur "/").

Comme ça, plus de stress et on peut profiter sans souci des avantages d'une rolling release, pour ma part en saveur KDE. Ceci dit, je crois n'avoir eu qu'une fois en deux ans un souci nécessitant d'utiliser un précédent snapshot pour ré-démarrer.

Utiliser les snapshots comme points de restauration de / ne nécessite pas de les exporter, il n'y a donc rien de contradictoire.

btrfs, tout comme zfs, a deux autres avantages par rapport à un FS classique qui sont autant de raisons, pour moi, de vouloir l'utiliser : détection auto (et même correction auto si raid) des corruptions de donnée, raid 1 très souple (différent du raid 1 classique).

Pour revenir sur la sauvegarde, je n'ai pas creusé les possibilités offertes par send snapshot, notamment pour faire de l'incrémental, car j'utilisais déjà borg et j'en suis satisfait. Je ne peux donc pas en parler.

Je n'utilise les snapshots btrfs que sur /. Avant chaque mise à jour du système, je fais un snapshot de / avec Timeshift, celui-ci est automatiquement rajouté au menu de démarrage de grub par Manjaro, ce qui me permet d'être à peu près sûr de redémarrer s'il y a un gros problème sur la mise à jour.

En revanche, je ne les utilise pas pour les sauvegardes de /home et autres partitions de données mais tout est quand même sous btrfs dont l'intérêt ne réside pas que dans la possibilité de faire des snapshots.

Il regroupe les fonctionnalités que les deux précédents ne font pas : compression et stockage type S3.

Faux, borg fait de la compression.

Un peu étonné de pas voir Snapraid mentionné.

Peut-être parce que le sujet du journal est la sauvegarde et qu'un raid, aussi résilient soit-il, ne protège pas contre les pertes de données dues à d'autres causes que les problèmes disque. Seule une sauvegarde avec historisation (et si possible deux destinations, une locale et une externe) peut répondre à ce problème. Si le raid en question assure une détection et une correction des erreurs disque, c'est très bien mais ça ne remplace pas une sauvegarde pour autant.

Ok, merci !

Le RAID me parait inutile et coûteux. Il répond selon moi à des questions de disponibilité, pas de sauvegarde.

Pas que. Par exemple le RAID 1 sous BTRFS permet la détection et la correction automatique d'une corruption. Je m'en sers pour ça, pas spécialement pour la disponibilité.

Ca permet d'éviter (autant que possible) qu'une corruption ne se propage le long de l'historique jusqu'à ce qu'il n'y ait plus aucune version du fichier non corrompue. De ce point de vue, ça répond à une problématique de la sauvegarde (mais ça ne la remplace absolument pas, on est bien d'accord).

C'est aussi un FS qui évolue donc ce qu'il était il y a quelques années ne reflète pas/plus ce qu'il est aujourd'hui.

Normalement un scrub périodique n'est pas utile. En raid 1, les erreurs sont automatiquement détectées et corrigées lors d'un accès en lecture de la donnée concernée, donc lors de la sauvegarde par exemple.

Il est bien plus économique en charge système de regarder les logs btrfs que de lancer un scrub tous les jours.

Par contre c'est vrai que si tu ne changes que légèrement un fichier, seul le bloc impacté est mis à jour dans le snapshot (vu que le snapshot opère au nivau du bloc si je me souviens bien).

La déduplication de borg fonctionne aussi par bloc (taille paramétrable).

Il gère également la déduplication.

Tout ce système pour prévenir de la défaillance d'un disque, pourquoi pas mais ça ne protège pas contre les erreurs telles qu'une suppression de fichiers par inadvertance, un bit rot, ou une corruption de données dues à un bug logiciel : il faut absolument pouvoir remonter dans le temps.

Pour ma part, j'utilise btrfs en raid 1 pour lutter contre un éventuel bit rot, borg pour la sauvegarde sur un autre disque local, et rclone pour une copie extérieure synchronisée de la sauvegarde borg (cloud wasabi).

Les milieux intérieurs sont plus dangereux, mais il est possible de diminuer les risques si l’on se donne tous les moyens possibles pour combattre la propagation par aérosols. Nous allons voir les probabilités d’infection dans trois scénarios quotidiens en fonction de la ventilation, des masques et du temps d’exposition.

Pour pallier à ça je synchronise de temps en temps mes g-mails avec une base locale via Thunderbird (utilisé ici uniquement pour cette fonction de "backup", pas comme client mail).

Ça te démarque certainement mais tu n'es pas seul : je suis dans le même cas que toi pour mes deux domaines (et avec Gandi comme registrar).

J'utilise deux domaines également depuis plus de 15 ans et je n'ai encore jamais rencontré ce cas de figure.

La nouvelle version de TousAntiStopCovid mémorise maintenant elle aussi les champs invariants (si on le souhaite). Elle utilise aussi localStorage ?

NB. L'appli TousAntiStopCovid peut servir à générer des attestations même si on ne souhaite pas l'activer.

Benalla n'est qu'un exemple. Le fait qu'il soit peut-être mal choisi dans le cadre de la loi en question ne change pas le problème. Mais y a t-il un problème ? Il me semble que si une vidéo montre des policiers en train de commettre un acte répréhensible dans le cadre de leur fonction, peu importe que leurs visages soient floutés, elle aura quand même un impact une fois diffusée et devra donner lieu, sous réserve que la presse reprenne l'événement, à une enquête de l'IGS qui aura les moyens d'identifier ces policiers (si elle le veut) en se procurant par exemple la vidéo originale. Que l'enquête de l'IGS soit biaisée ou non est un autre sujet qui ne dépend pas de cette nouvelle loi.

Une loi qui interdit tout court de filmer une intervention de la police me paraît autrement plus problématique.

C'est plutôt pour Google qu'elle ne s'est pas bien passé.

https://www.lesnumeriques.com/vie-du-net/ecoutant-la-cnil-cedric-o-ne-veut-finalement-plus-confier-nos-donnees-de-sante-a-microsoft-n155493.html

Il existe la commande btrfs-convert mais pour ma part j'ai préféré re-formater, ça fait moins peur.

Ça a pourtant fait l'objet de pas mal d'articles y compris dans la presse généraliste :

https://www.lebigdata.fr/smartphones-android-failles-snapdragon

elles sont même stockées hors de portée de l'OS dans une enclave sécurisée du processeur.

Hors d'atteinte des failles récemment révélées sur ces processeurs ?