Bonjour,
J’aimerais un conseil pour la méthode de sauvegarde entre rsync et rdiff-back
deux destinations de sauvegardes un pc local et un dd interne
j’ai fait des script avec contôle du dd interne monté avant de lance la sauvegarde en local
j’ai fait des script avec contôle du pc local s’il repond au ping je lance la sauvegarde
Je souhaite une sauvegarde tous les jours du home au boot sur dd interne
Je souhaite une sauvegarde par semaine du système sur dd interne
Je souhaite une sauvegarde par semaine du home sur pc local en ssh
Je souhaite une sauvegarde par semaine du système sur sur pc local en ssh
et surtout une maniére simple de restaurer
Merci d’avance.
Cordialement
Je pense que tu veux dire rdiff-backup.
rsync est un programme qui permet de mettre à jour le répertoire cible avec le répertoire source en étant optimisé pour le faire sans recopier les données déjà présentes dans le répertoire cible.
rdiff-backup sauvegarde un historique des incréments du répertoire source dans le répertoire cible.
Si tu souhaites pouvoir restaurer une version antérieure de tes données (ce qui est conseillé pour une sauvegarde), je te conseille plutôt d’utiliser rdiff-backup ou un des outils proposés par @Clochette.
Pour rdiff-backup, je te conseille de lire le manuel afin de comprendre ce que tu fais.
Pour clochette
timeshit correspond à ce que je souhaite en interne
il fait peu ou prou ce que j’ai mis en place avec rsync et --backup-dir en graphique et mieux que mon script certainement.
Mais ne fonctionne pas en local juste en interne ou usb.
Pour rdiff-backup, qui à ma préférence je rencontre un souci lors de la restauration depuis un pc local lors du lancement, échoue en me demandant d’ajouter --force.
Si j’ajoute – force il supprime tous les dossiers et les fichiers présents dans la source et absent de la sauvegarde à restaurer
J’utilise :
rdiff-backup -v5 —fsync restore --at now $USER@P:://ce que je veux restore oû je veux restore.
Dans ce cas Restic ou Borg feront le taff, c’est léger et efficace par contre c’est du CLI only
Pour info, vorta interface graphique borg:
vorta 0.8.10-1 : Desktop Client for Borg Backup / qt
GitHub - borgbase/vorta: Desktop Backup Client for Borg Backup
» illustration
2 J'aime
Disponible dans les repository Debian
vorta/stable,now 0.8.10-1 all [installé]
Desktop Client for Borg Backup
1 J'aime
si tu aimes le principe de rsync, grsync aide bien , il te donnes les options de rsync correspondant à tes choix
Vorta est disponible depuis 2020 chez Debian, pas un petit nouveau. [Vorta Debian]
Pourquoi Vorta est-il apparemment peu connu ?
Parce-que Borg est probablement peu utilisé, présentant pourtant de gros intérêts, mais surtout pour utilisation très avancée, et Vorta est en qt, donc plus connu des utilisateurs de KDE que de gnome, plus rétissants à installer trop de librairies qt.
Vorta:
Depends: python3-appdirs python3-paramiko python3-peewee python3-pkg-resources
python3-psutil python3-pyqt5 python3-secretstorage python3 libqt5svg5
python3-pyqt5.sip python3-pyqt5.sip python3 python3 libc6 libgcc-s1
libpython3.11 libqt5core5a libqt5dbus5 libqt5designer5 libqt5gui5 libqt5gui5
libqt5help5 libqt5network5 libqt5printsupport5 libqt5test5 libqt5widgets5
libqt5xml5 libstdc++6 qtbase-abi-5-15-8 et ++.....
Recommends: borgbackup
Une remarque au passage sur rsync (on ne s’en lasse pas de celle là).
rsync est une commande très puissante, mais complexe et dangereuse (lire son man…) qui demande un réel investissement pour comprendre son fonctionnement précis, la consultation d’une doc ou blog superficiel expliquant rsync avec 5 arguments ne suffisant pas (jusqu’au jour où on s’aperçoit qu’on avait pas tout compris).
$ rsync --help |grep '\-' |wc -l
152
La seule option rsync impérative à connaître avant utilisation …: --dry-run, -n
grsync en interface aide à mieux maitriser rsync (plus explicite, très léger, en gtk).
Un utilisateur qui dirait que « rsync est achement simple » n’a jamais pris le temps de comprendre rsync. On peut se contenter d’un script de backup qui fonctionne bien dans un cas particulier et assez commun, mais ça n’en fera jamais de rsync un outil « simple ».
Plus pour les utilisateurs de KDE, luckybackup aussi dans les dépôts Debian est un outil simple bien que basé sur rsync, masquant la complexité de rsync, avec interface bien intégré à KDE.
luckybackup:
Depends: libc6 libgcc-s1 libqt5core5a libqt5gui5 libqt5widgets5
libstdc++6 luckybackup-data rsync
Et enfin, avant de vouloir « cloner » des partitions, il faut déjà s’assurer que l’opération de « clonage » est réellement utile et nécessaire (j’ai un gros doute pour certaines demandes / jamais personnellement).
Bonjour,
j’ai tester luckybackup, timeshift ce sont de bon logiciels y font le boulot pas de souci mais mes besoins étant particuliers cela ne correspond pas totalement.
En fait j’ai sur mon pc deux système debian, pour des besoin bien distinct un de l’autre on va dire un simple utilisateur pour un et un autre plus dedié à mon activité pro que je souhaite mise à part.
Dossiers séparés pour user et root
Donc j’ai créer pour simple utilisateur
-
un script qui sauvegardes /home en interne tous les jours au boot avec contrôle du montage contrôle si sauvegarde déjà faite
-
un script qui sauvegarde /home sur un pc en local une fois par semaine, contrôle avec des if si pc allumé et si la sauvegarde n’a pas déjà était faite dans la semaine
lance via anacron. -
un script qui sauvegarde /home sur un dd usb 1 fois par mois ( je dois faire une rêgle udev !!!)
Pour la racine de root
sur tous contrôle si lancé en root
-
un script qui sauvegardes / en interne tous les jours au boot avec contrôle du montage contrôle si sauvegarde déjà faite, lancer via anacron
-
un script qui sauvegarde / sur un pc en local une fois par semaine, contrôle avec des if si pc allumé et si la sauvegarde n’a pas déjà était faite dans la semaine
lance via anacron, idem lancer via anacron -
un script qui sauvegarde / sur un dd usb 1 fois par mois ( je dois faire une rêgle udev !!!) controle du montage du disque usb etc
J’ai appliqué le même principe pour mon pc utilisation pro
Ok. En fait, précision: mon cerveau a fourché en évoquant luckybackup, puisque je pensais à kup-backup qui recommande bup (système de sauvegarde de fichiers basé sur Git)
C’est kup-backup qui a un interface totalement intégré à plasma.
Il y en a tellement avec des noms en ‹ kup › qu’on s’y perd.
Verner.
Justement je l’ai essayer mais quand au bout de 3 heures de sauvegardes 170 Go, la premiére fois, ils vous dit échec car un fichiers a éte modifié ca refroidie.
Une seconde fois je refait le test il mets 3 heures et ensuite tourne en boucle deux heures minimum pour analyser la sauvegarde j’ai stopper et renoncé.
Mais mais mais … pourquoi tout mettre dans un seul gigantesque fichier…
Avec un script, tu peux justement sélectionner répertoire par répertoire, ‹ tar › a une option pour automatiquement splitter les fichiers de taille X etc etc… (plus ça en tête pour le moment).
C’est pas super simple tout ça, mais perso, j’insiste sur le contenant qui me semble plus important que rsync qui reste complexe à maîtriser, et impossible à garantir ce qui se passera lors d’une restauration (pour du système). C’est juste un point de vue hein, du feeling…
Sinon cpio est sympa, le seul qui peut créer le répertoire lors d’une copie d’un fichier, en garantissant copie exact en tout paramètre (droits/date/taille etc…) mais moins connu car surtout utilisé pour faire ses initramfs perso.
cpio, c’est juste pour info. tar et cpio: même philosophie: l’archivage exact.
Bon courage.
Verner j’ai deux option en cas de pb sur le systéme comme je viens d’avoir.
Lors d’un test de incron qui a rendu mon système inutilisableb j’ai tester rdiff-backup et rsync, j’ai garder rsync car plus lisible les incréments.
j’ai fait un script pour partir d’une net install et remettre mes " personnalisations",
à voir qui est le plus rapide pour retrouver un système correct.
Je maitrise pas trop qui fait quoi dans /
Pour les données perso y a pas le souci de droits etc
Je ne vais pas pouvoir développer ce WE, mais juste un exemple.
A quoi ça sert d’archiver un répertoire genre /var/cache/apt/archives/ qui contient des paquets Debian.
Strictement à rien du tout, à part faire exploser des Go d’archives totalement inutiles.
Jamais très bien compris exactement les problèmes de « clonage » de partition etc…
Les outils de backup genre Borg par exemple sont spécialisés dans la backup incrémentale, niveau professionnel.
Les données persos: c’est le plus simple, pas de soucis particuliers.
Mais ‹ rsynquer › un système, si je puis dire… c’est juste partir à l’aventure qui sauvera des fichiers de config, mais sans garantie sur un ensemble système.
Impossible de prétendre maîtriser rsync sans s’être déjà cassé quelques dents…
sans pretention aucune j’ai eut plus de déboire avec la restauration via rdiff-backup que rsync ( suppression de fichier par rdiff)
justement j’avais testerles deux et garder celui qui me convennait le mieux et c’est rsync.
Pour le système maintenant que j’ai trouver la méthode je vais creuser et épurer les dossier à sauvegarder ou pas hormi les proc run sys srv tmp
un apt-get clean vide le cache d’apt chez moi avant une sauvegarde 
Bonjour,
bon retour du test d’une restauration du systéme avec rsync.
Akonadi ne fonctionne plus car au boot il ne se créer pas le dossier /run/user/1000/akonadi avec les sockets de mysql, certainement un liens cassé à la sauvegarde.
pour le moment je cherche plus fiable ( sur la partie dossier utilisateur la restauration fonctionne parfaitement)
Je vais cloner avec partition manager pour avoir une sauvegarde fiable dans un premier temps.
et revoir mon approche de pourquoi sauvegarder et quoi sauvegarder et comment sauvegarder et comment restaurer ensuite.
Depuis 2 mois je cherche car j’enchaine les erreurs , conne**** en tout genre :
au début un disque avec faillure smart m’a laché.
Reinstallation du systéme sur un disque neuf, premiére connerie je me trompe de disque et formate celui des données utilisateurs 
J’avait un backup de 3 mois avec rdiff-backup je remet avec quelques perte de données mais pas trop grave le plus important est remis en place.
Donc je cherche à parfaire mes sauvegardes restauration.
je teste incron et je plante mon systéme une fois de plus
Je rdiff-backup et retrouve un systéme fonctionnel.
Ne maitrisant pas rdiff-backup je me tourne vers rsync ( les incréments sont plus lisible que rdiff-backup) .
hiers encore une boulete qui a faire du test en live alons-y franchement je fait clic droit supprimer ( même pas dans la corbeille non supprimer direct, sur un dossier de montage dans /mnt et la je supprime une partie de mon autre systéme sans savoir quoi est partie.
Je restaure avec rsync et pb akonadi, certainement d’autre moins visible.
J’ai deux solutions pour la perte totale du systéme:
1 - clônage via partition manager mes deux systéme vont prendre 60 Go d’image pour 20 go utilisés,30 go et 10 pour chaque.
- 2 Reinstallation avec mon script, cela prend environ une heure.
Je cherche donc queleques chose qui soit récurent et plus rapide car j’aime bien aller au bout de mes idées.
Salut,
je crois qu’il va te falloir bien t’organiser parce qu’il me semble que tu n’es pas au bout de tes peines. La première étape consiste à faire l’inventaire précis de ton matériel et des données à sauvegarder.
Je dirai bien 'my God’, mais ça ne t’aidera pas.
Assure toi aussi de savoir décloner sans casser la table de partition d’un disque, ça pourrait aussi faire partie de facheux désagréments d’expérimentation.
En GPT, la table de partition n’est pas qu’en début de disque…
C’est fragile ces petites choses.
Sinon, dans l’expérimentation relative à rsync tu peux aussi regarder rsnaphot.
Sinon, il peut y avoir d’autres expérimentations intéressantes, pendant que tu expérimentes.
Pour éviter ça, je ne lance la commande que quand je suis sûr qu’elle sera appliquée sur le « bon » disque, et je me sers de leur numéro de série pour les identifier à coup sûr.
Un simple
udisksctl status
me permet de savoir quel fichier de périphérique a été associé à quel disque et quel est son numéro de série (qui est souvent inscrit sur l’étiquette d’identification collée sur le disque).