Transmit 4 et la sauvegarde incrémentale (via FTP)
Transmit est vraiment un super client FTP et c’est Alban qui me l’a fait découvrir, ou plutôt redécouvrir. Pour rappel, le FTP (File Transfer Protocol) est un protocole de communication qui permet d’échanger des fichiers sur un réseau. Je ne vais pas présenter le logiciel dans son ensemble, ni revenir sur ses impressionnantes fonctionnalités puisque le site officiel est là pour ça (profitez-en pour jeter un coup d’oeil à Coda). Et puis à la base Transmit n’est finalement qu’un client FTP comme d’autres (FileZilla par exemple) si ce n’est qu’il est disponible uniquement sous Mac (moyennant $34). Aujourd’hui il y a surtout deux excellentes fonctions de Transmit 4 sur lesquelles je souhaite revenir : « Sync » et « Disks ». Avant d’entrer dans le vif du sujet je ne peux que vous encourager à essayer ce logiciel très simple d’utilisation et qui dispose d’une interface vraiment sympa. Il est entièrement codé en 64 bits, supporte l’envoi de commandes SSH, Amazon S3, etc… De plus la vitesse des transferts est réellement impressionnante avec la possibilité de limiter la bande passante utilisée :-)
Synchronisation d’un FTP avec le Mac
Tout comme iTunes synchronise les musiques de votre iPod/iPhone/iPad avec votre Mac, Transmit 4 sait synchroniser les fichiers de votre serveur FTP avec celui-ci. C’est un peu l’équivalent de Carbon Copy Cloner mais en « version FTP ». Je pensais d’ailleurs pouvoir faire ça avec CCC mais j’ai un peu surestimé les capacités de ce (pourtant) très bon logiciel. A noter que le logiciel Carbon Copy Cloner ne peut absolument pas remplacer cette fonction car il ne supporte que des volumes formatés en HFS+.
[ATTENTION JE RACONTE MA VIE !] Je cherchais un logiciel de sauvegarde incrémentale (ou incrémentielle) via FTP et là je pense sincèrement l’avoir -enfin- trouvé ! J’aurais bien sûr pu dupliquer la VM (Machine virtuelle) sous VMware Infrastructure ou encore faire un crontab bancal (.tar.gz touSSa) mais je voulais une solution simple, rapide et efficace. Je me voyais bien régulièrement sauvegarder (ou faire des snapshots de) la machine virtuelle et rapatrier des centaines/milliers de Go via ma connexion ADSL. Là c’est PERFECT ! Plus qu’à bidouiller my.cnf pour déplacer /var/db/mysql/ dans /usr/home/web/ Comme ça j’effectue avec Transmit 4 un backup complet du FTP et de mes bases de données MySQL. Mwouahahahahah c’est UNBELIEVABLE, j’suis diabolique KrKrKr cyp La drogue c’est mal…
Un disque dur virtuel en guise de FTP
Grâce à Transmit 4 vous aurez en permanence votre FTP « sous la main » (ou plutôt sur le Finder). Le logiciel va créer une sorte de disque dur virtuel (vive MacFuse) que vous pourrez utiliser comme tel. Vous ajoutez, supprimez, renommez, déplacez des dossiers ou fichiers avec une simplicité déconcertante : supporte évidemment le glisser-déposer (Drag-and-drop pour les intimes). Et bien sûr, deux cerises sur le gâteau pour le prix d’une ! D’une part vous pouvez quitter le logiciel tout en conservant ce « disque dur virtuel » sur le Finder, et d’autre part les miniatures des fichiers sont totalement supportées !
Le mot de la fin…
L’éditeur Panic développe des logiciels de qualité et c’est toujours avec grand plaisir que je dépense quelques dizaines d’euros : jamais eu le moindre regret à ce niveau là. Que du bonheur, un peu comme GameLoft avec les jeux mobiles quoi :razz: Deux questions restent néanmoins en suspens :
- A quand un terminal dans Transmit alors que Coda en intègre déjà un ?
- Après Coda l’éditeur et Transmit le client FTP, aurons-nous droit à un (My)SQL Manager ?
Allez.. je vais essayer ça
J’ai utilisé la synchro avec d’autres softs, on va tenter de copier 100 go là
Je pense qu’il y aura de nombreuses inconsitences dans tes fichiers *.MYD et *.MYD si tu les copies sauvagement sans acquérir de lock. A mon avis, le meilleur moyen d’archiver les bases MYSQL reste la commande mysqldump qui gère cela très bien.
Tout ça c’est de la branlette ! J’ai essayé mysqldump ou même BigDump et ça fonctionne dans les grandes lignes. Lorsqu’il s’agit de sauvegarder quelques bases de données de plusieurs dizaines de Mo ça passe plutôt bien mais au delà de cette limite… y’a plus personne
Voilà typiquement le genre de problème qui apparait. Je ne parle même pas des dump qui balance toute la base de données dans un seul fichier texte de plusieurs Go. Si je prends le seul exemple de Motorsport-Passion, j’ai une table qui possède à elle seule plus de 5 millions d’enregistrements (plus d’un Go pour cette table). Là tous ces « dumps » rendent la main très rapidement. J’ai vraiment essayé tout ce que j’ai trouvé et je ne suis visiblement pas le seul dans ce cas là.
En plus quel logiciel va pouvoir ouvrir, ou ne serait-ce que lire et traiter, un fichier texte de plusieurs Go. Et là encore je ne fais pas allusion à la durée du traitement qui sera nécessaire à la réinjection d’un tel dump : le processus risque de charger la RAM encore plus que le dump en lui-même. Oui alors bon y’a bien une fonction « commit; » qui fonctionne d’une manière un peu « strange » : elle ne découpe pas pour autant le dump en plusieurs fichiers (de 50000 enregistrements par exemple).
Je n’ai jamais rencontré la moindre inconsistance en faisant un backup de /var/db/mysql/ (les fichiers *.MYD et touSSa), il faut juste ne pas tenter le diable en utilisant ces mêmes fichiers avec une version différente de MySQL. Une fois en place il me suffit de ne pas oublier les chgrp -R mysql, chown -R mysql et chmod 660 qui vont bien. Le seul risque étant de corrompre très légèrement une relation dans la base de données si celle-ci n’a pas été verrouillée au préalable : je pense que c’est à ça que tu faisais allusion quand tu disais « sans acquérir de lock ».
Voilà. Merci pour ton com’
PS : C’est un peu comme ne pas pouvoir faire un tar sur un répertoire qui contient plusieurs centaines de milliers de fichiers quoi : Argument list too long KrKrKr
Le problème « Too much opened file » que tu décris n’est pas un problème de mysqldump mais de FreeBSD. Tu peux changer cette limite avec ulimit.
Je ne vois pas pourquoi tu veux ouvrir ton fichier mais voici un éditeur que tu peux utiliser: vim. Bien sûr, tu peux également utiliser les outils comme sed et grep
J’ai pas trop compris pourquoi tu voulais découper ton fichier: la restauration est linéaire et même sur un petit serveur, la restauration d’un dump ne prend pas beaucoup de temps et ne surcharge pas la base.
PS: … et pour ton tar sur ton répertoire avec des centaines de milliers de fichiers, un détour par la page man d’xargs peut t’aider
Pour ce qui est de la version de MYSQL, tu as de la chance de pouvoir la contrôler étant donné que tu es l’admin de la machine. Néanmoins, cela n’est pas le cas si tu es tributaire d’un administrateur. L’autre cas qui pourrait être critique: tu perds ta machine pour une raison ou pour une autre et en faisant une réinstallation sur une autre machine, la version de MYSQL est incrémentée: bye bye les données.
Je ne connaissais pas ulimit mais je sais que cette limite vient de FreeBSD.
En fait je faisais allusion à BigDump qui est en php : d’où le découpage, la conso de RAM, le processus, etc…
A vrai dire mes questions n’attendaient pas des réponses LOL. A la base je « présente » un logiciel avec interface graphique qui permet une synchro FTP, j’en profite pour dire que « hop les *.MYD touSSa » et on en vient à des lignes de commandes. Tout ce que tu dis est tout à fait juste mais tu sais (ou du moins je pense que tu l’as déduit) que j’utilise VMware et qu’il y a donc des snapshots réguliers de la VM. Je profite juste de cette synchro pour les fichiers *.MYD, rien de plus.
Ton commentaire aura au moins eu le mérite de me rappeler qu’en 2010 il faudrait que je passe sous vim, que j’augmente une limite avec ulimit, que je me renseigne sur la page man d’xargs et que (s’il me reste un peu de temps) je me documente sur mysqldump. Et aller soyons fous, une petite réplication sql en plus de ma VM, de mon raid, de ma double alim et de mes deux connexions ethernet…
PS : Il faut que l’on se voit avec Jéjé « et tout » ce mois-ci parce que pas mal de choses risquent de bouger pour moi. Peut être un départ prochainement (très loin de MySQL LOL) donc voilà…
Si j’osais je vous proposerais bien d’utiliser rsync
D’ailleurs c’est utilisé en sous-terrain par CCC
« et c’est Alban qui me l’a fait découvrir »
Pouah, arrête, ça me touche trop, d’ailleurs c’est biscotte time là, je vais en profiter pour me caresser
Plus sérieusement, tu l’aurais découvert tôt ou tard sans mon aide mais merci pour le petit message puis je vois que tu as signalé deux points dont un à propos du Terminal, ça a du te marquer suite à notre conversation sur Skype
En dehors de ça, encore un billet de choix, +1, comme d’hab quoi !
al.
L’idée de passer mes données en clair ne me plaisait pas trop en lisant ton article, mais quand j’ai vu « One-Click SFTP Key Import Instead of a password, use key » dans les caractéristiques et bien ça m’a fait chaud au coeur. Un petit « iDisk » en SFTP ça c’est du tout bon :anger:
Ouaip Transmit gère « bien sûr » le SFTP, faut pas déconner !
Une appli pour iPhone peut être à suggérer pour accéder à ce « iDisk » à la façon Dropbox ? :nickel:
Je n’ai rien trouvé de concret, peut être un début de réponse ici… http://www.panic.com/blog/2010[...]mment-8961 :W
Ok ok, je vais essayer de creuser ça, merci en tous cas pour cet article :nickel:
Quoi ?! Non mais j’étais persuadé d’avoir répondu à cette article lors de sa parution, faut vraiment que j’arrête la drogue
Non, juste pour te dire qu’en effet ce service semble juste énorme et très pratique. Il m’intéresse un peu donc va falloir qu’on en parle … quand on aura réussi à ce choper car ces derniers temps c’est difficile
Bizzz coupaing
Bonjour,
Question de béotien: est-ce que je peux synchroniser deux Mac avec Transmit comme je le fais avec Dropbox? Je veux dire, « partager » deux dossiers entre deux macs via mon FTP ?
Merci pour tout!