Forum

Reprise du message précédent

Il me semble que draksnapshot est déjà une interface graphiqe pour rsync rien de plus.


Il me semble qu'il n'est pas possible de prendre une vrai "snapshot" du système avec un formatage ext4. D'ailleurs des outils comme rsnapshot semblent être en réalité basés sur rsync. C'est la même chose pour Timeshift.

Bonjour,



Cela tombe bien, rsnapshot est un pré requis pour draksnapshot, donc je pense que ce dernier est une interface pour ce premier programme.

Cependant, je pense qu' il y a mélange entre les bibliothèques gtk2 et gtk3 dans les appels du programme, c' est probablement pour ça que l' interface graphique ne se lance pas (le mélange entre les deux n' est probablement pas possible, et remplacer les modules référencés en gtk2 ( ugtk2 et mygtk2, par respectivement ugtk3 et mygtk3) n' est pas suffisant, les fonctions ayant probablement changées ( les appels à gtknew entrainent une erreur).

Ensuite, il y a un appel à MDV::SNAPSHOT:HAL ... Hal ça existe toujours ( donc même si l' interface fonctionnait, il y aurait probablement un problème avec la découverte des disques) ?

Édité par nic80 Le 17/05/2020 à 11h51

"This tool should be rewrite to switch to GTK+3 and udisks2, this is why it is broken for a long time."

https://bugs.mageia.org/show_bug.cgi?id=22425#c4

c'est ce que j'ai cru comprendre quand je m'étais intéressé à cela;
les vrais snapshots, c'est sur du "btrfs", mais ça suppose toute une configuration, une maitrise de la fonctionnalité, et surtout ça demande des partitions au moins du double de taille pour contenir les snapshots; ensuite, il y a les commandes "btrfs-send et receive" pour exporter ou reimporter les snapshots vers un disque externe ou le réseau, qui sont incrémentales comme rsync;
mais c'est assez compliqué à mettre en œuvre et à ma connaissance seul opensuse a travaillé sur la question du btrfs; même chez debian ou chez arch il n'y a pas beaucoup d'experts de btrfs.(c'était il y a deux ans, depuis j'ai laissé tomber l'affaire);et chez redhat ils y ont renoncé officiellement.
je me contente de maintenir une opensuse sur btrfs 60gio, pour voir comment ça vieillit ce truc;comme c'est le choix par défaut chez opensuse, la configuration des subvolumes et le fstab sont tout prêts et l'utilitaire snapper fait le job indispensable de gestion.

Btrfs à l'air de poser plus de problèmes qu'il n'en résout...

De plus je ne sais pas si c'est réellement considéré comme stable..Sous openSUSE, quand tu as un ssd ça va, mais sur un hdd rétro-magnétique classique, et bien ça rame sévère, de plus ça active une multitude de service, qui au final alourdissent le système.

Clonezilla c'est ce que j'ai trouvé de mieux !!

Bonjour,



Depuis le CCM, oui ça ne marche pas ( de base à cause du mélange gtk2/gtk3, ensuite après les modifications gtk2->gtk3 à cause de la fonction create_factory_menu))...

Depuis la konsole, j' ai réussi à avoir ça:



( Bon après j' ai modifié le fichier /usr/libexec/draksnapshot-config), en remplaçant tout ce qui est gtk2 en gtk3 ( ugtk2 devient ugtk3 et gtk2 devient gtk3, j' ai défini les champs retain hourly,daily,weekly et monthly dans /etc/rsnapshot.conf ( sans ça, ça plante parce qu' il faut qu' ils soient définis) ). D' ailleurs je crois que le champ interval s' est transformé en retain).

Bon quand je vais dans avancé, l' ajout ( ou l' exclusion) de répertoires fait planter l' application (à cause de VBox)...

Édité par nic80 Le 17/05/2020 à 23h03

Super, nic80,
Je veux bien de tes modifications. Idéalement sous forme de patch que tu joins à l'un des rapports de bogue.
Je pourrai les soumettre ensuite, ou regarder ce qui ne va toujours pas.

Bonjour,

Modifié le bug 22425.

Je n' ai pas attaché le /etc/rsnapshot.conf ( en fait il faut définir les interval/retain hourly,daily,weekly,montlhy ( sous la forme retain daily X où X est un chiffre ( ayant survolé le man de rsnapshot, je n' ai pas fait attention à la signification de celui ci).

Super !
Je regarde ça ce soir.

Bonjour,

En modifiant la ligne dans le fichier /usr/libexec/draksnapshot-config:



Par



L' interface semble se lancer depuis le centre de contrôle ( bien entendu, il faut faire les changements gtk2->gtk3 avant et créer les retain nécessaires dans /etc/rsnapshot.conf avant ( peut être que cela pourrait être défini dans le paquet rsnapshot ( les personnes modifiant directement le /etc/rsnapshot.conf ayant forcément lu la page man ( ou pas !) )....



Reste le plantage sur l' ajout de répertoires...

Après non, je ne connais pas du tout le Perl donc je fais des modifications sans bien comprendre le code...

Édité par nic80 Le 21/05/2020 à 11h28

Bonjour,

/usr/sbin/draksnapshot-applet.txt
/usr/libexec/draksnapshot-config.txt
/usr/share/perl5/vendor_perl/MDV/Snapshots/Hal.pm.txt

Dans le draksnapshot-config , la partie relative à hal est désactivée, parce que ça ne marche pas ( pour contourner le plantage du à la non définition la variable backup_directory, un répertoire par défaut est entré) ... Il faut toujours modifier le /etc/rsnapshot.conf pour définir les retain hourly, daily, weekly,monthly.

Petite question aux packageurs... Est ce normal que draksnapshot-config soit dans /usr/bin mais que le draksnapshot-restore soit dans /usr/sbin ? Et que /usr/share/autostart/autostart-draksnapshot.desktop ne soit pas dans /etc/xdg/autostart ?

Édité par nic80 Le 28/05/2020 à 11h10

Je ferai les essais ce soir.
Est-ce le bouton "Appliquer" est suivi d'effet ?

Bonjour,

Il me semble que oui. Après il n' y a rien de bien visible, car le programme ajoute/enlève des mots clés dans /etc/rsnapshot.conf en plus de rajouter/supprimer des entrées dans les répertoires cron.hourly, cron.daily, cron.weekly, cron.monthly (mais pas yearly puisque la période n' est pas gérée). Il n' y a donc pas de déclenchement de sauvegarde lors de l' appui sur appliquer (enfin il ne me semble pas).

Je viens de faire l'essai, et :
aucun plantage !!!
Aucun souci d'interface.
La configuration est effectivement écrite.

Je vais pousser pour ces corrections arrivent.

Ce n'est pas encore complètement gagné :

Le message est de 8h alors qu'il existe un fichier /var/run/rsnapshot.pid datant de 7h38

PS: En fait je pense que c'est parce qu'une première sauvegarde est en cours, et elle doit être bien longue. En tout cas, elle n'est pas finie.

Édité par Papoteur Le 29/05/2020 à 08h12

Bonjour,

Attention, je pense qu' il y a quand même un plantage si le fichier /etc/rsnapshot.conf ne contient pas les retain hourly,daily,weekly,monthy de manière décochée. Je pense que c' est du à cette ligne (qui doit définir les intervals/retain par défaut) :

$default_intervals{$_} ||= undef foreach $ordered_intervals;

Mais je ne comprends pas ce qu' elle fait exactement. Après lecture sur le web cela correspondrait à

$default_intervals{$_} = $default_intervals{$_} || undef foreach $ordered_intervals;

Mais est ce que cela indique que cela mets le couple hourly => undef ( et la même chose pour le reste ?)

Je n' ai pas forçement testé avec un /etc/rsnapshot.conf issu du paquet directement, ni tenté de vérifier que draksnapshot-restore fait la restauration correctement.

En plus la partie hal ne fonctionne pas (c' est pour ça qu'il y a un chemin "fantôme" qui est affiché).

draksnapshot-config fonctionne donc sans les fichiers hal.pm et draksnapshot-applet (qui ne sont pas fonctionnels).

edit: le plantage de rsnaphot est là probablement à cause du fait qu' il y a peut être une sauvegarde en cours ( si on sauvegarde un grand nombre de fichiers, le premier lancement est probablement plus long , rsync devant recopier l' intégralité des fichiers (et entre 7h38 et 8h00, il n' y a pas une heure)

Édité par nic80 Le 29/05/2020 à 08h19