Utiliser mon PI pour sauvegardes miroirs

[Sventovit]

Bonjour à toutes et à tous.
La question est dans le titre.

Je ne sais quelle solution (en mode console uniquement) pour mon besoin de sauvegarder en miroir le contenu d’un disque réseau vers un disque USB auto-alimenté qui lui est attaché.

Auriez-vous une idée ?

[epoch1970]

"sauvegarde en miroir", c'est un peu un oxymore...
Pour le côté miroir, j'utilise Syncthing et j'en suis fort satisfait. Ca n'est pas du tout une solution de sauvegarde!

[totoharibo]

j'utilise rsync (et pas en mode console : grsync )

on peut utiliser des commandes/scripts avant/après la sauvegarde (cela permet montage HDD, mise au repos HD, etc)

[Sventovit]

"sauvegarde en miroir", c'est un peu un oxymore...

exact…

Pour le côté miroir, j'utilise Syncthing et j'en suis fort satisfait. Ca n'est pas du tout une solution de sauvegarde!

Syncthing ?
Je ne connaissais pas (remarque, je ne connais rien à Linux non plus) et j’ai regardé sans trouvé de page sur une configuration en mirroring.

@totoharibo
rsync donc sur le RPI qui va procéder au mirroring ?
C’est bien ça ?

[epoch1970]

https://syncthing.net
C'est de la réplication de répertoire pair-à-pair à la Dropbox, en auto-hebergement. Un process par utilisateur. Chiffré, peut fonctionner en 100% local ou en mode cloud avec un service de discovery. API/CLI et interface web.

[Sventovit]

Et pour mon besoin (sauvegarder en miroir le contenu d’un disque réseau vers un disque USB auto-alimenté qui lui est attaché) ça pourrait coller ?
et ce n’est pas trop lourd pour un RPI 2 ?
d’après ce que j’ai lu ça devrait coller a priori.
Et ça peut servir à plein d’autres trucs.
Bref, ça a l’air du tonnerre.

Merci beaucoup.

[epoch1970]

Il y a une histoire de hashage des fichiers, l'install peut consommer pas mal de RAM si le volume répliqué (ou le nombre de réplicats?) est important. Mais je ne rencontre aucun problème, peut être qu'il faut partager des dizaines ou des centaines de giga pour commencer à le sentir sur un Pi.
Le hashage des fichiers déposés dans le répertoire prend 100% d'un core le temps qu'il faut, la charge du Pi n'excède jamais 25% mais sur des gros fichiers, l'opé peut prendre du temps...
Le lead dev (un Suédois) a fini par s'acheter un Pi pour voir de lui-même comment ça fonctionnait Je crois qu'il a pris un Pi 2.

Perso je l'utilise via VPN bridgé avec l'option de limite de débit en intra-LAN, pour des sites distants ça va mieux qu'un montage à travers le réseau.
A mon avis les options d'exclusion de fichiers, de versionnage... tout ça n'est pas trop cuit et peut entraîner des conflits de synchro. Ma recette, c'est synchro libre (sans filtre, r/w pour tout le monde) + backup automatique de chaque répertoire sur chaque machine tous les soirs.

Côté backups j'ai choisi borgbackup, ça fait de la dédup, j'en suis content. L'interface web est en développement, et elle n'est pas packagée en .deb pour le moment il me semble.

[jelopo]

Bonjour,

Jamais utilisé personnellement, mais il y a peut être à creuser du coté de drdb ?

A+

[nikotinux]

rsync -av --delete source dest

simple et très efficace

[JumpZero]

rsync -av --delete source dest

simple et très efficace

+1
les outils de base Unix font le boulot, existent depuis si longtemps, sont maintenus, documentés que demander de +

[totoharibo]

rsync -av --delete source dest

simple et très efficace

+1
les outils de base Unix font le boulot, existent depuis si longtemps, sont maintenus, documentés que demander de +

qu'il n'y a plus de bug ...

[JumpZero]

rsync -av --delete source dest

simple et très efficace

+1
les outils de base Unix font le boulot, existent depuis si longtemps, sont maintenus, documentés que demander de +

qu'il n'y a plus de bug ...

Bug dans rsync

[Sventovit]

là je ne comprends rien à ce qui est dit plus haut.
Bref… j’ai installé Syncthing sans difficulté pour synchroniser le contenu d’une clé USB connecté au RPI avec une tablette.
Ça marche bien
sauf que je suis tellement noob que je ne suis pas certain d’avoir bien formaté cette clé.
Voilà ce que me donne fdisk -l :

_/ EXT3 \______________________________________________________

Filesystem Size Used Avail Use% Mounted on
df: no file systems processed

______
_/ VFAT \______________________________________________________

Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk0p1 240M 21M 219M 9% /boot
/dev/sda1 58G 96K 58G 1% /media/9336-482C

______
_/ NTFS \______________________________________________________

Filesystem Size Used Avail Use% Mounted on
df: no file systems processed
/sbin/disklist: 8: read: arg count

En principe j’ai formaté cette clé de 64 Go en FAT32, mais là sa capacité formatée ne ferait que 58G.
Bizarre non ?

Pour mon opération de mirroring je pense utiliser Rsync plutôt que Syncthing qui me paraît lourd pour une tâche assez simple :
à une heure donnée comparer le contenu de A et de B et synchroniser B avec A (copies/suppressions).

Je compte m’y atteler aujourd’hui.

[epoch1970]

Un effet de la querelle des gibi et des giga sans doute. Ton 58GB vaut ~ 62GiB, ce qui est plus proche des 64 annoncés.

[Sventovit]

Quoi ?
Des Gibis ?
Des shadoks se seraient infiltrés dans ma Framboise ?

Blague à part c’était intéressant. Merci pour le lien.

[totoharibo]

Quoi ?
Des Gibis ?
Des shadoks se seraient infiltrés dans ma Framboise ?

Blague à part c’était intéressant. Merci pour le lien.

c'est la suite de 1kB =1024 octets =2 puissance 7 . et on continue sur les M et les G