Si on veut minimiser le nombre de coups en moyenne (i.e. sur un grand nombre de parties) sans compter sur le hasard, il me semble qu'il ne faut pas exclure de jouer des coups incompatibles mais qui apportent plus d'information. J'ai programmé ce jeu il y a quelques décennies (avec un algorithme de parcours d'arbre classique et min-max) et il me semble bien que le programme sortait aussi des coups incompatibles avec la connaissance disponible au tour concerné.
En fait, les deux modes proposés (BTRFS et RSYNC) correspondent à des fonctionnalités différentes* : la gestion de snapshot btrfs et une fonctionnalité plus classique de sauvegarde basée sur rsync. Quand Timeshift est en mode BTRFS, il montre les différents sous-volumes btrfs existants et permet de choisir celui pour lequel on veut faire un snapshot. Quand il est en mode RSYNC, il propose comme tout logiciel de sauvegarde le choix des dossiers à sauvegarder. Pour ma part, je ne l'utilise qu'en mode BTRFS pour faire des snapshots du sous-volume btrfs "/" et j'utilise un autre logiciel (borg) pour la sauvegarde de mes données.
* Un snapshot n'est pas vraiment une sauvegarde. Certes il fige une image du passé mais sur le même disque…
L'explication "serait" que certains environnements graphiques (Gnome, notamment) sont plus sujets à avoir des problèmes si la mise à jour est effectuée en mode graphique.
Il est même conseillé de faire pacman -Syu dans un terminal hors environnement graphique (i.e. accessible via ctrl-alt F3 par exemple).
Pour moi, cette phrase est mal formulée ou bien est un non-sens. Elle laisse entendre qu'avant d'utiliser Manjaro il faudrait utiliser Arch. D'abord "utiliser" n'est pas le bon terme car ce qui différencie les deux, c'est surtout l'installation. Si on a été au bout de celle de Arch (configuration comprise), je ne vois plus trop l'intérêt de passer à Manjaro.
[…] le fait qu'elle [Manjaro] utilise ses propres dépôts m'a rapidement fait fuir. On perd tout l'intérêt de la rolling release et c'est pas aussi à jour que sous Arch.
Ce sont ses propres dépôts mais ils s'agit pour l'essentiel des mêmes paquets que sous Arch mais décalés de 2 à 4 semaines. Par ailleurs, l'intérêt d'une rolling release n'est pas uniquement d'avoir des mises à jour immédiates mais d'éviter les changements de version à la Ubuntu et consorts. En ce qui me concerne, attendre 2 à 4 semaines la dernière version du noyau ou de LO ne me traumatise pas plus que ça et en 2 ans je n'ai eu qu'une seule fois un souci de mise à jour (facilement réglé en revenant au snapshot précédent).
Mettre les mains dans le cambouis d'une distribution Linux c'est très formateur mais c'est comme la mécanique auto, ça n'intéresse pas tout le monde.
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.
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.
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.
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).
Posté par mahikeulbody .
En réponse au journal Sauvegarde de données.
Évalué à 3.
Dernière modification le 10 novembre 2020 à 21:36.
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).
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).
# coups incompatibles
Posté par mahikeulbody . En réponse au journal Yes Master. Évalué à 2.
Si on veut minimiser le nombre de coups en moyenne (i.e. sur un grand nombre de parties) sans compter sur le hasard, il me semble qu'il ne faut pas exclure de jouer des coups incompatibles mais qui apportent plus d'information. J'ai programmé ce jeu il y a quelques décennies (avec un algorithme de parcours d'arbre classique et min-max) et il me semble bien que le programme sortait aussi des coups incompatibles avec la connaissance disponible au tour concerné.
[^] # Re: I use Arch BTW
Posté par mahikeulbody . En réponse à la dépêche Bien débuter avec Manjaro Linux. Évalué à 4.
Idem pour Octopi : il faut installer un paquet pour avoir le support de AUR.
[^] # Re: snapshot
Posté par mahikeulbody . En réponse au message Besoin de quelques éclaircissements sur btrfs. Évalué à 4.
En fait, les deux modes proposés (BTRFS et RSYNC) correspondent à des fonctionnalités différentes* : la gestion de snapshot btrfs et une fonctionnalité plus classique de sauvegarde basée sur rsync. Quand Timeshift est en mode BTRFS, il montre les différents sous-volumes btrfs existants et permet de choisir celui pour lequel on veut faire un snapshot. Quand il est en mode RSYNC, il propose comme tout logiciel de sauvegarde le choix des dossiers à sauvegarder. Pour ma part, je ne l'utilise qu'en mode BTRFS pour faire des snapshots du sous-volume btrfs "/" et j'utilise un autre logiciel (borg) pour la sauvegarde de mes données.
* Un snapshot n'est pas vraiment une sauvegarde. Certes il fige une image du passé mais sur le même disque…
[^] # Re: snapshot
Posté par mahikeulbody . En réponse au message Besoin de quelques éclaircissements sur btrfs. Évalué à 3.
Je n'ai pas d'onglet 'Filters'. As-tu bien sélectionné le type BTRFS (et non pas RSYNC) pour tes instantanés ?
[^] # Re: Certains renseignements m'auraient bien servi
Posté par mahikeulbody . En réponse à la dépêche Bien débuter avec Manjaro Linux. Évalué à 4. Dernière modification le 21 novembre 2020 à 11:20.
L'explication "serait" que certains environnements graphiques (Gnome, notamment) sont plus sujets à avoir des problèmes si la mise à jour est effectuée en mode graphique.
Il est même conseillé de faire pacman -Syu dans un terminal hors environnement graphique (i.e. accessible via ctrl-alt F3 par exemple).
[^] # Re: pour se prémunir d'éventuels problèmes lors d'une mise à jour
Posté par mahikeulbody . En réponse à la dépêche Bien débuter avec Manjaro Linux. Évalué à 4.
Pourquoi pas mais je n'en sais guère plus que ce j'ai dit ici. Je peux néanmoins relire la partie correspondante.
[^] # Re: pour se prémunir d'éventuels problèmes lors d'une mise à jour
Posté par mahikeulbody . En réponse à la dépêche Bien débuter avec Manjaro Linux. Évalué à 3.
Je ne connaissais pas, merci.
[^] # Re: Bien débuter avec Manjaro
Posté par mahikeulbody . En réponse à la dépêche Bien débuter avec Manjaro Linux. Évalué à 6. Dernière modification le 19 novembre 2020 à 19:05.
Pour moi, cette phrase est mal formulée ou bien est un non-sens. Elle laisse entendre qu'avant d'utiliser Manjaro il faudrait utiliser Arch. D'abord "utiliser" n'est pas le bon terme car ce qui différencie les deux, c'est surtout l'installation. Si on a été au bout de celle de Arch (configuration comprise), je ne vois plus trop l'intérêt de passer à Manjaro.
Ce sont ses propres dépôts mais ils s'agit pour l'essentiel des mêmes paquets que sous Arch mais décalés de 2 à 4 semaines. Par ailleurs, l'intérêt d'une rolling release n'est pas uniquement d'avoir des mises à jour immédiates mais d'éviter les changements de version à la Ubuntu et consorts. En ce qui me concerne, attendre 2 à 4 semaines la dernière version du noyau ou de LO ne me traumatise pas plus que ça et en 2 ans je n'ai eu qu'une seule fois un souci de mise à jour (facilement réglé en revenant au snapshot précédent).
Mettre les mains dans le cambouis d'une distribution Linux c'est très formateur mais c'est comme la mécanique auto, ça n'intéresse pas tout le monde.
Ah mince, je suis tombé en plein dans le troll !
[^] # Re: Certains renseignements m'auraient bien servi
Posté par mahikeulbody . En réponse à la dépêche Bien débuter avec Manjaro Linux. Évalué à 3.
Il l'est dans certaines distributions (Fedora, OpenSuse notamment).
[^] # Re: pour se prémunir d'éventuels problèmes lors d'une mise à jour
Posté par mahikeulbody . En réponse à la dépêche Bien débuter avec Manjaro Linux. Évalué à 5.
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.
[^] # Re: Certains renseignements m'auraient bien servi
Posté par mahikeulbody . En réponse à la dépêche Bien débuter avec Manjaro Linux. Évalué à 5.
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.
[^] # Re: du materiel ?
Posté par mahikeulbody . En réponse au message Mon pc a des phases rapide et d'autre très lente. Évalué à 6.
et font souvent de l'indexation par défaut.
# pour se prémunir d'éventuels problèmes lors d'une mise à jour
Posté par mahikeulbody . En réponse à la dépêche Bien débuter avec Manjaro Linux. Évalué à 5. Dernière modification le 19 novembre 2020 à 15:56.
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.
[^] # Re: snapshot
Posté par mahikeulbody . En réponse au message Besoin de quelques éclaircissements sur btrfs. Évalué à 2.
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.
# snapshot
Posté par mahikeulbody . En réponse au message Besoin de quelques éclaircissements sur btrfs. Évalué à 2. Dernière modification le 18 novembre 2020 à 21:06.
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.
[^] # Re: Pourquoi si compliqué ?
Posté par mahikeulbody . En réponse au journal Sauvegarde de données. Évalué à 2.
Faux, borg fait de la compression.
[^] # Re: Snapraid
Posté par mahikeulbody . En réponse au journal Sauvegarde de données. Évalué à 2.
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.
[^] # Re: Scénarii ?
Posté par mahikeulbody . En réponse au lien scénarii de propagation du virus sars-2. Évalué à 2. Dernière modification le 10 novembre 2020 à 21:49.
Ok, merci !
[^] # Re: Sauvegarde Paranoïa
Posté par mahikeulbody . En réponse au journal Sauvegarde de données. Évalué à 4.
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).
[^] # Re: Pourquoi si compliqué ?
Posté par mahikeulbody . En réponse au journal Sauvegarde de données. Évalué à 2.
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.
[^] # Re: Pourquoi si compliqué ?
Posté par mahikeulbody . En réponse au journal Sauvegarde de données. Évalué à 3. Dernière modification le 10 novembre 2020 à 21:36.
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.
[^] # Re: Pourquoi si compliqué ?
Posté par mahikeulbody . En réponse au journal Sauvegarde de données. Évalué à 2.
La déduplication de borg fonctionne aussi par bloc (taille paramétrable).
[^] # Re: Pourquoi si compliqué ?
Posté par mahikeulbody . En réponse au journal Sauvegarde de données. Évalué à 7.
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).
# résumé
Posté par mahikeulbody . En réponse au lien scénarii de propagation du virus sars-2. Évalué à 3.
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.
[^] # Re: [HS] et comment héberges-tu tes mails ?
Posté par mahikeulbody . En réponse au journal Les adresses mail personnelles et les comptes en lignes. Évalué à 2.
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).