Journal Timeshift, l'outil de sauvegarde de Linux Mint 19 : oui mais attention

Posté par  (site web personnel, Mastodon) .
Étiquettes :
23
15
nov.
2018

Linux Mint 19 pousse fortement à l'utilisation de son outil Timeshift, qui fait de la sauvegarde incrémentale, par exemple en l'intégrant avec le système de mises à jour.

Timeshift fait ses sauvegardes avec rsync ou Btrfs. En soi, c'est une excellente idée et très pratique, notamment pour le public cible de Linux Mint (les débutants et des gens qui ne veulent pas s'intéresser particulièrement au système), qui a encore moins que les autres le réflexe de faire des sauvegardes. Ça c'est pour le « oui ».

Mais « attention » quand on commence à avoir une utilisation un peu plus poussée de l'ordinateur. Typiquement, vous avez beaucoup de petits fichiers (si vous faites du développement c'est probablement le cas) mais que vous n'avez pas de SSD, les sauvegardes vont mettre des plombes à s'effectuer – c'est normal, c'est vos données et votre matériel qui ne laissent pas le choix.

Sauf que Timeshift ne cherche pas à savoir si vous utilisez ou pas l'ordinateur pendant qu'il tourne. Donc, le « attention », c'est que vous pouvez vous retrouver à avoir un ordinateur inutilisable pour cause de sauvegarde en cours, et qu'en plus il n'y a aucune indication qu'une telle sauvegarde est lancée (sauf à aller voir les programmes en cours). Pour un système grand public, c'est un peu dommage.

Ce texte est placé sous licence CC-0 4.0

  • # Retour d'expérience sauvegarde rsync

    Posté par  . Évalué à 2.

    Je fais tous les jours à 21h une sauvegarde rsync depuis mon disque principal (2 disques en RAID miroir) vers un autre disque interne. Ce ne sont pas des SSD. Et ma machine date pas d'hier.

    Ce n'est pas une sauvegarde incrémentale, juste une synchro.

    J'ai jamais constaté d'impact. Mais peut-être que je fais jamais de choses coûteuses à ce moment-là (à part la MAO, je fais rien qui coûte, et je dois faire ça plus tard, probablement…).

    • [^] # Re: Retour d'expérience sauvegarde rsync

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Tu as déjà un disque source et un disque destination différents, ce qui n'est pas mon cas sur ce PC. D'autre part, ce qui compte le plus c'est probablement le nombre de fichiers à analyser puis sauvegarder.

      La connaissance libre : https://zestedesavoir.com

      • [^] # Re: Retour d'expérience sauvegarde rsync

        Posté par  . Évalué à 5.

        Je ne comprends pas vraiment l'intérêt de faire une sauvegarde sur le même disque.
        Pour récupérer un vieux fichier supprimé accidentellement ?

        • [^] # Re: Retour d'expérience sauvegarde rsync

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          Pour revenir facilement à l'état précédent en cas de problème à l'installation d'un paquet. C'est l'utilisation par défaut de Timeshift dans Mint 19.

          La connaissance libre : https://zestedesavoir.com

          • [^] # Re: Retour d'expérience sauvegarde rsync

            Posté par  . Évalué à 2.

            SpaceFox parle de sauvegarde incrémentale, donc oui, je pense que c'est pour l'historique.

            Pour l'historique des installations/désinstallations, j'utilise etckeeper qui versionne /etc avec git. Et apt-clone pour conserver la liste des paquets installés. J'ai jamais utilisé apt-clone pour réparer, mais la sauvegarde de /etc c'est vraiment pas mal. En tout cas pour du serveur et pour un utilisateur technique.

          • [^] # Re: Retour d'expérience sauvegarde rsync

            Posté par  (Mastodon) . Évalué à 6.

            C'est un peu vilain d'appeler ça une sauvegarde quand même.

    • [^] # Re: Retour d'expérience sauvegarde rsync

      Posté par  . Évalué à 2.

      Je faisais ça aussi, il y a quelques années… Et c'est l'alim de mon poste qui a cramée, entrainant les 2 disques durs avec elle en même temps !!!! 3 ans de photos partis en fumée, littéralement !

      Depuis, les sauvegardes, c'est sur des disques externes avec leurs propres alimentations. (et sur un kimsufi en plus, mais là, c'est plus cher…)

      • [^] # Re: Retour d'expérience sauvegarde rsync

        Posté par  . Évalué à 2.

        J'ai aussi un disque dur externe USB sur lequel je fais une sauvegarde manuelle hebdomadaire. Je le conserve au bureau.

        Il faut pas que la maison brûle le soir où je le ramène pour la sauvegarde…

        • [^] # Re: Retour d'expérience sauvegarde rsync

          Posté par  . Évalué à 2.

          Il faut pas que la maison brûle le soir où je le ramène pour la sauvegarde…

          C'est pour ça qu'il te faut au moins 2 disques de sauvegarde…

          ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • # ionice

    Posté par  . Évalué à 3. Dernière modification le 15 novembre 2018 à 11:00.

    Il y aurait pas moyen dans Mint d'utiliser ionice pour minimiser la priorité de la sauvegarde et pas plomber les autres tâches ?

    • [^] # Re: ionice

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Probablement, mais ça nécessite de mettre les mains dans le cambouis, ce qui n'est pas du tout dans la philosophie de la distribution.

      La connaissance libre : https://zestedesavoir.com

      • [^] # Re: ionice

        Posté par  . Évalué à 3.

        Je voulais dire que les devs pourraient le faire, pas Mme Michu.

  • # Pour un système grand public, c'est un peu dommage.

    Posté par  . Évalué à -1. Dernière modification le 15 novembre 2018 à 11:36.

    Je te rassure, mes connaissances, de simple utilisateurs, ne savent pas ce qu'est une sauvegarde incrementale ou comment utiliser TimeMachine d'OSX voire Backup and restore de MS.

    Ce n'est pas pour dédouaner Mint, mais dans les 3 cas, si on ne sensibilise ou n'informe pas l'utilisateur, il passera à côt, aussi clickesque que soit l'OS.
    Un backup, ça reste un concept technique !

    Donc évitons de remettre tout de suite en cause la distribution ou "linux" pour un truc corrigeable vu la relative proximité avec l'équipe.

  • # sauvegardes et points de restauration

    Posté par  . Évalué à 3. Dernière modification le 15 novembre 2018 à 12:55.

    Il y a deux fonctions assez différentes dans Timeshift :
    - un outil basé sur rsync
    - un outil basé sur btrfs

    Dans le premier cas (rsync), c'est un outil de sauvegarde type "hardlink" tel que Back-in-Time (il faut bien sûr choisir un autre disque que la source). J'ignore ce qu'il vaut dans ce rôle mais il est basé sur rsync donc ça devrait être efficace.

    Dans le deuxième cas (btrfs), ce n'est pas un outil de sauvegarde. C'est un outil de retour en arrière, un peu comme les points de restauration de Windows. En effet, la photo (i.e. snapshot) ne peut s'effectuer que sur la partition source. Par défaut, Timeshift exclut le sous-volume @/home ; il ne prend que @/. De plus, il met à jour le grub quand on veut restaurer une ancienne photo de @/.

    Pour moi, mettre ces deux fonctions dans le même logiciel n'a pas de sens.

    • [^] # Re: sauvegardes et points de restauration

      Posté par  (site web personnel) . Évalué à 3.

      Je ne connais pas BTRFS réellement mais comme c'est plus ou moins les même fonctionnalité que ZFS, je ne vois pas ce qui l'empêche de transformer un snapshot en backup.

      Si tu fais un snapshot : c'est comme utiliser la fonction rsync sur le même disque (sauf que c'est plus rapide et plus efficace). Si tu veux envoyer ton snapshot sur un autre disque où un autre PC pour la sauvegarde, dans ce cas tu as un fonctionnement similaire à rsync à distance (sauf que c'est plus rapide et plus efficace).

      Un peu de lecture sur btrfs send/receive (zfs fait exactement pareil avec zfs send/receive) :

      https://btrfs.wiki.kernel.org/index.php/Incremental_Backup

      • [^] # Re: sauvegardes et points de restauration

        Posté par  . Évalué à 3.

        J'ai dit que ce n'était pas un outil de sauvegarde en mode btrfs.

        "ce" est le sujet de ce fil : Timeshift. Or Timeshift ne propose pas d'envoi/réception de snapshot. Timeshift en mode btrfs est clairement un outil pour restaurer le système à un état antérieur. Il propose accessoirement (et pas par défaut) d'embarquer @/home dans le snapshot.

  • # perf de Timeshift en mode rsync

    Posté par  . Évalué à 2.

    J'utilise Backintime (également basé sur rsync) sur le PC de ma compagne. Il s'active toutes les heures et c'est transparent. Mais comme la performance à la base est celle de rsync lui-même je vois deux raisons possibles à tes mauvaises perfs :

    • le fait que tes sauvegardes s'effectuent sur le même disque (qui doit donc faire à la fois des lectures et des écritures)
    • un paramétrage "maladroit" de rsync par Timeshift (par exemple l'option -c qui peut être pénalisante en cpu)

    Ceci dit, une sauvegarde sur le même disque c'est pas une sauvegarde, c'est juste la possibilité de revenir en arrière dans le temps. Une sauvegarde c'est aussi la possibilité de remédier à un problème disque (inéluctable tôt ou tard).

  • # Utilisez déjà-dup.

    Posté par  . Évalué à 1.

    Laissez tomber les bricoles maisons imposées par les distros.
    Cela vous enferme dans le carcan de la dite distro.

    Qui utilise BTRFS en FS par défaut ?
    Le snapshot n'est pas un backup.

    Considérant que seul /home/$user est à backuper sur votre desktop, le reste de vos data est "sécurisé" sur votre NAS, lui même backupé par divers mécanisme (copie Disk USB …)

    Avec déja-dup (surcouche graphique à duplicity).
    - Fonctionne sur tout les OS (déjà backupé depuis MINT Cinnamon et restau depuis Manjaro KDE)
    - Ultra simple d'utilisation
    - Permet le chiffrement des backups
    - Permet de backup dans diverses connecteur "cloud" ou sur des points de montage NFS ou disque USB évidemment.
    - Permet d'exclure des repertoires et des fichiers (ex Vidéo trop volumineux, ou .cache firefox, .config gnome ..)
    - Sauvegarde planifiable en fond.

    En cas de crash ou d'erreur après une update sur un OS un peu léger : Formatage complet sans état d'âme, reinstallation fresh depuis la dernière ISO en date (peu importe la distro tiens j'ai envie de tester la dernière KDE Neon …) apt get install deja-dup.
    Indiquer l'endroit des backup à déjà dup, restaurer depuis la date voulue.

    • [^] # Re: Utilisez déjà-dup.

      Posté par  . Évalué à 2. Dernière modification le 15 novembre 2018 à 15:53.

      Je n'utilise pas Mint mais je l'ai déjà installé "pour voir". btrfs n'y est pas proposé par défaut et encore moins "imposé".

      Si néanmoins on veut quand même btrfs (il y a plein de raisons valables pour ça), on peut alors utiliser Timeshift en mode btrfs pour avoir la gestion de points de restauration système (/, pas /home) via des snapshots et la maj de grub en conséquence. C'est quand même plus simple et autrement plus rapide que passer par la restauration d'une sauvegarde du système ou sa réinstallation.

      Pour les sauvegardes elles-mêmes, Timeshift me paraît assez limité (même si sa fondation est solide : rsync) mais je ne vois pas en quoi il te verrouille sur Mint. Ensuite, libre à toi de mettre en avant déja-dup (un peu lourdement quand même) mais il y a plein d'autres solutions, parfois plus performantes. Ce n'est juste pas le sujet ici.

    • [^] # Re: Utilisez déjà-dup.

      Posté par  . Évalué à 4. Dernière modification le 15 novembre 2018 à 17:38.

      J'ai longtemps utilisé déjà-dup et j'en ai été très satisfait. Mais il a un gros défaut : il est obligé de faire un full backup de temps en temps pour avoir un point de restauration si l'un des backups incrémentaux est corrompu.

      C'est un gros inconvénient pour moi qui ai un disque de 500GO avec plein de photos et vidéos personnelles sur un ordinateur portable connecté en Wifi à mon NAS qui reçoit les backups via Samba. Il faut toute une nuit pour faire un full backup (contre 1 heure via le LAN et un cable réseau).

      Je suis donc passé à Restic qui est aussi incrémental mais qui utilise de la dé-duplication au lieu de delta : non seulement ça lui permet de se passer de point de full backup intermédiaire, mais ça lui permet également de ne pas sauvegarder 2 fois des morceaux de fichiers identiques.

      Cerise sur le gâteau Restic fournit un serveur (tout a fait optionnel) que j'ai installé sur mon NAS et qui me permet de faire des backups via http et me passer de Samba.

      Restic est également cross-platform (codé en Go), Linux, Mac, Windows.

      Son seul inconvénient est qu'il n'existe pas d'interface graphique à Restic pour le moment à ma connaissance. J'ai tout configuré à la main avec un service systemd pour mes users.

      • [^] # Re: Utilisez déjà-dup.

        Posté par  . Évalué à 5.

        Dans le même genre il y a borg, restic ou bup (qui lui a des front-end, kup par exemple).

        La déduplication est souvent vue comme le moyen de se passer de sauvegardes incrémentales (chaque sauvegarde est vue comme complète) mais ce n'est pas là qu'elle se distingue le plus. En effet, une sauvegarde type BackinTime avec des hard links fait la même chose (à la maille fichier). Pour moi, l'apport qui distingue la dé-duplication type restic/borg/bup est qu'elle s'effectue à la maille bloc de données dans les fichiers =>

        1) Tagger une photo n'induit pas de doubler l'espace pris par deux versions de la photo alors que seuls quelques ko ont été modifiés (assez efficace avec borg ou bup, beaucoup moins avec restic qui ne permet pas de paramétrer la taille des blocs).

        2) Déplacer, renommer des arborescences ou des fichiers (même par milliers) n'a aucun impact sur la taille totale des sauvegardes (quel confort !).

        NB. Comme toute sauvegarde de type déduplication à la maille fichier (basée sur rsync et des hardlinks)) ou de type déduplication "bloc", il faut impérativement un double ailleurs (dans le cloud par exemple) car un même bloc de données peut être partagé entre toutes les versions d'un fichier ou plusieurs fichiers). Si le secteur supportant ce bloc devient corrompu on a perdu le fichier.

        • [^] # Re: Utilisez déjà-dup.

          Posté par  . Évalué à 1.

          NB. Comme toute sauvegarde de type déduplication à la maille fichier (basée sur rsync et des >hardlinks)) ou de type déduplication "bloc", il faut impérativement un double ailleurs (dans le >cloud par exemple) car un même bloc de données peut être partagé entre toutes les versions d'un >fichier ou plusieurs fichiers). Si le secteur supportant ce bloc devient corrompu on a perdu le >fichier.

          C'est un point important en effet. Avec restic (j'imagine que c'est pareil pour les autres) je lance régulièrement restic check pour vérifier l'intégrité de mes sauvegardes. J'ai également une copie complète de ma sauvegarde sur un disque usb en dehors de chez moi (cold backup). Je synchronise ce disque environ 2 fois par an.

          Restic a l'avantage d'être codé en Go ce qui facilite grandement son déploiement dans des environnements hétérogènes. En revanche, comme tu l'as souligné, la taille des blocs n'est pas paramétrable. En pratique une sauvegarde Restic prend plus de place qu'une sauvegarde Deja-Dup, si comme moi vous modifiez assez peu les fichiers existants (photos et vidéos).

          • [^] # Re: Utilisez déjà-dup.

            Posté par  . Évalué à 1.

            Avec restic (j'imagine que c'est pareil pour les autres) je lance régulièrement restic check

            Oui, il y a aussi un borg check (mais si on veut qu'il contrôle tous les blocs d'un repo de 500 Go ça peut être très long, surtout s'ils sont chiffrés).

            J'utilise une autre solution : btrfs en raid 1 pour les données source et le dépôt des archives (j'aurais bien choisi plutôt zfs mais ce n'est pas out of the box sur linux et je n'ai pas voulu me compliquer la vie). Le raid 1, ce n'est pas pour la disponibilité mais pour la correction automatique des éventuelles erreurs (capacité de btrfs et zfs, chose qu'un raid 1 logiciel classique ne peut pas faire).

        • [^] # Re: Utilisez déjà-dup.

          Posté par  (site web personnel) . Évalué à 2.

          Bonjour,

          je plussoie l'utilisation de borg

          principalement j'ai 2 Linux Mint à la maison et j'ai paramétré borg comme sauvegarde (ok via ssh sur un nas)
          la sauvegarde ne dure pas longtemps et permet la récupération de fichiers juste au cas ou

          l'espace pris n'est pas super important et ainsi j'ai un sauvegarde tout les jours plus la conservation
          d'une sauvegarde par semaine et par mois

          Ex :
          borg prune -v --list --keep-daily=7 --keep-weekly=4 --keep-monthly=6

          Et vous pouvez exclure le .cache du $HOME pour gagner du temps

          le scripts est pas super dur a faire non plus …

    • [^] # Re: Utilisez déjà-dup.

      Posté par  (site web personnel) . Évalué à 2.

      J'utilise deja-dup avec S3 pour mes sauvegardes et ça marche super bien. J'ai déjà restauré sans soucis. De plus automatiquement il valide régulièrement que les sauvegardes peuvent être récupérées, le truc que personne ne fait jamais !

  • # CC0 4.0, euh 1.0

    Posté par  (site web personnel) . Évalué à 4.

    Ce texte est placé sous licence CC-0 4.0

    Ça n’existe pas… =)

    La plus récente CC0 (et aussi la première) est la 1.0, elle n’a pas encore reçu de mise à jour, et j’imagine que ça ne fait pas beaucoup sens. ;-)

    C’est vrai que la confusion est facile puisque les autres licences ont reçu plusieurs mises à jour et en sont déjà à la 4.0, mais en même temps elles sont plus anciennes et sont beaucoup plus complexes dans leur rédaction, déjà que 1 300 mots pour le quasi domaine-publique de la CC0, ça fait déjà beaucoup…

    ce commentaire est sous licence cc by 4 et précédentes

  • # Timeshift + rsync vs btrfs

    Posté par  . Évalué à 1.

    Faisant partie des nouilles écervelées qui utilisent Mint, j'ai aussi dû me faire à ce nouveau gadget qui ne m'emballait pas vraiment…

    D'abord, ce n'est pas un outil de sauvegarde, mais plutôt un système d'instantanés pour l'OS permettant aux devs de Mint de sortir des mises à jours un peu moins léchées, et à l'utilisateur de revenir à un "point de restauration" (comme sous Win$) si ça tourne mal…

    Au départ, étant un peu frileux avec btrfs, je suis resté sur ext4, et j'ai créé une partition de sauvegarde pour Timeshift avec rsync. Il m'a vite semblé que les performances disque étaient moins bonnes que sur la Mint précédente, ce qui m'a décidé à garder l'ancienne version pour mes machines 32 bits. Ensuite, rsync m'a vite saoulé en faisant exploser la charge système quand il se mettait en route, pendant un temps plutôt élevé

    Du coup, à l'occasion d'une nouvelle installation, j'ai décidé de tester btrfs sur une partition système un peu plus grande plutôt qu'une partition à part. Le résultat en valait la peine : le système semble redevenu aussi rapide à démarrer qu'avant, et l'utilisation d'un "vrai" système d'instantanés à rendu le travail de Timeshift entièrement transparent. Ça prend aussi beaucoup moins de place sur disque puisque seul les changements sont conservés

    Finalement, j'ai réinstallé tous les autres postes Mint avec le système en btrfs. Les performances disque à l'usage (sur machine de bureau en tout cas) sont bien meilleurs que les benchmarks que j'ai pu lire à droite à gauche le laissaient entendre, et c'est aussi stable et performant avec bcache qu'ext4. Bref, je ne suis toujours pas emballé par Timeshift, mais je conseille de tester btrfs pour le système (je reste sur ext4/xfs pour les données pour l'instant)

    • [^] # Re: Timeshift + rsync vs btrfs

      Posté par  . Évalué à 4.

      A moins que j'ai raté quelque chose, Timeshift ne garantit pas de pouvoir revenir en arrière.
      En effet, on fait un snapshot de @/ avant une mise à jour. Puis on fait la mise à jour. Un éventuel problème peut être visible de suite, auquel cas on demande à Timeshift de restaurer les snapshot que l'on vient de faire et on reboote (la restauration implique un reboot pour être effective). Tout va bien.

      Mais le problème peut aussi ne se révéler que lorsqu'on reboote le système après une mise à jour et que ça plante avant d'arriver sur le bureau => impossible de demander une restauration à Timeshift. Il faut se débrouiller avec les moyens habituels (pas forcément à la portée de Mr Michu).

      C'est là qu'intervient btrfs-grub : il créé automatiquement une entrée dans grub pour chaque nouveau snapshot de @/. Du coup, si ça plante au redémarrage après la mise à jour, il suffit de choisir un des snapshots existants via une des entrées de grub.

      Du coup, je n'utilise Timeshift que comme une UI pour créer un snapshot, les lister ou en supprimer, jamais pour en restaurer un.

      Pour ce qui est de btrfs, je m'y suis mis moi aussi, y compris pour les données (en raid 1) et pour le moment j'en suis satisfait.

      • [^] # Re: Timeshift + rsync vs btrfs

        Posté par  . Évalué à 1.

        C'est intéressant. Par contre, je ne trouve pas btrfs-grub sur le système, ni dans les paquets standards. C'est quelque chose que tu as installé à la main ?

  • # des problèmes bizarres

    Posté par  . Évalué à 1. Dernière modification le 24 novembre 2018 à 13:28.

    Bonjour,

    J'utilise timeshift (choix rsync) programmation journalière depuis plus d'un an.
    Ça fonctionne bien durant un certain temps, je dirai 2 ou 3 mois, puis mystérieusement sans raison apparente, un beau jours terminé, tout est à refaire depuis le début !
    Je m'en rends compte au bruit que fait mon 2ème DD sur lequel j'effectue la sauvegarde :
    Quand tout se passe normalement, ça mouline environ 3 minutes, quand ça commence à déconner, environ 15 minutes.
    C'est encore arrivé ces jours-ci, pas de nouveau cliché dans la fenêtre principale.
    Voilà ce qui est indiqué dans les journaux :

     [15:00:01] rsync -aii --recursive --verbose --delete --force --stats --delete-excluded --link-dest='/media/root/SVG TimeShift/timeshift/snapshots/2018-11-22_12-00-01/localhost/' --log-file='/media/root/SVG TimeShift/timeshift/snapshots/2018-11-23_15-00-01/rsync-log' --exclude-from='/media/root/SVG TimeShift/timeshift/snapshots/2018-11-23_15-00-01/exclude.list' --delete-excluded '/' '/media/root/SVG TimeShift/timeshift/snapshots/2018-11-23_15-00-01/localhost/'
    [15:00:01] RsyncTask:prepare(): saved: /tmp/timeshift/n1VGwrE9/2018-23-11_15-00-01/script.sh
    [15:00:01] AsyncTask: child_pid: 13941
    [15:15:04] AsyncTask: finish(): enter
    [15:15:04] exit_code: 11
    [15:15:05] E: rsync returned an error
    [15:15:05] E: Failed to create new snapshot
    [15:15:05] Failed to create snapshot
    [15:15:05] E: Failed to execute child process "notify-send" (No such file or directory)
    [15:15:05]

    J'ai bien essayé de lancer une tâche manuellement (O) à la suite, mais c'est une nouvelle sauvegarde complète qui se crée (la première est alors renommé Grsync1).

    C'est pénible de ne pas pouvoir compter sur un soft de sauvegarde :(
    Mais bon, par rapport à Clonezilla que je trouve imbuvable et qui prend un temps fou puisque non incrémentiel, je me résigne à l'utiliser malgré tout…

  • # sauvegarde linuxmint19 sur dd externe

    Posté par  . Évalué à 1. Dernière modification le 23 décembre 2018 à 14:55.

    bonjour,j'ai un léger problème (évidemment sinon je ne serais pas ici!) j'ai sauvegardé (enfin je pensais) tous mes documents avec timeshift sur un DD externe….Linux mint 19 m'a planté (noir au démarrage…au bout d'un certain temps de galère je me suis dit…j'ai une sauvegarde donc je formate, remet Linux mint avec les mêmes paramètres et je n'ai qu'à revenir à on ancien système… sauf que… j'ai bien un home à mon nom mais rien dedans !…une idée ?

    • [^] # Re: sauvegarde linuxmint19 sur dd externe

      Posté par  . Évalué à 2. Dernière modification le 09 février 2019 à 13:38.

      Ceci dit, la règle c'est qu'on n'a pas de sauvegarde tant qu'on n'a pas tenté de faire une restauration pour vérifier que ça marche…

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.