Ajouter RAM VPS SSD 2

vous imaginez bien, c'est impossible.

Cela reste le même serveur, la configuration ne bouge pas.
Mais vous aurez un 2° vcore et + de RAM.
Généralement il faut agrandir la partition disque sois même par contre.

tt va dépendre de votre offre.
Sur les VPS SSD on a les backup en option il me semble.
J'utilise les S1-xx dans le public cloud perso.

Sinon un backup de la bdd et des fichiers et un téléchargement local est tjrs bon à prendre.

alors non on n'est pas obligé de changer la taille de la partition.
Effectivement on supprime la partition puis on la recrée, mais sans toucher aux données, donc on ne perds rien. Mais un backup avant l'opération est tjrs conseillé.

Il y a une doc ovh ici : https://docs.ovh.com/fr/vps/repartitionner-vps-suite-upgrade/

Mais si cela vous "stress" de trop il ne vaut mieux pas le faire si vous n'avez pas besoin de l'espace disque additionnel...
Et de toute façon, ne faites rien sans avoir fait un backup avant.

Salut @CLAUDINEB

nope.

Pour faire simple, la partition c'est un peu le "sommaire" du disque : comment est composé le disque, où sont les secteurs, leur taille ect... c'est "juste" "l'index" de tes data, la carte routiere.
Les datas, elles, sont en dur sur un secteur spécifique (le reste des pages du livre si je reste sur la metaphore).

Lors de ce repartitionnement, tu va juste "arracher" l'index existent et en ecrire un nouveau.

Le risque est de te planté en remettant les infos de début de secteur par exemple.
Si tu dit que ton chapitre 1 commence page 58 alors qu'il est page 2... tu vas rien comprendre. Idem pour ton disque.

Donc : la manip en elle même ne va pas delete les data mais, en cas d'erreur, peu les rendre injoignable.
Backup non facultatif donc :)

Jalinn

ne fois et que je me plante, bah je dois tout restauré ?

pour résumer ?
plus simple oui :p

Dans tout les cas, toute actions de maintenance ou d'action potentiellement critique impose la présence de backup au préalable.

Il ne faut jamais prendre le risque de "jouer" avec son serveur sans avoir un plan B voir un plan C et D pour le restaurer au besoin.

Oui , c'est une option payante sur vps.
Ça reste l'option C dites avant.
La B c'est le backup manuel....
Si ton Snap plante ou es corrompu, il te faut une autre source de backup

heu je ne pense pas qu'on puisse passer d'un vps ssd à un vps cloud ram...
Et de toute façon je vous le déconseille.... Ces VMs sont nullissimes... Les perfs disques sont pitoyables et très aléatoires...

Sur la gamme vps, tu ne pourras pas changer de type de vps. Tu ne peux augmenter qu'au sein de la même gamme :
SSD 1 -> SSD 2 -> SSD 3
Cloud 1 -> cloud 2 -> cloud 3
Cloud ram 1 -> Cloud ram 2 -> Cloud ram3

Pour passer de SSD a cloud/cloud ram, tu devras prendre un NOUVEAU serveur, copier manuellement tes data entre les deux et réinstaller tout comme il faut sur le nouveau (+ nouvelle IP du coup /!\ pense a dans)

Jalinn

Hello.

Si la question sous-jacente est "est-ce qu'il va y avoir un downtime le temps de la manipulation?", La réponse est oui.

Le repartitionnement t'impose de passer en mode RESCUE au préalable.
Si tu tente l'action alors que ton serveur est sur disque, au mieux tu auras un simple message d'erreur, au pire une corruption complète de tes data.

Donc, oui, tu devras rebooter ton système.
Dans l'ordre :
- évolution du Vps (1 reboot auto par le système lors de l'action)
- reboot en rescue
- manipulation sur le système de fichiers
- reboot sur disque

Et je complète pour dire que même concernant le changement de gamme il y a redémarrage obligatoire...
L'ajout de RAM et de vcore ne se fait pas à chaud...

En gros au moment du changement de gamme le serveur est redémarré pour avoir la nouvelle config. Charge à vous ensuite de revoir la taille de la partition en rescue...

sur certaines gamme ça se fait effectivement tt seul.

Si tt fonctionne c'est parfait :)

Tant mieux !

Effectivement, sur les nouvelles gammes vps, selon ta version de cloud-init et ta conf, ça fait le job tout seul lors du démarrage du système.

C'est donc ton cas :p