Forum Linux.général rsync et mode bloc

Posté par Philippe M (site web personnel) le 25 septembre 2013 à 16:41. Licence CC By‑SA.

Étiquettes : aucune

sept.

2013

Bonjour,

j'utilise très souvent rsync pour faire du backup (avec un petit script maison pour gérer la rétention). Le problème est que j'ai besoin d'externaliser mes sauvegardes sur un serveur distant pendant la nuit, j'ai une connexion fibre en 6M dans les deux sens mais, car il en faut un, j'ai tout les jours au minimum 120Go de données à déplacer de tout types… Oui 120Go qui bouge tout les jours pour un volume total d'environ 800Go.

rsync transfert que la différence des fichiers modifiés mais même dans ce cas ce n'est pas suffisant donc je regarde auprès des différentes solutions sur le marché et revient souvent la notion de transfert en mode bloc. Est-ce la même chose que ce que propose rsync, si non pensez-vous que ça pourrait régler mon problème de délai de transfert ?

En principe quand je vois ces sociétés lorsque j'aborde la question de l'estimation du délai de transfert de mes 120Go aucun ne répond et bizarrement je n'ai plus de nouvelles d'elles après le rdv même si il était question qu'on fasse un chiffrage/test…

Comment faite vous ?

# 120Go reste 120Go

Posté par NeoX le 25 septembre 2013 à 17:07. Évalué à 2. Dernière modification le 25 septembre 2013 à 17:19.

si tu as 120Go qui changent tous les jours, tu auras toujours 120Go à transferer tous les jours.
avec un peu de chance, tu as effectivement 120Go de fichiers modifier mais avec son algo rsync en transfert beaucoup moins

en effet rsync decoupe le fichier en troncons, et n'envoie que les troncons qui ont changé.
ca doit etre cela qu'on appelle le mode bloc (chez rsync)

attention, il a surement aussi des outils qui attaquent directement le disque (au niveau hardware) plutot que le filesystem pour faire le backup, là aussi ils peuvent parler de sauvegarde en mode bloc (mode secteur)

par contre regarde du coté des options de rsync ou de ssh car si comme moi tu fais du rsync au travers de ssh, la partie cryptage de la communication pour ssh prend un peu de temps, ca doit valoir le coup de faire un transfert via ssh mais sans cryptage ou avec un cryptage plus leger.

sinon quelques chiffres en supposant que tu sois tout seul sur ta ligne à 6Mbps et donc que tu l'utilises à fond :
120Go à la vitesse de 768Ko/s (6Mbps)
ou
983040Mb à envoyer 6Mbps => 163840sec => 45h

bref, à part faire une sauvegarde locale et partir avec le disque chez toi
ou booster ta connexion reseau à 100Mbps (2,73h, soit 2h45)

je ne vois pas trop comment transferer 120Go sur 6Mbps
# Astuce

Posté par jben le 25 septembre 2013 à 17:57. Évalué à 3. Dernière modification le 25 septembre 2013 à 17:58.
Juste une astuce, je ne sais pas si elle s'applique à ton problème.

Tu parles de déplacement de fichiers, et dans ce cas rsync refait un transfert du fichier, il n'a pas vu que c'est le même.

Par exemple, un répertoire nommé dossier/, synchronisé sur serveur:dossier/.

Initialement on fait
```
rsync -a dossier/ serveur:dossier/
```
Puis un jour on veut faire un déplacement de fichier, on fait :
```
mv dossier/fichierA dossier/fichierB
rsync -a dossier/ serveur:dossier/
```
Et là c'est le drame. Il retransfère le fichierB.

L'astuce c'est d'utiliser l'équivalence entre mv a b et ln a b; rm a, mais on va rajouter un rsync entre les deux.
```
cp -al dossier/fichierA dossier/fichierB
rsync -a dossier/ serveur:dossier/
rm dossier/fichierA
rsync -a --delete dossier/ serveur:dossier/
```
J'utilise cp -al et non ln, car ça permet de conserver les permissions et de faire le machin recursivement pour un répertoire si c'est un répertoire qui est bougé.

Et comme ça, ça passe très bien, il detecte que fichierA et fichierB sont des hard link, il crée fichierB comme un hard link sur fichierA dans la destination, et à l'étape suivante il supprime fichierA.

Alors je ne sais pas si c'est de ce type de déplacement dont tu parles, mais c'est une astuce à connaître quand on utilise rsync.
- [^] # Re: Astuce
  
  Posté par BuckFuck le 25 septembre 2013 à 20:49. Évalué à 1.
  
  Unison ? Il gère très bien le déplacement de fichiers… Par contre, il faut s'assurer d'avoir la même version (avec les mêmes libs).
- [^] # Re: Astuce
  
  Posté par Philippe M (site web personnel) le 26 septembre 2013 à 10:05. Évalué à 0.
  
  Au début j'utilisais cp -al mais j'ai découvert l'option --link-dest de rsync qui reproduit le même comportement, ça évite une étape.
  
  Born to Kill EndUser !
  - [^] # Re: Astuce
    
    Posté par jben le 26 septembre 2013 à 11:52. Évalué à 2.
    
    Tu remarquera que ce n'est pas du tout ce que je propose. Là tu parle de faire de la sauvegarde en gardant les version précédentes et en stockant les fichiers identiques via un hard link sur le même fichier. Moi je parle de faire un déplacement dans le répertoire qui est sauvegardé sans retransférer les fichiers.
- [^] # Re: Astuce
  
  Posté par wismerhill le 28 septembre 2013 à 12:55. Évalué à 2.
  
  L'astuce c'est d'utiliser l'équivalence entre mv a b et ln a b; rm a, mais on va rajouter un rsync entre les deux.
  cp -al dossier/fichierA dossier/fichierB
  rsync -a dossier/ serveur:dossier/
  rm dossier/fichierA
  rsync -a --delete dossier/ serveur:dossier/
  
  Tu n'aurais pas oublié l'option -H dans ton premier rsync?
  Elle n'est pas inclue dans le -a (parce que ça peut être très lourd) et sans elle rsync ignore les liens physiques.
  - [^] # Re: Astuce
    
    Posté par jben le 28 septembre 2013 à 14:16. Évalué à 2.
    Tout à fait. Je croyais que le -H était inclu dans le -a. En fait moi je n'utilse pas rsync -a au quotidien, mais des alias défini par mes soins (et je n'utilise plus du tout scp) :
```
alias rs='rsync -rltHAzyPhh'
alias rsd='rsync -rltHAzyPhh --delete-delay'
```
    De plus quand je fais un déplacement dans le même dossier, le -y fait le boulot, je n'utilise pas cette procédure, mais dans les autres cas, si.
# 120 Go, vraiment ?

Posté par Sébastien Maccagnoni (site web personnel) le 25 septembre 2013 à 17:59. Évalué à 1.

Tu as réellement 120 Go qui changent tous les jours ?

Tes utilisateurs font du montage vidéo, pour générer autant de données quotidiennement ?

Ou alors tu as "un peu de données" qui changent dans un total de 120 Go de fichiers, auquel cas on peut toujours réfléchir à une solution… Mais il faut des détails sur les données (type de données, type de modifications…). Ce qu'il faut avant tout, c'est réussir à réduire au minimum le scope de la sauvegarde…
- [^] # Re: 120 Go, vraiment ?
  
  Posté par Philippe M (site web personnel) le 26 septembre 2013 à 10:07. Évalué à 1.
  
  Ca ne concerne pas que mes utilisateurs, il y a les dump oracles, des fichiers à plat très volumineux et c'est ici le plus gros volume et en plus ils bougent tout les jours. Quand à changer la méthode des fichiers à plat c'est tout simplement impossible pour différente raison qui ne relève plus de moi.
  
  Born to Kill EndUser !
  - [^] # Re: 120 Go, vraiment ?
    
    Posté par NeoX le 26 septembre 2013 à 10:45. Évalué à 2.
    
    un fichier à plat si en plus c'est du texte (dump de base) ca doit pouvoir se compresser avant envoi.
    et prendre jusqu'a 10x moins de place sur le stockage.
    - [^] # Re: 120 Go, vraiment ?
      
      Posté par Philippe M (site web personnel) le 26 septembre 2013 à 10:58. Évalué à 0.
      
      Moins de place en stockage, moins de temps de transfert mais est-ce que ça compense le temps de compression ? A tester…
      
      Born to Kill EndUser !
      - [^] # Re: 120 Go, vraiment ?
        
        Posté par NeoX le 26 septembre 2013 à 11:01. Évalué à 3.
        
        tu compresses surement plus vite depuis le disque dur, vers le disque dur (3Gbps en sata2)
        que tu n'envoie (6Mbps) dans le cas ici etudié.
        
        donc meme s'il y a du temps de calcul, oui, tu traiteras tes 120Go plus vite en compression qu'en transfert total.
        
        à voir neanmoins si 'temps de transfert non compressé' > 'temps de compression en local + temps de transfert compressé'
      - [^] # Re: 120 Go, vraiment ?
        
        Posté par Zenitram (site web personnel) le 26 septembre 2013 à 11:37. Évalué à 3.
        
        Moins de place en stockage,
        
        Non, ça ça dépend du système de fichier, du moins si tu veux présenter la même chose à l'utilisateur (et non pas un .gz)
        il y a ZFS…
        
        moins de temps de transfert mais est-ce que ça compense le temps de compression ?
        
        De nos jours (et depuis longtemps), le CPU on en a à plus savoir qu'en faire sur les serveurs de stockage, par contre du débit réseau… Ton admin réseau te dira aussi merci (ou alors il te tue pour ne pas l'avoir fait avant).
        
        Allez, rsync -z!
  - [^] # Re: 120 Go, vraiment ?
    
    Posté par Sébastien Maccagnoni (site web personnel) le 27 septembre 2013 à 11:12. Évalué à 2.
    
    dump oracles, des fichiers à plat très volumineux
    
    J'aurais éventuellement une proposition, à tester :
    - tu conserves le dump de la veille
    - tu fais un diff entre le dump de la veille et celui du jour
    - tu transfères uniquement le diff
    - sur le serveur de stockage des backups, tu appliques le diff avec patch pour reconstruire le dump complet
    
    De mon côté j'utilise rdiff-backup sur des dumps MySQL et PostgreSQL ; je n'ai pas la même volumétrie, les dumps complets sont transférés, mais rdiff-backup a la même approche pour le stockage : il ne stocke que le diff entre deux sauvegardes. Et du coup, mes sauvegardes sont assez limitées en taille. Mais, encore une fois, ça ne se fait que côté stockage avec rdiff-backup : toi tu aurais besoin de + puissant, un diff avant transfert.
# voir les solutions proposés dans ton precedent sujet

Posté par NeoX le 25 septembre 2013 à 19:53. Évalué à 4.

et nous dire ce que tu as deja essayé

le precedent sujet avec une problematique similaire
http://linuxfr.org/users/flipflip/journaux/synchroniser-deux-repertoires-rdiff-backup
ou celui là
http://linuxfr.org/users/flipflip/journaux/sauvegarde-données-utilisateurs-et-serveurs
- [^] # Re: voir les solutions proposés dans ton precedent sujet
  
  Posté par Philippe M (site web personnel) le 26 septembre 2013 à 10:10. Évalué à 1. Dernière modification le 26 septembre 2013 à 10:11.
  
  Je ne l'ai pas dis tout simplement parce que ma question est "Est-ce que rsync transfert que la différence des fichiers correspond au mode bloc de certaine solution du marché".
  
  Certes ma question en fin de post laisse penser que je cherche une solution pour contourner ce problème. C'est une erreur de l'avoir posé ainsi.
  
  Born to Kill EndUser !
# question con

Posté par coïn le 25 septembre 2013 à 20:26. Évalué à 2.

question con surement, mais tes 120g ne seraient pas 7zippables ?
- [^] # Re: question con
  
  Posté par Philippe M (site web personnel) le 26 septembre 2013 à 10:09. Évalué à -1.
  
  Le temps de compression + le temps de transfert serait surement bien plus long que sans compression. Déjà que la création d'une list de fichiers par rsync est longue.
  
  Born to Kill EndUser !
  - [^] # Re: question con
    
    Posté par arnaudus le 26 septembre 2013 à 17:41. Évalué à 5.
    
    Bah, tu peux retourner le problème dans tous les sens, tu ne feras pas passer 120Go par jour avec ta connexion. Il faut absolument compresser. Et tu peux compresser en même temps que tu transfères, donc ça n'est absolument pas bloquant.
# Autre idée

Posté par Floris DUBREUIL le 25 septembre 2013 à 22:04. Évalué à 0.

Je ne sais pas si c'est gérable "en 24 heures" vu la volumétrie mais:

1- Synchroniser l'ensemble des données du distant vers le local "en temps réel" un peu sur le principe d'un RAID 1 iSCSI. La première synchro serait très longue mais ensuite "le distant = le local".
Effectivement, il faut au moins 1 To de libre sur le disque cible du local.

2- Ajouter un second disque dur sur "le local".

3- Paramétrer la tâche Rsync entre le disque iSCSI local vers le second disque local. Les 120 Go seront transférés d'un disque à l'autre sur le même PC.
- [^] # Re: Autre idée
  
  Posté par NeoX le 26 septembre 2013 à 11:04. Évalué à 2.
  
  mais ton 1 est problematique avec une liaison à 6Mbps (768Ko/s)
  
  si y a plus de X Mo qui change à un instant T, il faudra plusieurs secondes avant que ca n'arrive au deuxieme membre de la grappe raid1 over IP
  
  pas sur que ca ne ralentisse pas l'ensemble des disques en attendant que les données soient effectivement transférées.
# Normal

Posté par Zenitram (site web personnel) le 26 septembre 2013 à 11:54. Évalué à 5.

En principe quand je vois ces sociétés lorsque j'aborde la question de l'estimation du délai de transfert de mes 120Go aucun ne répond et bizarrement je n'ai plus de nouvelles d'elles après le rdv même si il était question qu'on fasse un chiffrage/test…

6 Mbps = 500 ko/s réels = 40 Go/jour réels, et 10-15 si tu te limites à la nuit.
donc vouloir faire transiter 120 Go/jour montre qu'il y a un problème dans la demande, le problème n'est pas comment optimiser rsync et ou trouver une solution de backup, mais comment augmenter le débit.
A moins que ce soit compressable, mais la il faut tester et dire la quantité réelle à transférer…
Normal que les gens ne donnent plus de nouvelles devant une demande impossible à satisfaire.

Le temps de compression + le temps de transfert serait surement bien plus long que sans compression.

A 6 Mbps de transfert le temps de compression jouerait quelque chose? Euh, comme dire…

Bref, la, si les données ne sont pas hautement compressibles, la première chose à faire est de louer une ligne 100 Mbps.
- [^] # Re: Normal
  
  Posté par jben le 26 septembre 2013 à 21:12. Évalué à 3.
  
  Le problème, c'est que l'auteur de la question ne nous donne aucune précision sur la nature des données, et la nature des modifications. Impossible de savoir si c'est compressible ou non. Impossible de proposer une logique differente ou un outils different en en connaissant si peu.
  
  Je suggère donc à l'auteur du journal de donner toutes les précisions dont il dispose. Que ça soit possible ou non, c'est un problème intellectuel qu'il peut être intéressant d'aborder.
# Attention Attention ...

Posté par Christophe B. (site web personnel) le 27 septembre 2013 à 18:03. Évalué à 0.

Salut Philippe et bonjour messieurs,

Pour connaître un peu le contexte et le problème, je rajouterai juste un truc : il faut rester simple.
Les sauvegardes c'est bien, mais la restauration c'est mieux :)

Il faut rester simple, surtout avec de gros volumes, quand on doit restaurer il faut que cela soit fluide et facile a faire, car généralement la pression des utilisateurs patrons et autres est ENORME.

Il est peut être possible de s'en sortir avec un rsync et du mode block, mais j'envisagerais AUSSI d'avoir un lecteur LTO qui peut stocker 1,5 To dans une cartouche avec des débits cohérents.

A bientôt
Chris
- [^] # Re: Attention Attention ...
  
  Posté par Philippe M (site web personnel) le 27 septembre 2013 à 20:46. Évalué à 0.
  
  Effectivement tu connais un peu le bouzin chez moi pour en avoir longuement parlé :)
  
  Je pense que je vais pas avoir le choix mais ça n'élimine pas le problème de "je suis pas la pour mettre la cartouche… bah y a pas de backup qui se lance" Allez soyons fou un robot… Mais si personne ne prends la cassette le soir en partant c'est le même problème.
  
  C'est pas tellement faire le backup qui me pose problème mais c'est sortir ces backups de nos locaux… C'est un vrai casse tête !
  
  Je suis pour la simplicité c'est pour ça que j'ai mis backuppc en place, il va très bien. Quand à la restauration, à tester régulièrement, d'ailleurs tu risque d'en entendre parlé début 2014 mais avant nous avons une connaissance commune qui commence à raler que les serveurs prod et test sont désynchro… pfff ces dev qui triture la prod sans reporter les modifs sur le test (je sais normalement c'est dans l'autre sens… mais c'est un peu la 4ème dimension chez les dev ;) ).
  
  Born to Kill EndUser !
  - [^] # Re: Attention Attention ...
    
    Posté par NeoX le 27 septembre 2013 à 20:55. Évalué à 3.
    
    au prix du robot de bandes, pour garder les bandes en local,
    regarde pour une fibre optique 100Mbps Symetrique.
    
    Orange Pro en propose à 79euros/mois
    
    ce sera bien mieux que tes 6Mbps actuel
    - [^] # Re: Attention Attention ...
      
      Posté par Christophe B. (site web personnel) le 28 septembre 2013 à 23:20. Évalué à 0.
      J'adoooooooooooooooorre ce genre d'infos sur le site d'orange ou les mentions légales et autres exclusions sont écrits en base de page :
      Je cite :
      
      encore plus rapide ! Internet 200 Mbits/s symétrique(1)
      
      téléphone par internet
      appels illimités(2) vers les fixes et vers les mobiles de France métropolitaine et de + de 100 destinations(3)
      service de fax intégré(4)
      appels simultanés(5)
      renvoi d'appels premium(6)
      
      Bref on est sur que du téléphone sur internet
      
      7 lignes 6 avec paragraphe de bas de page ….
      - [^] # Re: Attention Attention ...
        
        Posté par NeoX le 28 septembre 2013 à 23:38. Évalué à 3.
        
        tu as la meme chose chez tous les FAI/operateur
        
        telephone/sms/mms illimité : mais limité en nombre ou en durée d'appels
        debit : au best effort, jusqu'a …
        3G illimité : dans la limite de xGo, bloqué ou debit reduit au dela
        
        etc
    - [^] # Re: Attention Attention ...
      
      Posté par Philippe M (site web personnel) le 29 septembre 2013 à 17:43. Évalué à 0.
      
      Lors de l'étude de l'installation de la fibre la réponse d'orange a été sans appel "On fait pas dans votre rue"… Le tec de sfr qui est venu faire le raccordement a bien rit car il y avait tout ce qu'il faut au niveau installation d'orange.
      
      Je suis étonné du montant que t'annonce pour du 100M assuré et symétrique à 79€ par mois… Ensuite juste le petit 1 est drôle
      
      (1) Les débits annoncés sont des débits IP. Jusqu’à 200 Mégabit/s en réception et en émission (débit IP maximum). Fonctionne uniquement avec la Livebox pro.Orange pourra suspendre l’ensemble des services de l’offre (hors service mobile) au-delà de 2 téraoctets par mois (cycle de facturation). Cette suspension sera effective jusqu’à la date de facturation suivante.
      
      200 c'est le débit max que potentiellement tu peux attendre mais ils assurent rien et la limite de 2To ça va faire juste pour faire du backup. Et 200M débit IP c'est pas très parlant, au final j'aurais combien pour de vrai ? La livebox elle est pas rackable en plus :D
      
      Chez SFR j'ai certe que 6M pour le moment mais c'est de l'assuré… au moins sur leurs installations
      
      Born to Kill EndUser !
      - [^] # Re: Attention Attention ...
        
        Posté par NeoX le 29 septembre 2013 à 18:12. Évalué à 3.
        
        bah c'est sur que les operateurs ont plusieurs offres.
        
        le grand public
        le professionnel, TPE/PME (ici pour la fibre, Open Pro Fibre Intense)
        les grandes entreprises
        
        si tu veux du debit garanti, une GTR h+4, etc il faut mettre plus que 79euros/mois
        
        mais dans le cas present il faut quand meme reflechir à mettre les moyens et augmenter la ligne au dela de 6Mbps
        car, à defaut de preciser ce qui fait exactement 120Go de backups, le probleme vient de là.
        
        [^] # Re: Attention Attention ...
        
        Posté par Philippe M (site web personnel) le 30 septembre 2013 à 08:59. Évalué à 1.
        
        Disons que ma direction a des priorités et une fibre 100M, malgré tout le bien que je peux en dire, n'en fait pas partie. Encore heureux que les opérateurs proposent un choix mais il faut bien lire les petites lignes, dans le cas de l'offre orange à 79€ la limite de 2To peut être très vite atteinte même sans parler de faire de la sauvegarde.
        
        car, à defaut de preciser ce qui fait exactement 120Go de backups, le probleme vient de là.
        
        Y a un peu de tout dans ces backups : du fichiers utilisateurs type office, du dump de base de données, du fichiers à plat, des photos (jpg, tif, eps), de la vidéos, des fichiers pst… Ce qui bouge souvent c'est les dumps, les fichiers à plat et les pst. Après le reste représente de petits volumes.
        
        Born to Kill EndUser !
        
        [^] # Re: Attention Attention ...
        
        Posté par NeoX le 03 octobre 2013 à 23:03. Évalué à 2.
        
        Ce qui bouge souvent c'est les dumps, les fichiers à plat et les pst
        
        si le dump n'est pas binaire, alors ca se compresse AVANT de le stocker
        idem pour les fichiers à plat.
  - [^] # Re: Attention Attention ...
    
    Posté par Christophe B. (site web personnel) le 28 septembre 2013 à 19:15. Évalué à 0.
    
    On en reparlera, mais j'ai le même problème :)
    Et cela a fini par … c'est bibi et mimi ( Michel et Moi) qui échangeons les cartouches
    Et pourtant j'avais super simplifié le truc pour qu'une de nos charmantes secretaire puissent échanger les cartouches.
    mais bon il parait que les cartouches LTO cela déforment les sacs à main ou les poches de manteaux … pfff
    
    Pour les modifs PROD / TEST / DEVS / DEMOS / QUALIF et autres, je veux plus savoir, c'est trop "Aïe Leuvelle" pour des sysadmins, bref trop dur à comprendre pour nos petites têtes habituées au bon sens et à la logique pure et dure.
    
    Mais on en reparlera :) l'échanges d'idées ya que ça de vrai.
    En plus j'ai commencé à mettre les mains dans bacula :)
    
    A+
    chris
    - [^] # Re: Attention Attention ...
      
      Posté par Philippe M (site web personnel) le 29 septembre 2013 à 17:45. Évalué à 0.
      
      Pendant l'échange d'idées, pour l'apéro t'a prévue des ptits dev en croute doré au four histoire d'en éliminer un ou deux ? :D
      
      Born to Kill EndUser !
      - [^] # Re: Attention Attention ...
        
        Posté par Christophe B. (site web personnel) le 29 septembre 2013 à 23:01. Évalué à 1. Dernière modification le 29 septembre 2013 à 23:04.
        
        Nan j'ai plus le droit aux sévices physiques, depuis c'est la pagaille.
        Mais ca fait rien, la torture mentale c'est parfois tout aussi drôle :)
        
        Sinon, j'adore le foie de dev avec un excellent chianti …. tsss tsss tsss
        
        ;-)
# RDX vous connaissez ?

Posté par Christophe B. (site web personnel) le 30 septembre 2013 à 12:47. Évalué à 1. Dernière modification le 30 septembre 2013 à 12:49.

Bon puisque qu'on parle de sauvegarde, je viens de découvrir les sauvegardes RDX

PS: allez je vous la fait façon télécom :

ça à l'air vraiment bien sur le papier (1), l'avantage d'un disque dur (2) que l'on peut extraire facilement (3)
Je vois 3 avantages (4)
- Le prix bien sur (5)
- Ce n'est plus une bande mais un accès aléatoire dont super pour les petits fichiers (6)
- En plus on peut se passer de logiciel de sauvegarde (7)

(1) ça tout le monde peut le dire
(2) A vérifier quand même
(3) sauf pour les bipèdes à mèches blondes avec 2 mains gauches peut être
(4) oui 3 vous avez bien lu 3
(5) apparemment le prix est en centaine d'euros pour le drive, idem pour les cartouches donc moins cher que les LTOs
(6) quand on compare avec le LTO
(7) cela doit se mounter comme un disque USB

Donc ça pulse comme un LTO mais c'est un disque …

Avez vous des retours d'expérience sur ces périphériques ?

Vu que les disques RDX vont jusqu'à 1,5 To

A+
chris
- [^] # Re: RDX vous connaissez ?
  
  Posté par Philippe M (site web personnel) le 30 septembre 2013 à 16:27. Évalué à 0.
  
  Ca me rappel vaguement le VXA… dit-il en sifflant :)
  
  Born to Kill EndUser !
  - [^] # Re: RDX vous connaissez ?
    
    Posté par Christophe B. (site web personnel) le 30 septembre 2013 à 17:32. Évalué à 0.
    
    Ah ouiiii !!!
    
    c'est vrai que tu avais eu du VXA …
    
    Tu rigoles mais il y en a 1 qui tourne encore … il doit sauvegarde 10 Go / jour
    a 10% des capacités ça fonctionne …
    
    sinon VXA chez IBM c'est comme lapin sur un bateau … rien que le nom porte malheur :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.