Comment augmenter la capacité de stockage de YunoHost?

Support
1

C’est une question, qui, étonnamment, n’a pas encore été soulevée pour YunoHost.
À moins que je sois passé à côté (ce qui peut être le cas).

En effet, à un moment ou à un autre, la question va se poser, surtout si OwnCloud a été installé, et est utilisé par de nombreux utilisateurs, ayant chacun beaucoup de données à sauvegarder.
C’est en particulier le cas quand OwnCloud est utilisé via webDAV pour sauvegarder un système complet de fichiers par exemple.
C’est aussi le cas lorsque le serveur sert à stocker/archiver ses photos et/ou ses films/vidéos.

Remarque : cette question en appelle forcément une autre : comment le serveur YunoHost est-il sauvegardé ? Mais c’est une autre histoire.

On peut bien-sûr avoir prévu le coup, avec un DD partitionné, dont on n’aurait pas utilisé toute la capacité. Dans ce cas, il faudrait redimensionner les partitions, etc … Ou alors, si il reste de la place, créer une nouvelle partition.

Mais alors, comment intégrer cette nouvelle partition dans la capacité de stockage ?
On en revient à la même problématique si on rajoute un DD : comment va-t-on intégrer la nouvelle capacité de stockage ?

Linux a ceci d’extraordinaire que le système peut être étendu grâce à de nouveaux systèmes de fichiers ou à de nouveaux services, et ce, en live.

En faisant des recherches sur internet, j’ai trouvé plusieurs choses intéressantes :

Toutes ces solutions permettent de fusionner certains points de montage, voire certains répertoires sur des partitions différentes, et même combiner le tout.

Pour moi, la palme revient à mhddfs.

Je vous encourage vivement à aller visiter les pages relatives à chacune de ces solutions pour vous faire votre opinion, et compléter cette page si vous avez d’autres tuyaux intéressants et fonctionnels, simplement.

Remarque : il n’existe pas, à ma connaissance, de pages relatives à mhddfs écrites en français.

Bonne découverte, et merci de poster vos opinions.

2

Bonsoir,

Pour ma part j’utilise une solution plus basique mais qui, pour l’instant, me convient. J’ai un petit HDD sur mon serveur Yunohost car celui-ci ne contient rien si ce n’est la distribution ainsi que les téléversements instantannés de photos et de vidéos opérés par l’application mobile Owncloud. Pour le reste, ce sont des partages SAMBA de mon NAS qui sont montés via l’interface Owncloud de Yunohost. Le NAS est en RAID 1.

Ainsi, j’accède, depuis mon poste, à mes données en SAMBA lorsque je suis chez moi et ce directement depuis le NAS. Lorsque je suis à l’extérieur, j’atteinds le NAS par l’intermédiaire de Yunohost en WEBDAVS. Cela me permet de n’avoir que le port 443 d’ouvert et de laisser Yunohost gérer la sécurité plutôt que mon NAS. Sur ce point, je fais plus confiance à Yunohost qu’au fabricant de mon NAS qui sort une mise à jour de son firmware une à deux fois par an au grand maximum.

En somme, le NAS a pour rôle d’assurer l’intégrité physique des données en assurant leur redondance tandis que le serveur Yunohost gère leur sécurité en contrôlant les accès depuis l’extérieur et fournit les applications.

J’ai bien conscience des failles de mon système, notamment le fait qu’il n’y ait pas de redondance pour les autres applications Yunohost, notamment les mails, le calendrier et les contacts. C’est pourquoi je vais suivre avec intérêt ce topic et explorer les solutions que tu proposes.

Edit (10/01/2015 - 23:51) : Après plusieurs mois d’utilisation, cette méthode fonctionne vraiment très bien. Cependant elle a un gros défaut, qui peut facilement être pallié, qu’il faut bien avoir à l’esprit avant de la mettre en oeuvre à défaut d’avoir une drôle de surprise au bout de quelques mois. C’est pourquoi, je vous invite vivement à consulter ce sujet avant toute mise en application.

3

Bonjour,

Je suis très intéressé pour connaître la position de l’équipe de dev de YunoHost sur ce sujet.

Merci de nous faire partager votre vision à ce propos, car c’est toujours constructif.

4

La base est sauvegardée via ces scripts: https://github.com/YunoHost/moulinette-yunohost/tree/master/hooks/backup
Le reste sont des scripts à écrire pour chaque paquet.

J’avais intégré udiskie fut un temps. Visiblement il ne fonctionne plus, mais le principe était celui-ci : dès que le démon udiskie voyait un nouveau volume arrivé, il le montait dans /media. Et /media est accessible via owncloud. Du coup, quand ça fonctionnait, il suffisait de brancher une clé USB au serveur (ou un nouveau DD), et celui-ci apparaissait dans OwnCloud.

Ce n’est probablement pas la meilleure manière de gérer ça, le mieux serait bien sûr d’avoir un onglet de gestion des disques dans l’admin YunoHost, mais ça faisait le boulot.

Il s’agit maintenant de le remettre sur pied.

Jolie découverte en effet. A voir s’il est raisonnable de l’intégrer.

5

Ici, il est question d’augmenter la capacité de stockage d’OwnCloud. Et ce n’est déjà pas si mal.
Dans le principe, udiskie est plutôt séduisant. Dommage qu’il ne fonctionne plus.
De même, la procédure de @YGLG pour accéder à son NAS au travers de OwnCloud est très intéressante.

Ma vision, ou plutôt mon besoin est plus global, et non restreint à OwnCloud et l’extension de sa capacité.

Ce que je cherche est d’étendre la capacité de stockage de YunoHost quand le DD arrive à saturation. Dans ce cas, si RoundCube est installé, ou une autre app nécessitant de stocker des fichiers (en plus ou moins grande quantité et de plus ou moins grande taille) sur le DD, si celui-ci arrive à saturation, il devient impossible d’utiliser YunoHost dans sa globalité.

Que faire alors ?

Amahi (Stream and share your audio and video collection to your devices and screens. Centralize your backups and easily run webapps and media apps like a pro! qu’ils disent …) par exemple utilise la technologie Greyhole (Disk Pooling). Cette technique semble présenter quelques inconvénients, que mhddfs n’aurait pas et qu’il remplacerait avantageusement.

J’ai testé mhddfs en fusionnant une partition montée à chaud (dans /media/dd1 par exemple) avec un répertoire existant tel que /var (qui par ailleurs pourrait être le point de montage vers une partition spécifique). Tous mes tests (montage, lecture, écriture, démontage, …) ont réussi avec succès.

On pourrait imaginer de fusionner /var et /home (puisque ce sont ces deux répertoires qui stockent les données utilisateur, ce qui nous intéresse) avec autant de partitions que l’on veut (ou dont on a besoin), et ce de façon automatique à la détection d’un nouveau DD ou d’une nouvelle partition, en proposant d’étendre automatiquement la capacité à la fois de /var et de /home, ou bien en détectant automatiquement quel répertoire a besoin de plus de capacité.

J’ai la sensation que cela permettrait d’économiser beaucoup d’énergie pour mettre au point un système fiable, puisque tout est déjà fonctionnel, et que le démontage de ce type de système préserve les fichiers dans leur hiérarchie de stockage.

Si on ajoute, à chaque besoin supplémentaire en capacité de stockage, un double DD monté en RAID 1, et qu’on a un système de sauvegarde automatique par synchronisation, on peut obtenir le système presque parfait qui s’étend à l’infini (presque) et qui se synchronise/sauvegarde tout seul (presque).

Petit partage d’infos et de liens sur la synchronisation de fichiers (après recherches approfondies sur le net) : à une époque, j’utilisais un démon java (webdav_sync) pour recopier automatiquement sur mon OwnCloud via webDAV les fichiers modifiés ou ajoutés en temps réel. C’est aussi ce que permet de faire le démon hubiC ou le démon Mega, ou bien Copy, de façon beaucoup moins libre (mais que j’utilise en permanence - je parle d’hubiC et de Mega). De la même façon, il y a Pulse (anciennement Syncthing, avec son interface graphique sous Ubuntu) et son pendant non libre BitTorrent Sync.

6

Bonjour,

Je ne sais pas si ma réponse convient mais pourquoi ne pas utiliser LVM ?
Lorsque tu ajoute un nouveau disque tu peux étendre le volume logique.

Personnellement c’est ce que j’utilise, lorsque j’en aurai besoin je pourrai étendre le point de montage.

7

LVM serait une excellente solution si nous avions la main sur le partitionnement. Or YunoHost est agnostique de ce côté-là, donc ce n’est pour le moment pas envisageable.

8

De l’évolution de ce côté ci? Car actuellement pour mes test et mon petit serveur actuel, tout fonctionne mais il est envisagé de rapidement pouvoir étendre l’espace disque ^^

9

Rien pour le moment, mais toute recherche ou test à ce sujet est le bienvenu :blush:

10

Bonjour intrigué par cela;
voici ce que je teste présentement

à partir d’une installation fraiche de Wheezy
j’ai créé un LVM pour /srv
formater en XFS puis
puis monté avec les options : nosuid,noexec,nodev
créé des liens pour home et www
ln -s /srv/home /home
ln -s /srv/www /var/www

et ensuite installé yunohost

j’ai également migré /home et /var/www dans /srv d’une installation existante
Je vous tiens au courant des dommages et intérêt :slight_smile:

11

Excellent.

Je pense que si nous devons intégrer un outil pour simplifier l’ajout de support de stockage, nous le ferons définitivement avec LVM :slight_smile:

1 Like