# Apres l'execution d'un script bash j ai perdu le boot et le grub **URL:** \ **Category:** Support Debian\ **Created:** [Octobre 28, 2024, 2:51 UTC](https://www.debian-fr.org/t/apres-lexecution-dun-script-bash-j-ai-perdu-le-boot-et-le-grub/90499 "2024-10-28T14:51:12Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![safir199](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/58956e/32.png) [@safir199](https://www.debian-fr.org/u/safir199)\ **Post date:** [Octobre 28, 2024, 2:51 UTC](https://www.debian-fr.org/t/apres-lexecution-dun-script-bash-j-ai-perdu-le-boot-et-le-grub/90499/1 "2024-10-28T14:51:12Z")
Bonjour A près executer un script bash suivant : BACKUP\_DIR ="/backup/mongodb" DATE=$(date + « %Y%m%d-%H%M ») mongodump --username user --password password --out $BACKUP\_DIR/$DATE --authenticationDatabse admin; find $BACKUP\_DIR/\* -type d -mtime +7 -exec rm -rf {} \ tout est parti, ç a commencé par l’interface graphique et les menus puis je n’arrivais plus à booter la machine sous debian12 fdisk -l donne =\> ser@debian:~$ sudo fdisk -l Disk /dev/nvme0n1: 238.5 GiB, 256060514304 bytes, 500118192 sectors Disk model: SAMSUNG MZVLB256HAHQ-000H1 Units: sectors of 1 \* 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 1FDF628F-8E2A-4FBE-9928-B692B9BCDBB3 Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1050623 1048576 512M EFI System /dev/nvme0n1p2 1050624 59643903 58593280 28G Linux filesystem /dev/nvme0n1p3 59643904 61644799 2000896 977M Linux swap /dev/nvme0n1p4 61644800 500117503 438472704 209.1G Linux filesystem Disk /dev/sda: 447.1 GiB, 480103981056 bytes, 937703088 sectors Disk model: KINGSTON SA400S3 Units: sectors of 1 \* 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 2C69AF94-E460-43ED-9737-FC5F65ADC532 Device Start End Sectors Size Type /dev/sda1 34 32767 32734 16M Microsoft reserved /dev/sda2 32768 450592767 450560000 214.9G Microsoft basic data /dev/sda3 450592768 937699327 487106560 232.3G Microsoft basic data Disk /dev/sdb: 7.5 GiB, 8004829184 bytes, 15634432 sectors Disk model: USB Flash Drive Units: sectors of 1 \* 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x529e475f j’ ai des applications imprtantes sur cette machine est ce qu’il y a un moyen de recuperer mes fichiers Merci pour votre aide ---
**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:** [Octobre 28, 2024, 3:09 UTC](https://www.debian-fr.org/t/apres-lexecution-dun-script-bash-j-ai-perdu-le-boot-et-le-grub/90499/2 "2024-10-28T15:09:53Z")
salut - ta ligne de commande est celle que tu as faite ou que tu écris ici de mémoire? - l’avais-tu déjà utilisée? Je ne ferais JAMIS ça : `find $BACKUP_DIR/*` : au minimu mettre des doubles guillemets autoru du $BACKUP\_DIR ; en effet si par exemple BACKUP\_DIR="/home sauvegarde" alors sans les guillemets ça devient deux dossiers dont l’un est /home !!! à cause de l’espace mal placé - /backup/ est un dossier de / sur nvme0n1 ( /dev/nvme0n1p2 ) ou un deuxième disque dur qui n’apparaît pas ici.? - tu as perdu tout ton disque ou « seulement » /boot sinon, bien que ne connaissant pas du tout mongodump, je vois sur leur doc ([https://www.mongodb.com/docs/database-tools/mongodump/](https://www.mongodb.com/docs/database-tools/mongodump/)) qu’ils sauvegardent quelquechose ( `--uri=` e ou `--host=` ) et je ne vois rien de comparable dans ta ligne de commande . pour commencer : df -h sudo du -sh /\* ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Octobre 28, 2024, 3:34 UTC](https://www.debian-fr.org/t/apres-lexecution-dun-script-bash-j-ai-perdu-le-boot-et-le-grub/90499/3 "2024-10-28T15:34:25Z")
Peux tu nous donner le listing du script et non une partie manuelle? Le risque que tu as c’est que dans la commande `find $BACKUP_DIR/* -type d -mtime +7 -exec rm -rf {} \` si` $BACKUP_DIR` est vide, ça revient à: `find /* -type d -mtime +7 -exec rm -rf {} \` Ce qui signifie que tu as effacé tous les répertoires qui ont été modifié depuis les 7 derniers jours. Le problème c’est que si tu as tout effacé pas moyen de démarrer la machine. Il te faut une autre machine sur laquelle monter ton disque endommagé. Et de l’OS de cette deuxième machine utiliser `testdisk` (ou une autre application de récupération de données) pour tenter de récupérer les données. **Ne fait surtout aucune tentative d’écriture sur ce disque** sinon tu risques de tout perdre. Les `find $var -exec` fonctions{} \ sont dangereux, en cas d’erreur dans le `find` tu peux effectivement flinguer complètement une machine. Mieux vaut faire la commande sans l’exec manuellement pour s’assurer que le résultat du find est bien conforme à ce qu’on en attend. Concernant ta commande mongodump: `mongodump --username user --password password --out $BACKUP_DIR/$DATE --authenticationDatabse admin;` Il a donc utilisé par défaut ` localhost (127.0.0.1)` avec le `port 27017`. `authenticationDatabse` est erroné car avec une erreur de typographie =\> `authenticationDatabase="admin"` , la bdd doit etre entre double quotes. Ce que je ne comprends pas c’est que tu fait un dump de ta BDD dans un répertoire dont le find vient ensuite effacer tout les répertoires ce qui s’y trouve, y compris ce que tu viens de sauvegarder. Car `mongodump` va créer un répertoire du nom de ta base de donnée dans le répertoire de backup, donc tu aura: d:/backup/mongodb =\> $BACKUP\_DIR d:/backup/mongodb/$DATE/ d:/backup/mongodb/$DATE/admin/ `--out` est le nom du répertoire de destination de ta sauvegarde, pas celui du fichier. Donc ta commande fin va exécuter un `rm -fr` sur les répertoires: d:/backup/mongodb/$DATE/ d:/backup/mongodb/$DATE/admin/ ---
**Author:** ![safir199](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/58956e/32.png) [@safir199](https://www.debian-fr.org/u/safir199)\ **Post date:** [Octobre 28, 2024, 6:11 UTC](https://www.debian-fr.org/t/apres-lexecution-dun-script-bash-j-ai-perdu-le-boot-et-le-grub/90499/4 "2024-10-28T18:11:42Z")
Merci Dindoun , Zargos pour votre éclairage je pense que j’ai fait une grande bourde le disque sur lequel je boot est le nvme avec deux partition nvme0n1p4 et nvme0n1p2 les deux autres on est êtes crée par debian je vais installer un disque ssd sur lequel j’installe debian 12 et je vais essayer testdisk merci encore pour vos conseils ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Octobre 28, 2024, 6:17 UTC](https://www.debian-fr.org/t/apres-lexecution-dun-script-bash-j-ai-perdu-le-boot-et-le-grub/90499/5 "2024-10-28T18:17:34Z")
tu peux aussi essayer avec un livecd ---
**Author:** ![safir199](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/58956e/32.png) [@safir199](https://www.debian-fr.org/u/safir199)\ **Post date:** [Octobre 28, 2024, 6:23 UTC](https://www.debian-fr.org/t/apres-lexecution-dun-script-bash-j-ai-perdu-le-boot-et-le-grub/90499/6 "2024-10-28T18:23:16Z")
j ai essayé avec une cle usb mais testdisk ne reconnais que le disque dur sda ---
**Author:** ![safir199](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/58956e/32.png) [@safir199](https://www.debian-fr.org/u/safir199)\ **Post date:** [Octobre 28, 2024, 6:59 UTC](https://www.debian-fr.org/t/apres-lexecution-dun-script-bash-j-ai-perdu-le-boot-et-le-grub/90499/7 "2024-10-28T18:59:31Z")
je suis arrivé a monter les disques nvme quel est l’outil idéal pour récupérer les fichiers perdus ``` foremost, extundelete, magicrescue ---
**Author:** ![safir199](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/58956e/32.png) [@safir199](https://www.debian-fr.org/u/safir199)\ **Post date:** [Octobre 29, 2024, 9:03 UTC](https://www.debian-fr.org/t/apres-lexecution-dun-script-bash-j-ai-perdu-le-boot-et-le-grub/90499/8 "2024-10-29T09:03:34Z")
bonjour Zargos le script est : #!/bin/bash # Configurations DATE=$(date +« %Y%m%d-%H%M ») BACKUP\_DIR=« /backup/mongodb » MONGO\_USER=« your\_username » MONGO\_PASSWORD=« your\_password » # Créer le répertoire de backup si non existant mkdir -p $BACKUP\_DIR/$DATE # Effectuer le backup mongodump --username $MONGO\_USER --password $MONGO\_PASSWORD --out $BACKUP\_DIR/$DATE --authenticationDatabase admin # Supprimer les backups plus anciens que 7 jours find $BACKUP\_DIR/\* -type d -mtime +7 -exec rm -rf {} ; je l’ai inséré dans une crontabl comme suit: 0 3 \* \* \* /usr/local/bin/backup-mongodb.sh \>\> /var/log/mongodb\_backup.log 2\>&1 voila la commande test qui a tout effacé sudo /usr/local/bin/backup-mongodb.sh après cett commande tout s’est enchainé rapidement est j ai perdu ma machine et mes applications react node mongodb (trois mois de travail) S 'il y a un moyen de récupérer quelque chose vous me l’indiquez Merci pour votre aide ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Octobre 29, 2024, 9:25 UTC](https://www.debian-fr.org/t/apres-lexecution-dun-script-bash-j-ai-perdu-le-boot-et-le-grub/90499/9 "2024-10-29T09:25:16Z")
Oui donc c’est bien ca, ta ligne find n’est pas bonne. Dans ton script: Remplacer `BACKUP_DIR="/backup/mongodb"` par `export BACKUP_DIR="/backup/mongodb"` Remplacer `mkdir -p $BACKUP_DIR/$DATE` par `[-d $BACKUP_DIR/$DATE] && mkdir -p $BACKUP_DIR/$DATE` Remplacer `find $BACKUP_DIR/* -type d -mtime +7 -exec rm -rf {} ;` par `find $BACKUP_DIR/$DATE/admin/* -type d -mtime +7 -exec rm -rf {} ;` Pour récupérer tes données, il va te falloir utiliser un outil de récupération de données que tu peux lancer à partir d’un livecd avec (tu utilises apt dans une console de la livecd en root[sudo su -]): - testdisk (préféré) - extundelete AUPARAVANT: il est judicieux de faire un clone de ta(tes) partition(s): - Soit à partir d’un livecd et de la commande dd - Soit à partir d’une iso de clonezilla Ceci afin de conserver l’état actuel avant toute tentative. Il te faudra de fait un stockage assez grand pour conserver ces données, soit distant sur un autre serveur qui a assez de stockage, soit sur un disque externe qui a assez de stockage disponible aussi. ---
**Author:** ![safir199](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/58956e/32.png) [@safir199](https://www.debian-fr.org/u/safir199)\ **Post date:** [Octobre 29, 2024, 4:55 UTC](https://www.debian-fr.org/t/apres-lexecution-dun-script-bash-j-ai-perdu-le-boot-et-le-grub/90499/10 "2024-10-29T16:55:12Z")
Problème : Quand j’utilise testdisk il ne trouve que les partitions sda pas nvme ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Octobre 29, 2024, 8:07 UTC](https://www.debian-fr.org/t/apres-lexecution-dun-script-bash-j-ai-perdu-le-boot-et-le-grub/90499/11 "2024-10-29T20:07:51Z")
Peux-tu nous afficher ce qui correspond à cet affichage réalisé sur ma machine: ```auto TestDisk 7.1, Data Recovery Utility, July 2019 Christophe GRENIER https://www.cgsecurity.org TestDisk is free software, and comes with ABSOLUTELY NO WARRANTY. Select a media (use Arrow keys, then press Enter): >Disk /dev/sda - 960 GB / 894 GiB - CT960BX500SSD1 Disk /dev/sdb - 1000 GB / 931 GiB - ST1000LX015-1U7172 Disk /dev/sdc - 2000 GB / 1863 GiB - Samsung SSD 870 QVO 2TB Disk /dev/sdd - 960 GB / 894 GiB - CT960BX500SSD1 Disk /dev/mapper/zvg01-boot - 499 MB / 476 MiB Disk /dev/mapper/zvg01-home - 3149 GB / 2932 GiB Disk /dev/mapper/zvg01-root - 99 GB / 93 GiB Disk /dev/mapper/zvg01-swap - 31 GB / 29 GiB Disk /dev/mapper/zvg01-tmp - 4999 MB / 4768 MiB Disk /dev/mapper/zvg01-var - 99 GB / 93 GiB Disk /dev/mapper/zvg01-var_log - 9999 MB / 9536 MiB Disk /dev/mapper/zvg01-var_log_audit - 14 GB / 13 GiB Disk /dev/mapper/zvg01-var_tmp - 4999 MB / 4768 MiB Disk /dev/dm-0 - 499 MB / 476 MiB Disk /dev/dm-1 - 99 GB / 93 GiB Disk /dev/dm-2 - 31 GB / 29 GiB Disk /dev/dm-3 - 99 GB / 93 GiB Disk /dev/dm-4 - 9999 MB / 9536 MiB Disk /dev/dm-5 - 14 GB / 13 GiB Disk /dev/dm-6 - 4999 MB / 4768 MiB Disk /dev/dm-7 - 4999 MB / 4768 MiB Disk /dev/dm-8 - 3149 GB / 2932 GiB Disk /dev/nvme0n1 - 2000 GB / 1863 GiB Disk /dev/nvme1n1 - 2000 GB / 1863 GiB >[Proceed] [Quit] Note: Disk capacity must be correctly detected for a successful recovery. If a disk listed above has an incorrect size, check HD jumper settings and BIOS detection, and install the latest OS patches and disk drivers. ```