Erreur FTP : 550 Could not delete [File] : Disk quota exceeded

Par le dans . Marqué comme , , , , , avec 16 Commentaires

Erreur FTP : 550 Could not delete [File] : Disk quota exceeded

Aujourd’hui je partage avec vous une petite astuce qui peut vous être utile si un jour vous vous retrouvez dans la même situation que moi …

Je détaille le contexte … Sublimigeek est hébergé sur un serveur que j’administre moi même … jusque là tout va bien :)

En bon administrateur que je suis (ou pas), la première chose que j’ai faite, a été de mettre en place un système de backups de mes sites et autres fichiers de configurations critiques, afin de pouvoir restaurer le blog et mes serveurs logiques le plus rapidement possible.

Rien de bien violent quoi, un cron qui appelle deux scripts que j’ai développé et qui exécutent une moulinette.

Le premier script s’occupe de dumper (sauvegarder) l’ensemble de mes bases de données avec mysqldump et de compresser le tout. Le second script quant à lui, génère un rsnapshot de mes fichiers et répertoires sélectionnés, récupère le dump des bases de données, recompresse et transfère le tout sur le serveur FTP de backup mis à disposition par OVH (100Go au total).

Le système m’envoie ensuite un courriel pour me confirmer si oui ou non le cron s’est bien exécuté et n’a pas retourné d’erreur.

Bon jusque là, pour ceux qui comprennent de quoi je parle, ce n’est rien de sorcier … sauf que le jour où j’ai développé ce petit système, je n’ai pas pensé à une chose … mettre en place un système me permettant de supprimer automatiquement les anciennes sauvegardes devenues inutiles afin de ne pas saturer l’espace disque du serveur de sauvegarde.

Ayant la flemme de m’en occuper (bouuuuh c’est pas bien ça), je surveillais de temps en temps l’espace disque de celui-ci afin de supprimer à la main les sauvegardes inutiles …

Jusqu’au jour où … ce qui devait arriver … arriva … je ne m’en suis pas occupé ^^

Donc forcément, je reçois un courriel de mon cron qui m’indique que le système de sauvegarde n’a pas été exécuté entièrement pour faute d’espace disque disponible sur mon serveur FTP.
Moi premier réflexe, je me connecte à mon FTP et je commence à supprimer quelques fichiers.

# J'utilise LFTP qui permet d'utiliser des commandes plus évoluées que FTP, sinon la commande aurait ressemblé à cela : delete NomDeMaSauvegarde.gz
lftp> rm -r /RepertoireStockantLesBackups/NomDeMaSauvegarde.gz

Et là … qu’est-ce qu’il me répond le bougre ?!

550 Could not delete NomDeMaSauvegarde.gz: Disk quota exceeded

Euuuh … comment te dire … j’essaie justement de t’en faire de la place … donc merci de faire un petit effort ^^

Et ben malgré tous mes essais, avec "delete", "mdelete", "rm", "rmdir" en forçant des paramètres comme la récursivité sur les répertoires ou la suppression forcée, rien à faire impossible de libérer de l’espace en supprimant mes fichiers.

J’ai comme l’impression que je suis dans une impasse ^^

Après quelques recherches sur le net, rien de plus, apparemment pas mal de personnes ont rencontré ce type de problème, mais il n’y a pas vraiment de solution type à appliquer. Sur un des forums OVH, des utilisateurs ont même ouvert des tickets incidents avec le service technique, c’est pour vous dire …

En gros, le problème est là :

230-OK. Current directory is /
230 On Sat Jun  9 01:00:48 CEST 2012 space used : 102400044 Kb - authorized : 102400000 Kb
Remote system type is UNIX.

A force de fouiner dans tous les postes du forum OVH, j’ai fini par dénicher un poste qui m’a mis la puce à l’oreille.

Cet utilisateur propose une solution bien à l’arrache comme on aime, avec un retour de 15 ans en arrière. Dans le style bonne grosse bidouille à deux francs, voici la solution qu’il propose :

Il "suffit" de copier sur le FTP un fichier vide portant le nom d'un gros fichier. Le gros fichier sera écrasé, de la place sera libérée et vous pourrez reprendre la main sur votre FTP !

Et là, je me dis « Noooooon … Quand même pas !! » … Mais comme je suis un curieux de nature, j’ai fini par tester !!

Donc dans le principe, je récupère le nom du fichier d’une de mes veilles sauvegardes et j’envoie un fichier identique sur mon serveur :

cd /tmp/
touch NomDeMaVeilleSauvegarde.gz

Je me connecte ensuite à mon FTP :

lftp MonNomUtilisateur@MonServeurDeBackup

Et je tente d’uploader mon fameux fichier dans mon répertoire de backup :

ftp> put /tmp/NomDeMaVeilleSauvegarde.gz /MonrepertoireDeSauvegarde/NomDeMaVeilleSauvegarde.gz

Et là … que me répond le FTP ??

local: /tmp/NomDeMaVeilleSauvegarde.gz remote: NomDeMaVeilleSauvegarde.gz
200 PORT command successful
150 Connecting to port 57986
226-File successfully transferred
226 0.001 seconds (measured here), 3.76 Kbytes per second
2 bytes sent in 0.00 secs (39.9 kB/s)

Oui oui … vous ne rêvez pas cela a fonctionné !!
J’ai cherché pendant une bonne heure à contourner le système et à faire en sorte de libérer un peu d’espace sur le serveur FTP en vidant le cache, en modifiant les droits des fichiers pour forcer la suppression, en lisant le manuel de FTP et de LFPT à la quête d’une commande magique sans résultat alors qu’un simple « PUT » a résolu mon problème en moins d’une minute chrono …

Voilà voilà … pourquoi chercher à faire simple lorsque l’on peut faire compliqué … n’est-ce pas ?!

J’espère que cette petite astuce vous sera utile le jour où vous vous retrouverez dans cette situation, cela vous fera sûrement gagner du temps et comme le temps c’est de l’argent, c’est tout bénef pour tout le monde ^^

Si jamais vous avez une autre solution moins « à l’ancienne » que celle que je vous propose, n’hésitez pas à m’en faire part, je serais curieux de savoir si il en existe une !!

Le conseil du jour : N’oubliez pas de faire vos sauvegardes, on n’est jamais à l’abri d’un bug, d’un piratage ou d’une mauvaise manipulation :)

Sur ce, je vous laisse, je retourne relancer manuellement mes scripts histoire de dormir sur mes deux oreilles ce soir ^^

16 Commentaires


    • Hummm pourquoi pas … Il faudrait que je le fasse évoluer un peu et je pourrais le mettre en ligne, mais en gros il ne fait rien d’extraordinaire :)
      J’ajoute ça dans ma todo liste et te tiens au courant !

  1. Excellente la ruse de Barbu ! Personnellement, je ne trouve pas ça bourrin du tout, au contraire, c’est vraiment réalisé avec finesse et subtilité, fallait y penser.

    Merci pour les recherches et l’info Joël.

    Personnellement pour les sauvegardes j’utilise RSYNC avec contrôle d’intégrité, et comme Joël un p’tit script en bash maison. Cependant, j’ai la chance d’avoir un serveur dédié aux sauvegardes et un système de suppression automatique des vielles archives, avec historique, différentiel, etc…. Si j’arrive à le rendre lisible pour un humain, je le partagerai volontiers.

    Mais pour les bases de données, parait-il que même avec un dump, on est pas en sécurité. Le mieux est de tester ses sauvegardes de temps en temps ; ce sont les recommandations de nombreux développeurs ; une BDD c’est vraiment fragile. ça fait quand même flipper ^^

    Bon week-end à tous et désolé pour avoir clouer l’ambiance :(

    • Il est clair qu’un test de restauration de ses sauvegardes est TOUJOURS à prévoir même si son système tourne très bien :)
      J’en fais de temps en temps (1 à 2 tous les 3 mois) sur une machine virtuelle en local histoire de voir si rien ne plante, si il n’y a pas de perte de données et surtout si mes backups sont fonctionnels ^^

      Ce qui est important de savoir aussi … c’est le temps de restauration … car on peut vite y passer des heures !! Bon je ne dis pas que si Sublimigeek reste hors ligne une demi journée c’est la fin du monde, mais en entreprise cela peut rapidement devenir une perte financière non négligeable …

  2. Tiens je ne savais pas qu’on avait un accès SSH sur les backups OVH.

    Pendant un moment j’ai fait des backups en local avec rdiff-backup et bash (cf. doc Ubuntu) ce qui a toujours très bien fonctionné car la sauvegarde incrémentielle m’évitait d’exploser le disque de mon NAS local.

    Mais j’avoue que depuis que j’utilise OpenVZ avec Proxmox c’est quand même beaucoup plus pratique ! :p

    • J’avoue que les backups en local sont pas mal (surtout si l’on possède un NAS), mais ayant une connexion ADSL assez faible en terme de débit, en cas de crash du serveur, je préfère avoir les données sur le FTP OVH ce qui permet une reprise du service plus rapide :)

    • Content que cette petite astuce est pu te faire gagner du temps :)
      Et merci pour le lien, il y a de quoi s’occuper un moment avec ça … ça me fait d’ailleurs penser aux différentes modifications que je devrais apporter au mien, mais je n’ai pas vraiment le temps de m’en occuper ^^

  3. Alors là, un grand merci ! Je suis un total néophyte qui bien que désormais habitués à ce genre de défaillance de mon plugin de sécurité, n’aurait jamais pu trouvé seul. Problème résolu en 3minutes et une idée toute simple qui m’a réellement sauvé. Que de l’amour

    • Hello Flo,

      Recevoir tout cet amour pour une solution que j’ai publié en 2012, je trouve cela tout simplement magique :D
      Merci d’avoir pris le temps de poster un retour ici, ça fait chaud au cœur tout ça :)

      Bonne continuation et si jamais tu as besoin d’aide pour quoi que ce soir, n’hésites pas à me contacter via la page « contact » du blog.
      Je réponds toujours aux personnes qui ont pris la peine de me contacter !

      @+

  4. Et bien on est en janvier 2018 et cette solution est toujours valable: testée à l’instant sur mon FTP backup associé à un serveur dédié OVH.
    Merci Joël!

N'hésitez pas, laissez un commentaire — DoFollow activé sur ce site —


« »