Voici une incarnation plus ancienne de cette requête que j'ai trouvée : 555

+1

Je pense aussi que ce serait une fonctionnalité vraiment utile.

Alors, laissez-moi résumer : vous exécutez restic backup /mnt/backup-snapshot , donc le fichier /mnt/backup-snapshot/foo est /mnt/backup-snapshot/foo dans l'instantané, mais vous aimeriez qu'il soit /foo . Est-ce exact?

Vous pouvez y parvenir avec restic > 0.9.0 en changeant le répertoire actuel, exécutez simplement cd /mnt/backup-snapshot puis restic backup . .

Est-ce que ça marche pour toi?

Changer le cwd fonctionne, mais j'ai remarqué qu'il y a un effet secondaire désagréable si vous utilisez des fichiers pour inclure/exclure. Il semble que si des chemins absolus y sont placés, ils seront ignorés lors de la modification du cwd . Je préférerais également utiliser des chemins absolus - pour l'instant, je vais probablement me diriger vers le chemin chroot, mais je suis d'accord qu'il serait plus agréable d'avoir quelque chose de similaire au drapeau -C dans tar .

Je pense que cette fausse option root serait une fonctionnalité utile. J'aimerais faire la même chose que cdhowie mais avec un instantané apfs sur macOS. Pour accéder aux instantanés apfs en lecture seule, ils doivent être montés quelque part. Mais lors de la restauration, je voudrais que le chemin "d'origine" soit le chemin canonique stocké dans l'instantané.

l'astuce du cd n'est malheureusement pas optimale car j'ai beaucoup (125) de chemins absolus collectés à partir de StdExclusions.plist (liste d'exclusion de sauvegarde standard macOS) et tous les fichiers et dossiers que mdfind peut trouver avec l'ensemble d'attributs com_apple_backup_excludeItem.

Laisse juste le problème si vous placez /mnt dans le fichier ignore et démarrez la sauvegarde à partir de /mnt/fs-snapshot, il s'exclura lui-même.

Plus cd $path && restic backup . donne toujours $path dans la vue d'ensemble de l'instantané, tandis que les chemins dans l'instantané sont basés sur /.

J'ai trouvé une solution de contournement avec proot.

Je voulais aussi trouver un moyen de supprimer le préfixe de chemin. Mon cas d'utilisation est légèrement différent - je crée un instantané zfs ( fs@$(date +%s) ) et je voulais le sauvegarder sans avoir à le monter ( /path/to/mount/.zfs/snapshots/${TS} ) - de cette façon, j'espère que je n'ai pas s'inquiéter du fait que l'instantané ne se démonte pas, puis traîner indéfiniment en cas de plantage.

La sortie restic forget pour cela me fait penser que les instantanés avec des chemins différents ne seront pas oubliés selon le calendrier (quotidien / hebdomadaire / etc.).

Le commentaire proot de @blurayne était un bon point de départ, je pense que je suis arrivé à la même conclusion :

$snap_path="/path/to/where/snapshot/is/accessible"
$orig_fs="/path/to/filesystem"
proot -b "${snap_path}":"${orig_fs}" restic backup "${orig_fs}"

Cela fonctionne bien, et maintenant tous les instantanés ont le même chemin, sans cd ou pushd requis. De plus, le proot est disponible dans l'espace utilisateur, donc si les sauvegardes ne sont pas effectuées en tant que root, c'est toujours possible.

Mon cas d'utilisation : vider les données de la base de données dans un répertoire temporaire, comme /tmp/tmpzmn28r02 (obtenu via mktemp ou mkdtemp() de python), puis les sauvegarder.
Cette méthode marquera tous les fichiers entre 2 instantanés comme étant différents. J'ai donc besoin d'un moyen de dire à restic d'ignorer totalement le préfixe de répertoire temporaire.
Autre cas d'utilisation possible : aujourd'hui, j'ai toutes mes images dans '/mnt/something/pictures' mais demain, le même contenu sera dans '/mnt/external/pictures-from-home' (schéma de partitionnement différent/quoi que ce soit)

De plus, si vous souhaitez utiliser restic et sauvegarder plusieurs répertoires dans la même exécution, afin d'utiliser le même instantané, cela devient encore plus compliqué.

Jusqu'à ce qu'un correctif soit fait, je vais utiliser la proposition 'proot' - merci @blurayne et @whi-tw

Salut! J'ai un cas similaire. Par exemple j'ai des dossiers

/srv/my/long/server1/path/data (with many subfolders and dozen of files)
/path/to/dump.sql
/path/certbot.tar.gz

donc je veux obtenir une sauvegarde comme

/data
/dump.sql
/certbot.tar.gz

et obtenez la possibilité de restaurer sur un autre serveur (je ne connais pas la structure de dossiers précédente) par un chemin différent (relatif).

Je n'ai pas d'idées chaudes pour résoudre cette tâche triviale. Restic est un outil incroyable mais... pourquoi cela fonctionne-t-il si difficilement pour les utilisateurs finaux ?

Je copie dans le dossier de sauvegarde prédéfini (/backup) tout ce dont j'ai besoin et j'exécute la sauvegarde Restic (via cd). Mais cette solution ne fonctionne que pour de petites quantités de données.

Ce sera formidable d'avoir la capacité de restauration avec le sous-dossier --include juste après le modèle (ou en incluant ce masque). ex.:
restic restore --include data --target /my/new/path
et obtenir comme résultat
/my/new/path/data

Merci @whi-tw pour la solution avec proot -b /path/i/wanted:./path_in_repo restic backup . - cela fonctionne pour moi.

Mon cas d'utilisation est la migration d'instantanés d'autres solutions de sauvegarde vers restic (Time Machine et images disque dans mon cas).

Je les migre d'où je monte l'image ou le sous-répertoire de l'instantané créé par TM, ce qui peut devenir très long, par exemple /Volumes/TimeMachine-Backups/Backups.backupdb/MacBook Pro/2019-05-22-185113/Macintosh SSD/ .

La solution cd fonctionne lorsque vous utilisez restic mount et restic restore , mais le chemin absolu de l'instantané d'origine est répertorié lorsque j'exécute restic snapshots .

Puisqu'il s'agit d'un instantané migré, j'aimerais que ce soit le chemin à partir duquel l'instantané d'origine a également été pris. En dehors de cela, avec les longs chemins, cela rend également la sortie de restic snapshots un peu bruyante.

Un indicateur pour définir un préfixe alternatif serait idéal pour moi aussi.

Cela fonctionne bien, et maintenant tous les instantanés ont le même chemin, sans cd ou pushd requis. De plus, le proot est disponible dans l'espace utilisateur, donc si les sauvegardes ne sont pas effectuées en tant que root, c'est toujours possible.

Cela aurait été une bonne solution de contournement, mais proot n'est pas disponible sur macOS et ne semble pas arriver de sitôt (la plupart du code écrit spécifiquement pour Linux) : est- ce que PRoot fonctionne sur MacOSX ?

Y a-t-il une autre solution de contournement qui vous vient à l'esprit?

Mon cas d'utilisation : vider les données de la base de données dans un répertoire temporaire, comme /tmp/tmpzmn28r02 (obtenu via mktemp ou mkdtemp() de python), puis les sauvegarder.
Cette méthode marquera tous les fichiers entre 2 instantanés comme étant différents.

Notez que les fichiers _sont_ probablement différents de toute façon ; les sauvegardes de base de données incluent généralement un horodatage dans les premières lignes.

Vous pouvez régler les commandes de vidage de la base de données pour exclure les commentaires dynamiques et être trié par clés primaires, mais pour rendre les données à évolution lente vraiment dédupables

Une mise à jour : 'proot' n'a fonctionné que sur une machine pour moi, sur une autre, il y a des erreurs de segmentation.
Une alternative (plus récente) - du papier bulle
Ajout d'un wrapper dessus (ci-joint) qui devrait fonctionner avec les mêmes paramètres '-b'. Cela semble fonctionner jusqu'à présent. Notez qu'en fonction de vos besoins et de l'emplacement des répertoires, vous devrez peut-être modifier un peu le wrapper.
J'espère que cela vous aidera les gars, mais j'attends avec impatience le soutien à l'intérieur de restic lui-même.

proot.sh.txt

J'ai essayé proot . Il semble interrompre la possibilité d'exécuter restic en tant que non-root avec des capacités supplémentaires (https://restic.readthedocs.io/en/stable/080_examples.html#full-backup-without-root); au moins, j'ai eu des erreurs scan: Open: open /.pulse: permission denied que je n'ai pas eues lors de l'exécution de restic sans proot .

Même problème avec bwrap .

Donc, pour moi, supprimer un préfixe de chemin dans restic lui-même semble toujours utile.

Cette fonctionnalité manquante rend plus difficile que nécessaire la sauvegarde des machines virtuelles.
Mes instantanés de VM se retrouvent dans un dossier temporaire et sont ensuite sauvegardés par restic.
Il en résulte ce qui suit :

ID        Time                 Host         Tags        Paths
--------------------------------------------------------------------------------------
02c536db  2020-04-10 14:28:27  resolver-02              /tmp/tmp.vOFFxxly9O/config.xml
c5709aed  2020-04-10 14:28:29  resolver-02              /tmp/tmp.vOFFxxly9O/sdb.img
a88cc1e7  2020-04-10 14:36:22  resolver-02              /tmp/tmp.FoY1j5JPIZ/config.xml
7c44e6ee  2020-04-10 14:36:24  resolver-02              /tmp/tmp.FoY1j5JPIZ/sdb.img
65456111  2020-04-10 14:37:48  resolver-02              /tmp/tmp.vjtI9JE3Iz/config.xml
eaced756  2020-04-10 14:37:49  resolver-02              /tmp/tmp.vjtI9JE3Iz/sdb.img
8eccec2c  2020-04-10 16:04:30  resolver-02              /tmp/tmp.YtLYRd0rNI/config.xml
34c897e1  2020-04-10 16:04:31  resolver-02              /tmp/tmp.YtLYRd0rNI/sdb.img
99b67b97  2020-04-10 16:07:53  resolver-02              /tmp/tmp.aWaEDqAaTq/config.xml
cad2c9d8  2020-04-10 16:07:54  resolver-02              /tmp/tmp.aWaEDqAaTq/sdb.img
--------------------------------------------------------------------------------------

Cela casse restic forget car il ne reconnaît pas qu'il s'agit du même fichier et conserve un instantané pour chaque instance. Je préférerais s'il y avait un moyen de supprimer un préfixe connu ou de ne stocker qu'un chemin relatif, pas absolu.
J'appelle déjà restic avec un chemin relatif et ching dans le dossier temporaire. Cela n'aide malheureusement pas et je préférerais ne pas avoir à utiliser de bindmounts pour cela.

Cela casse restic forget car il ne reconnaît pas qu'il s'agit du même fichier et conserve un instantané pour chaque instance.

Nous rencontrons également ce problème, mais la solution est assez simple : balisez chaque sauvegarde en fonction du ou des fichiers en cours de sauvegarde.

Par exemple, vous pouvez utiliser les balises config.xml et sdb.img ici. Ajoutez ensuite --group-by host,tags lors de l'exécution de restic forget .

Qu'est-ce qui rend cette fonctionnalité si difficile à mettre en œuvre ? Ne s'agit-il pas simplement du même filtrage de chaîne de base sur les métadonnées d'instantané ? La valeur qu'il apporterait est énorme. Oui, vous pouvez contourner le problème avec le balisage, mais il y a un champ de chemin et il pourrait être utilisable...

Qu'est-ce qui rend cette fonctionnalité si difficile à mettre en œuvre ?

En tant que développeur moi-même (pas de restic, mais d'autres projets open source) : ce n'est souvent pas la complexité d'une fonctionnalité qui empêche de l'implémenter, mais plutôt des choses banales comme le manque de temps, de motivation ou tout simplement la "vraie vie"...

Bien sûr, mon objectif n'était pas d'être critique, cherchant véritablement à cartographier la complexité pour les contributeurs potentiels

Salut à tous, j'ai commencé à travailler sur la mise en œuvre de cette fonction "racine personnalisée". L'implémentation elle-même était apparemment simple, même si j'ai dû apprendre le golang en ne connaissant que C #... Quoi qu'il en soit, j'essaie d'évaluer le type de support que ce problème a encore, vu que cela date de 2018, il y a 2 ans . Je m'engagerai bientôt sur https://github.com/TheRealVincentVanGogh/restic/tree/2092-feature-custom-path-prefix , si quelqu'un veut m'aider avec golang 😅. J'espère que bientôt plus tard, je mettrai une demande de tirage ici.

@TheRealVincentVanGogh Je ne vais pas apprendre Go, mais je suis toujours impatient de cette fonctionnalité et j'ai une tonne de sauvegardes que je veux toujours porter sur restic mais pour ce problème. Ouvrez un PR une fois que vous avez quelque chose qui semble fonctionner et publiez le lien ici, je vais vous prêter des tests intensifs

@TheRealVincentVanGogh Quel est le lien entre votre mise en œuvre prévue et le PR #2010 ?

@TheRealVincentVanGogh Quel est le lien entre votre mise en œuvre prévue et le PR #2010 ?

@MichaelEischer Oh, tire ! On dirait que quelqu'un m'a déjà devancé. Ouais, PR #2010 est exactement ce que je suis en train de... ré-accomplir... Merde. Peut-être que @cdhowie pourrait lier le PR #2010 à ce problème pour éviter toute confusion future ? Merci!

@themightychris Voici un lien vers ce PR . On dirait que le dev a également abandonné en 2018... curieux.

Éditer:

Il semble y avoir une certaine ambiguïté entre la suppression d'un préfixe de chemin du fichier d'instantané VS. suppression d'un préfixe de chemin de chaque structure de fichier + fichier d'instantané. On dirait que le PR #2010 ne traite que du premier . Étant donné que OP recherchait "supprimer ce chemin principal des chemins de tous les fichiers sauvegardés" (AKA, correction du chemin au niveau de la structure des fichiers), je dois retirer ce que j'ai dit sur le lien entre le PR # 2010 et ce problème . Désolé pour la mention cdhowie !

Néanmoins! @MichaelEischer Mes intentions ont toujours été d'obtenir une implémentation de découpage de préfixe de chemin d'accès au niveau de la structure de fichier et de l'instantané dans Restic (c'est une longue fonctionnalité/phrase). Je vais donc très probablement commencer à travailler sur cela à partir du code existant du PR #2010, ce qui devrait accélérer la mise en œuvre.

PS Je suis assez occupé de nos jours, donc le travail peut être lent pendant un certain temps ; bien sûr, je posterai un PR quand je pense avoir quelque chose à partager avec vous tous ! Restez en sécurité tout le monde ! ??