alwaysdata : site compromis, SSH et journaux
Chez alwaysdata, SSH et journaux sont souvent encore là quand un mutualisé classique a déjà coupé le FTP. Utilisez-les avant de tout réinstaller. Un site Python ou PHP sur mesure se cartographie ; il ne se « réinstalle » pas comme un WordPress en un clic. Dates, process, clés, cron : vous dressez la chronologie. Un rm -rf « pour se rassurer » détruit précisément ce que le support sait vous donner.
SSH et journaux sont souvent accessibles. Utilisez-les avant de tout réinstaller. Un site Python/PHP sur mesure se cartographie, il ne se « réinstalle » pas comme WordPress.
Ce que alwaysdata donne (et qu'il ne faut pas gâcher)
Interface claire, SSH, logs, cron, plusieurs sites, stacks variées. C'est un avantage le jour J — si vous ne commencez pas par un `rm -rf` ou une réinstall « pour se rassurer ». Copiez hors compte d'abord. Sauvegarder déjà pirate.
Cadre : compte suspendu, guide. Si SSH est déjà mort, archive. Archive sale.
WordPress chez alwaysdata existe ; le réflexe zip officiel tient. Le site maison, non. Site PHP. Les clients alwaysdata mixent souvent les deux sur le même compte : un blog WP « pour le SEO » à côté d'une app Django. Le mail d'abus ne cite que le bruyant. Inventoriez les deux stacks avant de jurer que « le WordPress est propre ».
SSH : dater, lister, ne pas tout rm
Dates de fichiers, `find` par mtime, liste des process, cron utilisateur. Vous établissez la chronologie. Vous ne publiez pas un exploit. Vous ne « testez pas si vous pouvez lire le voisin ».
Clés SSH : listez `authorized_keys`, retirez les inconnues, tournez. Un nettoyage fichiers avec une clé encore là se refait la nuit. VPS — même discipline clés, périmètre plus petit.
Si vous n'êtes pas à l'aise en SSH, restez au panel + archive. Casser le métier en ligne de commande est un second incident. Un `chmod 777` « pour que ça reparte » sur un compte encore ouvert est pire qu'une heure à lire les dates. Demandez à alwaysdata un dump si la copie SFTP est trop lente : c'est toujours d'une archive sale qu'il s'agit, donc hors prod.
Journaux : HTTP, applicatifs, cron
Access/error, logs Django/Flask/Laravel, cron. POST vers un PHP inconnu, 200 sur un script isolé, user-agents de bots. Lire les logs.
Téléchargez-les hors compte : une réinstall les écrase.
Journal d'envoi si spam. Distingue l'app et un PHP racine.
Sites PHP, Python, Node : cartographier
Chaque site alwaysdata a un type. Python : venv, `requirements.txt`, fichiers dans `static` / `media`. Node : `node_modules`, process forever/pm2. PHP : `vendor`, uploads. Dépendances.
Pas de « réinstaller WordPress » universel. Carte, dates, secrets `.env`. `.env`.
Adminer, phpinfo, debug laissé. Adminer.
Compte alwaysdata, users, adresses e-mail
Mot de passe compte + 2FA, users techniques, adresses de recovery. Panel d'abord. Moindre privilège.
Mail alwaysdata vs MX ailleurs. Adresse perso dans le ticket si besoin. Mail coupé.
Permissions entre sites du même compte : ne supposez pas l'isolation parfaite. Demandez / vérifiez. Isolation.
Ticket et abus
Support alwaysdata : souvent technique, apprécie un constat précis (chemins, process, timestamps). Référence d'abus. Pas de relance horaire.
Ils peuvent aider sur les logs et l'archive. Ils ne « nettoient pas Laravel à votre place » dans le ticket gratuit.
Créer un compte si la stack dépasse le dimanche soir.
Isolation entre sites du compte
Plusieurs sites = inventaire complet. Un vieux Django à côté d'un PHP métier. Éteignez les morts. CMS oublié.
Cron d'un site qui écrit chez l'autre.
IP / réputation : réputation IP.
Après : secrets, tests, dépendances
`.env`, clés SSH, compte, CMS. Lockfiles sains. Tests visiteurs. Tests.
WAF après. WAF. Trente jours. Garantie.
Gandi Simple Hosting voisin d'esprit. Gandi.
Ce que le support alwaysdata sait faire — et s'arrête
Ils sont souvent capables de pointer un process, un cron, un chemin, de fournir des logs plus longs que la moyenne des mutualisés. Ils ne vont pas comparer votre `app/` Laravel à Git, ni décider si une table clients a été lue. Ce partage des rôles évite d'attendre d'eux un « clean » qui n'arrivera pas, et d'ignorer ce qu'ils donnent vraiment.
Un ticket qui dit « merci pour le process X, nous l'avons stoppé après copie, entrée Y fermée, constat en PJ » avance. Un ticket « vous avez un virus, réinstallez-moi Python » tourne. Même exigence que chez OVH, avec plus de matière technique à coller.
Si la stack (CI, plusieurs sites, Docker oublié) dépasse le forfait web, dites-le tôt. Un VPS alwaysdata ou un compte qui ressemble à un mini-serveur se traite comme VPS dès que root ou le démon Docker entre en jeu. Créer un compte : on lit les logs avec vous, on ne « formatera » pas l'instance pour se rassurer.
- Logs et process : oui, demandez.
- Réinstall métier à l'aveugle : non.
- Constats PDF : ils les lisent.