# Table de partition GPT de sauvegarde corrompue

**URL:** <https://www.debian-fr.org/t/table-de-partition-gpt-de-sauvegarde-corrompue/91770>\
**Category:** Support Debian\
**Created:** [Novembre 18, 2025, 1:10 UTC](https://www.debian-fr.org/t/table-de-partition-gpt-de-sauvegarde-corrompue/91770 "2025-11-18T13:10:06Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![josephtux](https://www.debian-fr.org/user_avatar/www.debian-fr.org/josephtux/32/3985_2.png) [@josephtux](https://www.debian-fr.org/u/josephtux)\
**Post date:** [Novembre 18, 2025, 1:10 UTC](https://www.debian-fr.org/t/table-de-partition-gpt-de-sauvegarde-corrompue/91770/1 "2025-11-18T13:10:06Z")

</div>

Bonjour à tous,

`$sudo sfdisk -l` renvoie le message suivant: (la dernière ligne est en rouge)

```
Disque /dev/mapper/VG0-VAR : 45,63 GiB, 48997859328 octets, 95698944 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
La table de partitions GPT de sauvegarde est corrompue, mais la primaire semble fonctionnelle, elle sera donc utilisée.

```

Que dois-je faire?  
Faut-il réparer cette table de sauvegarde?  
Si oui comment, avec quelles précautions?

J’ai le même message sur un SSD sorti d’un PC et placé dans un support usb:

`sudo sfdisk -l /dev/sdb`

```
La table de partitions GPT de sauvegarde est corrompue, mais la primaire semble fonctionnelle, elle sera donc utilisée.
Disque /dev/sdb : 476,94 GiB, 512110190592 octets, 1000215216 secteurs
Modèle de disque : OM8SFP4512P-AH 
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 33553920 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 9F9F1FFA-4DED-4251-82DB-F03648DF7C1E

Périphérique Début Fin Secteurs Taille Type
/dev/sdb1 2048 976895 974848 476M Système EFI
/dev/sdb2 976896 1000214527 999237632 476,5G Système de fichiers Linux
```

---

<div class="post-metadata">

**Author:** ![dindoun](https://www.debian-fr.org/user_avatar/www.debian-fr.org/dindoun/32/4281_2.png) [@dindoun](https://www.debian-fr.org/u/dindoun)\
**Post date:** [Novembre 19, 2025, 4:51 UTC](https://www.debian-fr.org/t/table-de-partition-gpt-de-sauvegarde-corrompue/91770/2 "2025-11-19T16:51:01Z")

</div>

jamais fait  
ça peut aider:  
[https://forum.ubuntu-fr.org/viewtopic.php?id=2091962](https://forum.ubuntu-fr.org/viewtopic.php?id=2091962)

---

<div class="post-metadata">

**Author:** ![josephtux](https://www.debian-fr.org/user_avatar/www.debian-fr.org/josephtux/32/3985_2.png) [@josephtux](https://www.debian-fr.org/u/josephtux)\
**Post date:** [Novembre 19, 2025, 5:01 UTC](https://www.debian-fr.org/t/table-de-partition-gpt-de-sauvegarde-corrompue/91770/3 "2025-11-19T17:01:35Z")

</div>

Merci dindoun (et geole),

sur le SSD USB, ça s’est fait très simplement en suivant (aveuglément!) ce protocole avec _gdisk_:

```
**x => Afin d'utiliser le mode experts**
 **r => Afin de passer en mode recovery**? => Afin de savoir ce qu'on peut faire
**d =>> use main GPT header (rebuilding backup) afin de remettre en état le double,**
 **w => Afin d'écrire**
 **Y => Afin de confirmer l’écriture et quitter**

```

et bizarrement, le message de `sfdisk -l` concernant  
`/dev/mapper/VG0-VAR`  
a disparu spontanément.  
Peut-être un bug de _sfdisk_ ? ou une initiative de  
_gdisk_ (appelé sous la forme `gdisk /dev/usb`)