# Conseils pour upgrade ?

**URL:** <https://www.debian-fr.org/t/conseils-pour-upgrade/78481>\
**Category:** Pause Café\
**Tags:** upgrade\
**Created:** [Janvier 30, 2019, 8:02 UTC](https://www.debian-fr.org/t/conseils-pour-upgrade/78481 "2019-01-30T08:02:12Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![nicoz](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/bb73d2/32.png) [@nicoz](https://www.debian-fr.org/u/nicoz)\
**Post date:** [Janvier 30, 2019, 8:02 UTC](https://www.debian-fr.org/t/conseils-pour-upgrade/78481/1 "2019-01-30T08:02:12Z")

</div>

Ayant quelques serveurs en production (en Jessie ou Stretch), j’hésite toujours franchement à lancer des upgrades réguliers dans la mesure où ça peut très très mal se passer et causer des heures de sueurs froides à restaurer au plus vite un site offline et ses divers services … mais à un moment il faut bien en passer par là, et les failles APT récentes sont une raison solide de se lancer !

J’ai donc commencé à mettre à jour applicatif par applicatif sur une Stretch après backup complet (site, base, config) : en réglant la source.list uniquement sur du “main contrib non-free”, en vérifiant après update la policy de chaque élément de la liste --upgradable (elle est longue …) et en procédant une à une chaque install successive afin éviter le possible déraillement d’un upgrade total - qui me donne toujours l’impression d’un gros bouton rouge à code nucléaire …

Idéalement je procéderais si je le pouvais par des VMs avec un miroir de test pour mise à jour complète, vérification que tout marche dessus puis bascule DNS interne, mais je ne peux pas forcément faire cela sur certains serveurs … alors peut être qu’il y a d’autres astuces possibles que je ne connais pas permettant de faciliter ce type de problématique ?

Merci par avance de vos suggestions et conseils !

---

<div class="post-metadata">

**Author:** ![sk4hrr](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/7bcc69/32.png) [@sk4hrr](https://www.debian-fr.org/u/sk4hrr)\
**Post date:** [Janvier 30, 2019, 10:28 UTC](https://www.debian-fr.org/t/conseils-pour-upgrade/78481/2 "2019-01-30T10:28:38Z")

</div>

Bonjour,

Personnellement je fais ça en mode bourrin sur des heures non-ouvrées :

1. Création d’un instantané (snapshot)
2. Mise à jour de la liste des dépôts : `apt update`
3. Téléchargement des mises à jour: `apt dist-upgrade --download-only`
4. Installation des mises à jour: `apt upgrade`
5. Redémarrage
6. Si ça ne va pas, retour à l’instantané, sinon la suite
7. Création d’un instantané
8. Mise à jour de la distribution: `apt dist-upgrade`
9. Redémarrage
10. Si ça se passe mal, retour au à l’instantané du point 7, sinon la suite
11. Nettoyage: `apt purge --auto-remove && apt autoclean`
12. Supprimer l’instantané du point 1
13. Changement de version de Debian: `sed -i 's#jessie#stretch#g' /etc/apt/sources.list`
14. Ajouter le dépôt de sécurité de jessie: `echo "deb http://security.debian.org/debian-security jessie/updates main" >> /etc/apt/sources.list`
15. Reprendre du point 1 à 12
16. Après quelques jours, supprimer les instantanés

Jusqu’à maintenant je n’ai pas eu de réel surprise. Le travail en heure non-ouvrés permet d’avoir un peu de temps pour corriger les quelques merdouilles éventuelles.

---

<div class="post-metadata">

**Author:** ![grandtoubab](https://www.debian-fr.org/user_avatar/www.debian-fr.org/grandtoubab/32/4505_2.png) [@grandtoubab](https://www.debian-fr.org/u/grandtoubab)\
**Post date:** [Janvier 30, 2019, 11:51 UTC](https://www.debian-fr.org/t/conseils-pour-upgrade/78481/3 "2019-01-30T11:51:54Z")

</div>

> Changement de version de Debian: `sed -i 's#jessie#buster#g' /etc/apt/sources.list`

Passer de jessie à buster c’est sauter l’étape Stretch ?

> Ajouter le dépôt de sécurité de jessie: `echo "deb http://security.debian.org/debian-security stretch/updates main" >> /etc/apt/sources.list`

je vois plutôt que tu as mis le dépôt sécurité de Stretch

---

<div class="post-metadata">

**Author:** ![sk4hrr](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/7bcc69/32.png) [@sk4hrr](https://www.debian-fr.org/u/sk4hrr)\
**Post date:** [Janvier 30, 2019, 11:59 UTC](https://www.debian-fr.org/t/conseils-pour-upgrade/78481/4 "2019-01-30T11:59:32Z")

</div>

> [@grandtoubab](#):
>
> Passer de jessie à buster c’est sauter l’étape Stretch ?

Mouarf, oublié de modifier la deuxième partie, je corrige, merci !

> [@grandtoubab](#):
>
> je vois plutôt que tu as mis le dépôt sécurité de Stretch

Erf, corrigé aussi, merci !

---

<div class="post-metadata">

**Author:** ![grandtoubab](https://www.debian-fr.org/user_avatar/www.debian-fr.org/grandtoubab/32/4505_2.png) [@grandtoubab](https://www.debian-fr.org/u/grandtoubab)\
**Post date:** [Janvier 30, 2019, 12:03 UTC](https://www.debian-fr.org/t/conseils-pour-upgrade/78481/5 "2019-01-30T12:03:50Z")

</div>

Sinon quand je travaillais on avait des équipements en structure actif/stand-by.

Les changements de logiciels se faisaient sur le stand-by et quand on avait fini et on basculait le stand-by en actif puis on mettait à jour l’ancien actif.

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Janvier 30, 2019, 1:01 UTC](https://www.debian-fr.org/t/conseils-pour-upgrade/78481/6 "2019-01-30T13:01:43Z")

</div>

> [@nicoz](#):
>
> j’hésite toujours franchement à lancer des upgrades réguliers dans la mesure où ça peut très très mal se passer et causer des heures de sueurs froides à restaurer au plus vite un site offline et ses divers services …

Plus tu fais des «&nbsp;rolling updates&nbsp;», moins ça se passe mal.  
Il vaut mieux avoir un process d’update régulier genre mensuel, AMA.  
Aprés, tu peux cloner tes machines en virtualbox et tester tes updates, si tu veux t’assurer de ne pas interrompre ta production.

---

<div class="post-metadata">

**Author:** ![nicoz](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/bb73d2/32.png) [@nicoz](https://www.debian-fr.org/u/nicoz)\
**Post date:** [Janvier 30, 2019, 6:09 UTC](https://www.debian-fr.org/t/conseils-pour-upgrade/78481/7 "2019-01-30T18:09:31Z")

</div>

Merci de vos conseils, juste besoin d’une précision sur le 1er suggéré par sk4hrr :

> [@sk4hrr](#):
>
> 1. Création d’un instantané (snapshot)

Quel outil est approprié pour ça, sachant que je n’ai pas trop la possibilité de faire des VMs en terme d’espace disque et d’install …

J’ai parcouru ce guide avec Btrfs mais ça semble quand même velu à mettre en oeuvre tout comme de bidouiller le grub : [[Btrfs] Snapshot et rollback sur votre système GNU/Linux - LinuxFr.org](https://linuxfr.org/news/btrfs-snapshot-et-rollback-sur-votre-systeme-gnu-linux)

Sinon je vois que plusieurs commentateurs évoquent snapper, est-ce viable ? [I Challenge Thee](https://packages.debian.org/search?keywords=snapper)

Ou peut être encore un autre outil ?

---

<div class="post-metadata">

**Author:** ![sk4hrr](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/7bcc69/32.png) [@sk4hrr](https://www.debian-fr.org/u/sk4hrr)\
**Post date:** [Janvier 31, 2019, 1:30 UTC](https://www.debian-fr.org/t/conseils-pour-upgrade/78481/8 "2019-01-31T13:30:14Z")

</div>

Erf, effectivement, je parle d’instantané dans un contexte de virtualisation. Lorsqu’il s’agit de serveurs physique, je fais une image CloneZilla. Cela sous-entends un arrêt le temps de la sauvegarde…

---

<div class="post-metadata">

**Author:** ![grandtoubab](https://www.debian-fr.org/user_avatar/www.debian-fr.org/grandtoubab/32/4505_2.png) [@grandtoubab](https://www.debian-fr.org/u/grandtoubab)\
**Post date:** [Janvier 31, 2019, 7:36 UTC](https://www.debian-fr.org/t/conseils-pour-upgrade/78481/9 "2019-01-31T19:36:49Z")

</div>

De bonnes idées dans le guide de l’admin  
[https://www.debian.org/doc/manuals/debian-handbook/sect.regular-upgrades.fr.html](https://www.debian.org/doc/manuals/debian-handbook/sect.regular-upgrades.fr.html)

la doc Red Hat est bien faite  
[https://access.redhat.com/documentation/fr-fr/red\_hat\_enterprise\_linux/7/html/storage\_administration\_guide/ch-snapper](https://access.redhat.com/documentation/fr-fr/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-snapper)

---

<div class="post-metadata">

**Author:** ![nicoz](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/bb73d2/32.png) [@nicoz](https://www.debian-fr.org/u/nicoz)\
**Post date:** [Février 1, 2019, 3:59 UTC](https://www.debian-fr.org/t/conseils-pour-upgrade/78481/10 "2019-02-01T15:59:22Z")

</div>

Merci pour ces liens et vos conseils …

… malheureusement je ne peux en appliquer aucun car :

- mon environnement n’utilise aucune virtualisation actuellement
- Snapper n’est pas directement compatible avec les partitions ext4
- LVM2 n’accepte pas de reprendre ma partition ext4 pré-existante

Malgré de nombreuses tentatives, je n’ai pas trouver le moyen de contourner ces problèmes … je commence à me demander si je ne vais pas creuser côté virtualisation finalement, car je ne trouve aucune autre alternative locale à la Snapper qui soit du même niveau - la plupart des solutions trouvées sont plus ou moins des gros backups via rsync.

---

<div class="post-metadata">

**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\
**Post date:** [Février 1, 2019, 5:49 UTC](https://www.debian-fr.org/t/conseils-pour-upgrade/78481/11 "2019-02-01T17:49:57Z")

</div>

Si le but avant mise à jour est de faire une image de son système Clonezilla ou tout autre logiciels du même acabit suffit.
