bup te cause quand même de comment l'envoyer à distance, ta "sauvegarde locale" ;-))
Je ne suis pas spécialiste de bup, mais il semble quand même que son fonctionnement standard c'est de faire une sauvegarde locale, de l'envoyer ensuite par rsync vers une sauvegarde distante et ensuite d'utiliser la sauvegarde locale. Par exemple ce n'est pas possible avec bup de faire un restore depuis la sauvegarde distante (ou bien il faut faire le restore depuis la sauvegarde locale ou bien se connecter sur la machine distante pour « opérer en local » pour peu que l'on ait bien tout installé sur la machine distante).
Cela ressemble quand même très très fortement à ce que je suis en train de faire. ;-)
Sans doute parce qu'en général la sauvegarde s'occupe d'avoir une copie des données [...] et est considérée suffisamment orthogonale pour ne pas parler de protéger des aléas de la copie courante [...]
C'est un peu à la frontière je te l'accorde, mais certains outils de sauvegarde comme bup (encore lui !) intègre la protection contre la corruption de données (via checksum effectué par l'outil même).
Le fait que l'outil ait un "sas" local ne valide pas pour moi la pertinence d'une sauvegarde locale contre autre chose qu'un bête rm (et avant que tu remettes sur le tapis à toutes les sauces les corruptions de bits, si ton disque commence à chier dans la colle sur les fichiers courants, il peut tout aussi bien chier dans la colle sur les fichiers de la sauvegarde locale, et si les deux sont corrompus... d'où la problématique orthogonale mais nécessaire aussi d'outils contre ça).
Là j'ai du mal à te suivre. Dans mon approche, les fichiers courants et les fichiers de la sauvegarde locale sont exactement les mêmes (reflink). Donc si l'un est corrompu, l'autre l'est automatiquement aussi. Mais j'ai justement un RAID1 pour empêcher que la donnée originale soit corrompue (et donc automatiquement la donnée localement sauvegardée). Donc sauf à considérer une erreur dans la carte mère ou le FS/Kernel, on peut dire que les données ne peuvent pas être corrompue dans mon approche.
Et pour la protection contre le bête rm, il y a un admin plus haut qui donne des statistiques sur l'utilisation de ses sauvegardes. En très très grand majorité, c'est suite à un bête rm qu'il utilise les sauvegardes. Donc cela ne me semble pas idiot d'optimiser mon approche pour me protéger contre le rm et de « négliger » un peu la protection contre les autres risques (même s'ils sont couverts en fin de semaine lors de la sauvegarde distante).
Merci pour la discussion posée ! C'est quand même sacrément plus agréable.
[^] # Re: Mes deux centimes
Posté par SaintGermain . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 1.
Je ne suis pas spécialiste de bup, mais il semble quand même que son fonctionnement standard c'est de faire une sauvegarde locale, de l'envoyer ensuite par rsync vers une sauvegarde distante et ensuite d'utiliser la sauvegarde locale. Par exemple ce n'est pas possible avec bup de faire un restore depuis la sauvegarde distante (ou bien il faut faire le restore depuis la sauvegarde locale ou bien se connecter sur la machine distante pour « opérer en local » pour peu que l'on ait bien tout installé sur la machine distante).
Cela ressemble quand même très très fortement à ce que je suis en train de faire. ;-)
C'est un peu à la frontière je te l'accorde, mais certains outils de sauvegarde comme bup (encore lui !) intègre la protection contre la corruption de données (via checksum effectué par l'outil même).
Là j'ai du mal à te suivre. Dans mon approche, les fichiers courants et les fichiers de la sauvegarde locale sont exactement les mêmes (reflink). Donc si l'un est corrompu, l'autre l'est automatiquement aussi. Mais j'ai justement un RAID1 pour empêcher que la donnée originale soit corrompue (et donc automatiquement la donnée localement sauvegardée). Donc sauf à considérer une erreur dans la carte mère ou le FS/Kernel, on peut dire que les données ne peuvent pas être corrompue dans mon approche.
Et pour la protection contre le bête rm, il y a un admin plus haut qui donne des statistiques sur l'utilisation de ses sauvegardes. En très très grand majorité, c'est suite à un bête rm qu'il utilise les sauvegardes. Donc cela ne me semble pas idiot d'optimiser mon approche pour me protéger contre le rm et de « négliger » un peu la protection contre les autres risques (même s'ils sont couverts en fin de semaine lors de la sauvegarde distante).
Merci pour la discussion posée ! C'est quand même sacrément plus agréable.