Use of bind-mount insteed of symbolic link

Discuss
, , ,
1

English bellow via deepl.

Bonjour,
Ce sujet a pour objet de proposer d’utiliser des bind-mount en lieu et place des liens symboliques pour stocker les données des applications dans un autre répertoire que /home/yunohost.app/$APP.

Une mésaventure m’est en effet arrivée.
J’avais constaté que les sauvegardes que je réalise via la commande CLI yunohost backup create ne suivaient pas le lien symbolique, réalisant des sauvegardes tronquées (type core_only). J’avais “corrigé” ce problème en modifiant le data_dir (ou datadir selon les apps) au moyen de la commande CLI yunohost app setting $APP data_dir -v /Monrépertoirededonnées.
Les sauvegardes contenaient alors les données au complet.

Seulement, un jour, j’ai eu besoin de restaurer une très volumineuse application. J’avais en principe l’espace nécessaire sur la partition système pour recevoir les /tmp/nécessaires à la restauration. Sauf que mon data_dir étant désormais incorrect le process de restauration a recopié en “provisionning” l’ensemble des données déjà là (en cas de pépin de restauration, je suppose, ne sais pas). La suite est un crash à 100% d’espace utilisé.

En discutant sur le support Matrix, nous avons découvert qu’en effet, le process de backup utilisé via la CLI ne suis effectivement pas les liens symboliques, et que c’est un fonctionnement cohérent.
on m’a conseillé d’utiliser des bind-mount en lieu et place des liens symboliques.

J’ai procédé au changement sur plusieurs de mes applications (pas fini encore, mais le concept est validé selon moi).

présentation de comment j’ai procédé

D’abord un peu de renseignements sur ce que c’est :
Understanding Bind Mounts
et comment le mettre dans /etc/fstab pour que tout soit monté durant le boot:
How do I do ‘mount --bind’ in /etc/fstab?

En supposant que les données sont déjà dans /autreemplacement

  1. Arrêt des services de l’application ou passage en mode maintenance pour éviter des accès pendant les manipulations.
  2. suppression de lien symbolique dans /home/yunohost.app/$APP/par la commande rm home/yunohost/$APP/monliensymbolique (la commande rm ne suivra pas le lien et ne supprimera pas vos données vers lesquelles le lien pointe).
  3. création du répertoire /home/yunohost.app/$APP/data (ou uploads, ou autre dépend de l’application)
  4. attribution des droits corrects pour cette application (peuvent être trouvés dans les scripts install du github de l’app-ynh)
  5. Montage du bind-mount (je le fais en ligne de commande d’abord pour tester) comme ceci mount --bind /autreemplcement/data/ /home/yunohost.app/$APP/data/
  6. redémarrage des services de l’application et teste si tout fonctionne.
  7. si tout est OK, je reporte dans /etc/fstab le montage de mon bind-mount: /autreemplcement/data/ /home/yunohost.app/$APP/data/ none defaults,bind 0 0 ainsi à chaque boot, les montages seront faits.

Puisque j’avais fait la bêtise de modifier le data_dir de l’application, j’ajoute un point 5bis) pour remettre la valeur correcte: sudo yunohost app setting $APP data_dir -v /home/yunohost.app/$APP/

Voilà, faites moi part de vos idées, remarques, interrogations, …

English version:

Hello,
The purpose of this topic is to suggest using bind-mounts instead of symbolic links to store application data in a directory different from /home/yunohost.app/$APP.

A misadventure happened to me.
I had noticed that the backups I made using the CLI command yunohost backup create did not follow the symbolic link, resulting in truncated backups (core_only type). I had “corrected” this problem by modifying the data_dir (or datadir depending on the app) using the CLI command yunohost app setting $APP data_dir -v /MydataDirectory.
The backups then contained all the data.

One day, however, I needed to restore a very large application. In principle, I had the necessary space on the system partition to receive the /tmp/ necessary for restoration. Except that my data_dir was now incorrect, and the restore process “provisioned” all the data already there (in case of a restore glitch, I suppose, don’t know). The result is a crash with 100% space used.

Discussing this with Matrix support, we discovered that, indeed, the backup process used via the CLI does not follow symbolic links, and that this is a consistent practice.
I was advised to use bind-mount instead of symbolic links.

I made the change on several of my applications (not finished yet, but the concept is validated in my opinion).

presentation of how I went about it

First a little background on what it is:
Understanding Bind Mounts
and how to put it in /etc/fstab so that everything is mounted during boot:
How do I do ‘mount --bind’ in /etc/fstab?

Assuming data is already in `/otherlocation

  1. Stop application services or switch to maintenance mode to avoid access during manipulation.
  2. remove the symbolic link in /home/yunohost.app/$APP/ using the command rm home/yunohost/$APP/mysymlink (the rm command will not follow the link and will not delete your data to which the link points).
  3. create the directory /home/yunohost.app/$APP/data (or uploads, or whatever depends on the application)
  4. assign the correct rights for this application (these can be found in the install scripts on the app-ynh github)
  5. mount the bind-mount (I’m doing it on the command line first, to test) like this mount --bind /otherlocation/data/ /home/yunohost.app/$APP/data/
  6. restart application services and test if everything works.
  7. if everything’s OK, I enter my bind-mount in /etc/fstab: /otherlocation/data/ /home/yunohost.app/$APP/data/ none defaults,bind 0 0 so that at each boot, the mounts will be done.

Since I’d made the mistake of modifying the application’s data_dir, I’ll add a point 5bis) to restore the correct value: sudo yunohost app setting $APP data_dir -v /home/yunohost.app/$APP/.

Here you go, let me know your ideas, comments, questions, etc.

2 Likes
2

Tu parles du backup YNH si j’ai bien compris, est ce que tu sais si les backup réalisés via borg sont aussi concernés par ce comportement ?

J’utilise borg sur un SSD externe via un symlink, les logs des saves sont nickels et j’ai déjà testé de restaurer une app sans aucun soucis mais je m’inquiète pour les apps plus volumineuses et bien plus critiques dont je n’ai pas envie de tester régulièrement la restauration à plusieurs dizaines de Go (:sweat: nextcloud)

4

Le seul problème que je vois avec la méthode du bind, outre les ratés entre un dossier monté ou pas monté (dans les deux cas il existe, parfois on oublie…), c’est que certaines mises à jour d’application échouées peuvent ne pas se restaurer automatiquement, car le répertoire cible du “bind” ne peut pas être supprimé, donc la suppression de la mise à jour erroné ne se complète pas, donc pas de restoration possible.
Et dans ces cas, je n’ai pas trouvé de méthode pour restaurer sans supprimer temporairement le bind, donc il faut avoir sur le système de fichier d’origine (généralement /) assez de place pour restaurer…

5

Tu peux monter une sauvegarde Borg (donc sans l’extraire) pour vérifier son contenu :wink:

1 Like
6

Mon souci est venu du fait que j’avais modifié le app setting data_dir pour mettre mon répertoire sur mon SSD et avoir des sauvegardes consistantes malgré le non suivi des symlink.
Tes sauvegardes, si elles font des gigas et des gigas, elles contiennent tes données, sans que tu aies eu besoin de modifier le data_dir.
à priori, tes sauvegardes sont OK, de ce point de vue.

7

Du coup, il faudra que je restaure moi-même le pre-upgrade en cas de plantage de mise à jour.

1 Like
8

To elaborate for future readers (and excuse for stating the obvious if that is the case :wink: ): the problem Catslover71 describes is not writing a backup to a symlinked location (as in the case of Aristid).

If there is a symlink in the directory to be backed up, Yunohosts backup mechanism seemed not not to recognize it as such. It will create the backup as if it is all one contiguous directory/partition.

The data is also secured: all data (including the data in the symlinked directory) is backed up.

The problem only would arise when restoring the backup: because the symlinked directory is not restored as [symlink + directory on other partition], but as [directory in the same partition], the risk arises that restoring the backup fills the whole partition (because the large datadir was expected to be restored, via symlink, on a partition on external storage, for example).

Edit: rephrased a bit because of Aleks’ post below; while trying to reproduce the behaviour, things worked out well enough.

I run Borg as well, and had a look but I have no symlinks in my backed-up directories, so I did not have a test case at hand.

To follow Lapineige’s advice, you can look into the backed up files without restoring them by using borg mount. I got my backups in /backup/borg/, and created a mountpoint /backup/mountpoint to mount the backups and inspect them using:

# borg mount /backup/borg /backup/mountpoint

After that, you can run ls -l /backup/mountpoint/_backup_that_interests_you and if there is a symlink, it wil start with l (instead of d or ), and -> point to the destination.

4 Likes
9

Uuuuuh are you positive about this ? I was discussing yesterday with @CatsLover71 on the chat and and actually ended up trying to reproduce the behavior of yunohost which use’s python’s tarfile lib and adding a symlinked directory in the archive result in … having literally the symlink in the archive, not the pointed content

This may be different with other tools like borg though

2 Likes
10

Thank you @Aleks
That’s consistent (even if it’s not obvious) with what I experienced. I don’t remember very well the date I started to modify the data_dir parameter, but I’d not be surprised if it happened after the use of compressed archives (so with Python tarfile).
And sorry if I’m not elaborated enough, Yunohost is a for all tool, not expert only and that’s the beauty of it (as long as there is no disdain from experts).

By the way @Aleks, I reviewed my opinion about cluster and so on (remember, you asked yourself why do people want to do complex stuff). I gonna do simple for everybody. I hope to progress and be able to contribute to this wonderful tool.

1 Like
11

Sorry, I focused on writing out the difference between (worries about) archiving a backup to a symlinked location versus restoring an archive that had symlinks in it, and did not test or experience the behaviour myself.

I’ll edit my post to reflect that!

2 Likes
12

J’ai trouvé un lien qui détaille un peu les pro/con des bind-mount.
Voici : StackExchange - Are there any drawbacks from using mount --bind as a substitute for symbolic links?
Si vous souhaitez investiguer ce point.

Jusqu’ici cela fonctionne pour moi et règle le souci. Par contre, je constate un ralentissement marquant de mes sauvegardes de Peertube.

1 Like
13

Le bind est fait sur le même système de fichier / support de stockage ? Ou sur un autre support de stockage ?

14

Non, le bind est sur un disque SSD SATA (le disque système) alors que le répertoire de données cible est sur un NVMe (pas tout à fait un vrai car via adaptateur ORICO sur USB3.0)

15

J’ai survolé la discussion tout en pensant à un autre use case : je gère un site Web hébergé chez un shared host provider. La sauvegarde cpanel n’est pas top. En lisant le premier message, je me suis dit qu’il était possible de monter le site distant sur une webapp (avec curlftpfs).
Mais le point de montage ne sera pas géré par yunohost. Donc la mise à jour et la restoration vont certainement rencontrer des erreurs puisqu’il n’y a pas de fonction monter/démonter dans les scripts correspondants.
L’idée est intéressante d’intégrer la gestion des montages dans les scripts surtout pour les applications qui peuvent avoir de gros volumes de données, ou même dans la webadmin. Reste à penser comment ça devrait être.

1 Like
16

Et quand tu fais une écriture dessus, il y a un ralentissement ?

17

Je ne sais trop te répondre. Comment faire le tests ? As-tu des commandes à me suggérer et des paramètres à surveiller ?
NB: je n’ai plus d’autre outil de supervision que htop actuellement.

18

Si tu copies un gros fichier sur le bind mount par exemple ?
Ça peut se tester avec un outil pour mesurer les perfs, par exemple avec la commande dd (attention, usage risqué en cas d’erreur).

19

Just to let you know.

My Bind-mount is not convenient and positively conclusive.

I passed my wool /home on the NvMe drive on an ext4 partition. And everything is better.

So an install with self partitioning for me for the next yunohost install. definitely easier.

Sorry not having been able to debug more this Bind-mount, but this is my “production” server, I can’t play to much.

Thaznk you all, anyway.

Regards.

1 Like