Reprise du message précédent :
un pour tous si possible

 
n330 arrêtes tu me fait rêver avec toutes cette puissance: dual core  

dans ce cas, normalement, tu montes une VM avec passtrough sur tes disques en RAID, et les autres VMs y accèdent par un partage réseau...

Avec Xen on peut créer un RAID soft dans le Dom0 (domaine privilégié) et ensuite l'utiliser comme disque pour les VM.
 
Je sais pas si c'est possible avec ESXi.

Sinon SmartOS semble parfait pour ce genre de cas.

je préfère ma méthode, ça permet un montage des VMs dans des répertoires séparés et éviter des risques de propagations d'erreurs...

 
qu'est-ce que tu entends exactement par « propagation d'erreurs » ?

simple...
tu fais un "rm -R", tu perds tout y compris ce qui est des autres VMs, si tu verrouilles par rapport à des répertoires sur un partage fichiers, c'est un soucis que tu n'as pas....

Ah mais c'est pas ce que je voulais dire Je parlais d'utiliser le RAID soft dans le Dom0 pour y stocker les disques des VM. Après libre à toi dans chaque disque de VM de faire l'usage souhaité : partage de fichier, serveur web, peu importe.

edit : et généralement on fait ça dans du LVM, donc pas de risques de merder dans le Dom0 (d'ailleurs, le Dom0 faut jamais s'y connecter sauf pour des MAJ)

moui vu comme ça...

ceci dit, perso, pour une machine perso, j'évite les VMs.

Plam, tu peux également utiliser proxmox au lieu de xen pour gérer ton raid soft.

Quoiqu'il en soit, un peu de LVM comme tu le dis pour gérer la taille des disques plus facilement.
Et une petite VM xpenology si tu veux te simplifier la vie avec les "fonctions NAS".

Je vais peut-être m'orienter sur ça quand je ferai mon NAS. C'est une solution qui évite d'avoir besoin de VT-D (parfait pour une petite CM itx C2750).

quelqu'un à déjà essayé la version autonome d'hyper-v ?
(Hyper-V Server 2012 R2) apparemment c'est gratuit
 
http://technet.microsoft.com/fr-fr [...] 05299.aspx

 
C'est tout à fait possible, mais niveau perfs et possibilités de virtu, ya pas photo avec Xen. Et puis maintenant ya une interface web pas dégueux

Tu aurais plus de détails de ce que tu avances ?
Pour ma part je n'utilise que xen pour l'instant.

Bah si on compare perfs/maturité/features, Xen > containers (proxmox). Après avec KVM (que peut aussi faire proxmox) c'est plus une comparaison sur la façon dont ils sont architecturés (Xen est plus élégant dans son archi globale, niveau perfs ils sont au coude à coude, enfin reste à voir avec le PVH de Xen qui à l'air de bien déboiter).

Mais ya pas de « meilleur » dans l'absolu, ça dépend des besoins de chacun Et puis je connais bien Xen il faut dire, vu que je bosse depuis quelque temps sur une interface web

Oh, une IHM web pour Xen ?    
/me ajoute ça dans la TODO-list sans fin des trucs qu'il serait bien d'ajouter sur son pitit serveur.

 
Xen + XAPI  
 
Donc présentement XenServer, Debian + paquets xapi ou Centos + paquets xapi.

J'utilise Seafile depuis quelques mois pour avoir mon propre dropbox-like. Le seul inconvénient que je vois est que seafile utilise son propre système de fichier qui tourne, dans mon cas, sur un FreeNas ZFS avec un partage réseau.  
 
J'aimerai pouvoir ajouter une vérification des données pour garantir l'intégrité et être sur que les données que j'envoie lors de mon backup ne sont pas corrompues.
 
Est-ce que certains d'entre vous ont déjà des solutions pour garantir l'intégrité lors des transferts de données entre les différents services ou disques réseau ?
 
Je pensais soit à un checksum ajouté comme metadata sur chaque fichier soit avoir une application de type quickpar qui surveille les dossiers que je veux et qui créé un fichiers de récupération pour chaque fichier dans mon arborescence. Est-ce que cela vous semble possible ?

Moi j'utilise un script de sauvegarde de mon Linux qui vérifie l’intégrité du backup avec une simple somme MD5.

Je comprends pas bien ce que toi tu veux faire (l'histoire du cloud perso ?). Le backup c'est quoi: un backup d'un dataset ZFS vers une autre machine? Un sauvegarde en USB ?  

J'ai l'équivalent de dropbox sur mon serveur perso. Toutes les données des PC "clients" sont synchronisées avec cette outil. J'aimerai que lorsque ces données sont envoyées vers le serveur, un checksum du fichier calculé sur le PC client soit également envoyé vers le serveur.
 
Ca me permettrait d'être sur que le fichier enregistré sur le client ne soit pas corrompu d'une façon ou d'autre lors de l'envoi sur le serveur.

A mon sens cette vérification est forcément au niveau de l'application de synchronisation, tu peux toujours en plus rajouter un scipt cron qui fait cette comparaison, mais en définitive, imagine qu'un fichier devienne corrompu sur ton serveur, dans la seconde qui suit il sera synchronisé corrompu sur tous les clients par ton appli de cloud.  
 
A la limite je serai toi, je ferai un snaphot toutes les heures du dataset synchronisé sur le serveur Freenas avec une durée de rétention de deux semaines par exemple, et un plus long (hebdomadaire par exemple avec une rétention illimitée). Ainsi si tu t’aperçois d'une corruption, tu as juste à restaurer avec le snapshot qui va bien.
 

Seafile gère l'historisation nativement... Reste à voir ce que ça donne en cas de corruption.

Du côté serveur, avec freenas, zfs et la ram ecc, je me dis que le risque de corruption est très faible. Par contre côté client, le fichier pourrait très bien être corrompu et envoyé sur le server sans que je sois au courant.

Le fichier est corrompu sur le PC client, c'est le même risque que la suppression/écrasement/édition accidentel, c'est là que la sauvegarde a son rôle, le contrôle du checksum est une fausse solution à un faux problème..

C'est pas une fausse solution, c'est pas un faux problème. C'est juste pas la bonne solution à ce problème là  

Au final la seule vrai réponse est ZFS non ? Avec une garantie de l'intégrité niveau fichier. (Les autres RAID, c'est juste niveau disque, pas fichier)

Bonjour à tous,
 
 
Je souhaite migrer mon stockage (pc, usb) vers un solution de type NAS, et pourquoi pas "homemade". L'idée m'est venu en découvrant ce topic, et après avoir vu le prix des solutions "clé en main" type qnap ou synology. A savoir que je dispose déjà de matos :
 
- cpu core2 duo (E6600 mais je peux le remplacer par un E4300)
- carte mère micro ATX
- 2go de RAM
- alimentation 300w
- disques durs 3.5" à la pelle
 
Reste à trouver un boîtier.
 
Ça s'engage bien, surtout financièrement , mais malgré tout, quelques interrogations me trottent dans la tête.
 
- Ce type de NAS maison peut-il se mettre en veille, et être sorti de veille facilement et rapidement lorsqu'il est sollicité? J'imagine que cela dépend de l'OS installé et de la gestion de la veille par la CM?
- La consommation électrique n'est-elle pas trop élevée comparé à une solution commerciale?
 
Merci pour vos avis

Perso mes serveurs sont toujours allumés H24.
 
Pour la conso, voilà ce que donnait mon ancien NAS :  

 
Au final sur l'année, même allumé H24, ça représente pas grand chose.

 
Ben non, pour moi ça n'a aucun rapport.
 
Le gars s'inquiete de la corruption du fichier au niveau client, et comme dit plus haut, on s'en fout un peu, la corruption au niveau du client, c'est la même problematique que l'écrasement accidentel, la modification ou la suppression accidentelle, c'est le role de la solution de sauvegarde; les tests d'intégrité lors du transfert, raid etc n'ont aucun poids, aucun interet pour ce genre de question.

Non la sauvegarde ne répond pas à mon problème. Ce que je souhaite c'est pouvoir vérifier que les données que je sauvegarde ne sont pas corrompues. J'aimerai pouvoir être sur que si j'ai besoin d'accéder à un backup pour récupérer un fichier supprimé, celui-ci ne soit pas corrompu.
 
En gros j'aimerai compléter la sécurité de ZFS avec un checksum sur toute la chaîne. J'ai donc trouvé quelques outils que je vais tester pour générer un hash pour chaque document important sur le poste client. Ensuite, avant chaque sauvegarde, je vais régénérer ces hash sur le serveur et les comparer avec ce qui a été envoyé par le client.

Dans ce cas, tu vas simplement valider qu'il n'y a pas de corruption pendant le backup.  
Mais si le fichier est corrompu sur ton poste client, tu génèreras le hash d'un fichier corrompu ...

 
 
Oui mais pourquoi tu focalises sur cette histoire de corruption ? c'est ce que je ne comprends pas du tout. la corruption lors du transfert est gérée par le soft de transfert, donc si la "corruption" est en amont, sur le PC client, ton serveur n'a aucun role à jouer là dedans, c'est la même problematique que l'écrasement accidentel, la modification ou la suppression accidentelle, un truc pour tester l'intégrité ou autre ensuite lors du transfert n'a pas le moindre interet
 

 
Voila, exactement

un logiciel de sauvegarde n'a AUCUN moyen de savoir si un fichier sur le disque est corrompu ou pas.
toi seul en ouvrant le fichier et en le visualisant / utilisant peut dire si un fichier est corrompu ou non.

La où je travaillais avant (maintenant les backup ne sont plus dans mes fonctions), les sauvegardes, c'étaient toujours copie + comparaison bit à bit. mais si les données d'origines sont non fiables...

Sauf si tu as un checksum de ton fichier sur toutes la chaîne (depuis sa création sur le pc client jusqu'à son stockage sur le disque du serveur). Et ce que je teste en ce moment.

 
Ben non
 
Chaque modification faite sur le fichier changera le checksum, tu n'as aucun moyen de faire la différence entre une modification faite par l'utilisateur, ou une corruption éventuelle
 
A moins que ton fichier ne soit absolument jamais modifié, du coup l'interet d'en faire une copie sur le serveur regulierement est absolument nul.
Ou que tu demandes à l'utilisateur de valider manuellement le checksum chaque fois qu'il fait une modification volontaire dessus.. si tu as des utilisateurs prêt à s'emmerder à faire ça, garde-les précieusement, il n'en existe pas beaucoup.
 
Le controle du checksum est utile dans le cadre d'une copie, pour comparer un fichier avant sa copie, avec le nouveau fichier à l'arrivée. sorti de ça, ça ne sert à rien, personne ne comprends ta démarche. Ou alors tu n'as pas compris comment marche le checksum, c'est pas un truc magique qui te donne la santé d'un fichier, c'est juste un truc qui sert à verifier qu'après le transport le fichier est toujours identique à l'original, rien d'autre

Chaque modification qui passe par le système de fichier uniquement générera un nouveau calcul de checksum. Si c'est une corruption (erreur disque, ram ou autre), la date de modification du fichier sera inchangée et l'outil ne générera pas un nouveau checksum.  
 
Le fichier sera donc synchronisé sur le serveur avec son ancien checksum et lors du backup le serveur va comparer calculer le checksum du fichier et voir que ça ne correspond pas avec le checksum qui était enregistré -> corruption.

On en revient a ce que je disais plus haut : et ça sert a quoi ?  
 
Tu es en train de mettre en place une usine a gaz, pour contrer un cas hyper specifique qui doit arriver tous les 32 du mois, alors qu'avec une simple gestion des sauvegardes, tu couvres ce cas hyper spécifique ainsi que les 8535 autres façons de perdre un fichier en même temps.
 

tu as des putains de virus qui changent les fichiers SANS modifier le checksum.
donc un fichier peut facilement être corrompu SANS que le checksum ne change, hélas pour toi...

Non, mais relis, ça fait partie des 8000 façons de perdre un fichier sont ils se fout, lui il veut juste prevenir le cas hyper frequent de corruption de fichier que tout le monde a au moins quinze fois par jour, qui est l'erreur disque/ram
 
Les virus et les mauvaises manipulation des utilisateurs sont quand à elles des sources de problèmes négligeables