Boîte à idées

Sauvegardes : restaurer seulement une partie du service

Actuellement, la restauration d'une sauvegarde remplace tout le service : fichiers, bases de données, boîtes mail et domaines. Pour récupérer une base corrompue, il faut donc aussi revenir en arrière sur les fichiers et perdre les e-mails reçus depuis.

Il serait utile de pouvoir choisir, au moment de restaurer, les éléments concernés :

• les fichiers ;

• une ou plusieurs bases de données ;

• une ou plusieurs boîtes mail.

Les éléments non sélectionnés resteraient inchangés. La restauration complète resterait le choix par défaut.

Sauvegardes : bouton « Sauvegarder maintenant »

Actuellement, la sauvegarde est uniquement automatique, une fois par jour. Avant une opération risquée (mise à jour d'un CMS, migration de base, changement de version de PHP), il n'existe aucun moyen de créer un point de restauration récent : en cas de problème, on perd tout le travail fait depuis la sauvegarde de la nuit.

Il serait utile d'ajouter un bouton pour déclencher une sauvegarde à la demande, identifiée comme « manuelle » dans la liste.

Pour limiter le stockage, une seule sauvegarde manuelle pourrait être conservée, remplacée par la suivante.

Tâches planifiées : alerte e-mail en cas d'échec

Aujourd'hui, une tâche planifiée qui échoue ne prévient personne : il faut ouvrir le panel pour le constater, parfois plusieurs jours après.

Il serait utile de pouvoir activer, pour chaque tâche, l'envoi d'un e-mail lorsque l'exécution se termine en erreur, à l'adresse du compte ou à une adresse choisie.

Pour éviter le spam sur les tâches fréquentes, une seule alerte serait envoyée au premier échec, puis une autre au retour à la normale.

Tâches planifiées : journal d'exécution avec la sortie du script

Actuellement, une tâche planifiée indique seulement « exécutée » ou « erreur », y compris lors d'un lancement manuel. En cas d'échec, impossible de savoir pourquoi sans ajouter soi-même une écriture de logs dans le script.

Il serait utile d'avoir, pour chaque tâche, un historique des dernières exécutions avec :

• la date et la durée ;

• le code de retour ;

• la sortie du script (sortie standard et erreurs).

Une rétention courte suffirait, par exemple les 20 dernières exécutions, avec une sortie tronquée à quelques kilo-octets pour limiter le stockage.

Redirection e-mail : option pour ne pas conserver de copie

Actuellement, lorsqu'une redirection est active sur une adresse e-mail, les messages redirigés restent stockés dans la boîte d'origine. Ils s'accumulent et finissent par remplir le quota de stockage, ce qui oblige à vider la boîte manuellement.

Il serait utile d'ajouter, pour chaque redirection, un choix entre :

• conserver une copie dans la boîte (comportement actuel) ;

• supprimer le message de la boîte une fois redirigé.

Cela permettrait d'utiliser une adresse comme simple alias, sans surveiller son quota.

Hello, je trouve que mettre en place un système de partenariat similaire à celui de Minestrator, avec un code partenaire, etc., serait vraiment sympa pour Webstrator !

Pouvoir supprimer un pod, une offre Web ou un autre service avant son expiration si on n’en a plus besoin, avec éventuellement un remboursement du temps restant en crédits.

Créer un MCP dédié à Webstrator, sur le même principe que celui proposé pour Minestrator.

Pouvoir exécuter des commandes directement depuis une console en temps réel. Le système actuel d’exécution de commandes via la page fonctionne, mais je le trouve assez peu pratique pour une utilisation régulière.