Database accidentally deleted with a bash script [duplicate]












9
















This question already has an answer here:




  • Monday morning mistake: sudo rm -rf --no-preserve-root /

    10 answers




Edit: a follow-up question: Restore mongoDB by --repair and WiredTiger.



My developer committed a huge mistake and we cannot find our Mongo database anywhere in the server.



He logged into the server, and saved the following shell under ~/crontab/mongod_back.sh:



mongod_back.sh



#!/bin/sh
DUMP=mongodump
OUT_DIR=/data/backup/mongod/tmp // 备份文件临时目录
TAR_DIR=/data/backup/mongod // 备份文件正式目录
DATE=`date +%Y_%m_%d_%H_%M_%S` // 备份文件将以备份对间保存
DB_USER=Guitang // 数库操作员
DB_PASS=qq■■■■■■■■■■■■■■■■■■■■■ // 数掘库操作员密码
DAYS=14 // 保留最新14天的份
TARBAK="mongod_bak_$DATE.tar.gz" // 备份文件命名格式
cd $OUT_DIR // 创建文件夹
rm -rf $OUT_DIR/* // 清空临时目录
mkdir -p $OUT_DIR/$DATE // 创建本次备份文件夹
$DUMP -d wecard -u $DB_USER -p $DB_PASS -o $OUT_DIR/$DATE // 执行备份命令
tar -zcvf $TAR_DIR/$TAR_BAK $OUT_DIR/$DATE // 将份文件打包放入正式
find $TAR_DIR/ -mtime +$DAYS -delete // 除14天前的旧备


And then he ran it and it outputted permission denied messages, so he pressed Ctrl+C. The server shut down automatically. He tried to restart it but got a grub error:



GRUB



He contacted AliCloud, the engineer connected the disk to another working server so that he could check the disk. Looks like some folders are gone, including /data/ where the mongodb is!




  1. We don't understand how the script could destroy the disk including /data/;

  2. And of course, is it possible to get the /data/ back?


PS: He did not take snapshot of the disk before.



PS2: As people mention "backups" a lot, we have lots of important users and data coming these 2 days, the purpose of this action was to backup them (for the first time), then they turned out to be entirely deleted.










share|improve this question















marked as duplicate by Jenny D, womble yesterday


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.














  • 4





    Your script has no error checking. If the line cd $OUT_DIR fails, it's going to delete everything in the current path, which may well be / . This is why you have backups - use them.

    – Jenny D
    yesterday











  • He run the shell under ~/crontab/, how could rm or find -delete delete folders under /?

    – SoftTimur
    yesterday








  • 8





    Wow - did this script get into your version control system? Did it go through peer review? rm -rf $OUT_DIR/* really? And why was the script not tested on a non-production server? Once you have restored from backup you have many critical procedural failings to address here before automating anything else. I hope you're not too hard on your developer over it, as a result (though they also have quite a bit to answer for)

    – Lightness Races in Orbit
    yesterday








  • 3





    Re: this was to be your backup script, never test a new procedure against the only copy of your data. Prior to your very first backup, create a separate test database, put in some fake data, and restore test that.

    – John Mahowald
    yesterday






  • 2





    Two suggestions to improve your questions: 1) use all-English. The problem with the non-English content is that people don't understanding it, also don't know if it is important or not. Thus, they can't be sure that their answer is okay, and thus they tend to rather don't answer. 2) If you can use textual copy-paste, use that and never use screenshots.

    – peterh
    20 hours ago
















9
















This question already has an answer here:




  • Monday morning mistake: sudo rm -rf --no-preserve-root /

    10 answers




Edit: a follow-up question: Restore mongoDB by --repair and WiredTiger.



My developer committed a huge mistake and we cannot find our Mongo database anywhere in the server.



He logged into the server, and saved the following shell under ~/crontab/mongod_back.sh:



mongod_back.sh



#!/bin/sh
DUMP=mongodump
OUT_DIR=/data/backup/mongod/tmp // 备份文件临时目录
TAR_DIR=/data/backup/mongod // 备份文件正式目录
DATE=`date +%Y_%m_%d_%H_%M_%S` // 备份文件将以备份对间保存
DB_USER=Guitang // 数库操作员
DB_PASS=qq■■■■■■■■■■■■■■■■■■■■■ // 数掘库操作员密码
DAYS=14 // 保留最新14天的份
TARBAK="mongod_bak_$DATE.tar.gz" // 备份文件命名格式
cd $OUT_DIR // 创建文件夹
rm -rf $OUT_DIR/* // 清空临时目录
mkdir -p $OUT_DIR/$DATE // 创建本次备份文件夹
$DUMP -d wecard -u $DB_USER -p $DB_PASS -o $OUT_DIR/$DATE // 执行备份命令
tar -zcvf $TAR_DIR/$TAR_BAK $OUT_DIR/$DATE // 将份文件打包放入正式
find $TAR_DIR/ -mtime +$DAYS -delete // 除14天前的旧备


And then he ran it and it outputted permission denied messages, so he pressed Ctrl+C. The server shut down automatically. He tried to restart it but got a grub error:



GRUB



He contacted AliCloud, the engineer connected the disk to another working server so that he could check the disk. Looks like some folders are gone, including /data/ where the mongodb is!




  1. We don't understand how the script could destroy the disk including /data/;

  2. And of course, is it possible to get the /data/ back?


PS: He did not take snapshot of the disk before.



PS2: As people mention "backups" a lot, we have lots of important users and data coming these 2 days, the purpose of this action was to backup them (for the first time), then they turned out to be entirely deleted.










share|improve this question















marked as duplicate by Jenny D, womble yesterday


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.














  • 4





    Your script has no error checking. If the line cd $OUT_DIR fails, it's going to delete everything in the current path, which may well be / . This is why you have backups - use them.

    – Jenny D
    yesterday











  • He run the shell under ~/crontab/, how could rm or find -delete delete folders under /?

    – SoftTimur
    yesterday








  • 8





    Wow - did this script get into your version control system? Did it go through peer review? rm -rf $OUT_DIR/* really? And why was the script not tested on a non-production server? Once you have restored from backup you have many critical procedural failings to address here before automating anything else. I hope you're not too hard on your developer over it, as a result (though they also have quite a bit to answer for)

    – Lightness Races in Orbit
    yesterday








  • 3





    Re: this was to be your backup script, never test a new procedure against the only copy of your data. Prior to your very first backup, create a separate test database, put in some fake data, and restore test that.

    – John Mahowald
    yesterday






  • 2





    Two suggestions to improve your questions: 1) use all-English. The problem with the non-English content is that people don't understanding it, also don't know if it is important or not. Thus, they can't be sure that their answer is okay, and thus they tend to rather don't answer. 2) If you can use textual copy-paste, use that and never use screenshots.

    – peterh
    20 hours ago














9












9








9


4







This question already has an answer here:




  • Monday morning mistake: sudo rm -rf --no-preserve-root /

    10 answers




Edit: a follow-up question: Restore mongoDB by --repair and WiredTiger.



My developer committed a huge mistake and we cannot find our Mongo database anywhere in the server.



He logged into the server, and saved the following shell under ~/crontab/mongod_back.sh:



mongod_back.sh



#!/bin/sh
DUMP=mongodump
OUT_DIR=/data/backup/mongod/tmp // 备份文件临时目录
TAR_DIR=/data/backup/mongod // 备份文件正式目录
DATE=`date +%Y_%m_%d_%H_%M_%S` // 备份文件将以备份对间保存
DB_USER=Guitang // 数库操作员
DB_PASS=qq■■■■■■■■■■■■■■■■■■■■■ // 数掘库操作员密码
DAYS=14 // 保留最新14天的份
TARBAK="mongod_bak_$DATE.tar.gz" // 备份文件命名格式
cd $OUT_DIR // 创建文件夹
rm -rf $OUT_DIR/* // 清空临时目录
mkdir -p $OUT_DIR/$DATE // 创建本次备份文件夹
$DUMP -d wecard -u $DB_USER -p $DB_PASS -o $OUT_DIR/$DATE // 执行备份命令
tar -zcvf $TAR_DIR/$TAR_BAK $OUT_DIR/$DATE // 将份文件打包放入正式
find $TAR_DIR/ -mtime +$DAYS -delete // 除14天前的旧备


And then he ran it and it outputted permission denied messages, so he pressed Ctrl+C. The server shut down automatically. He tried to restart it but got a grub error:



GRUB



He contacted AliCloud, the engineer connected the disk to another working server so that he could check the disk. Looks like some folders are gone, including /data/ where the mongodb is!




  1. We don't understand how the script could destroy the disk including /data/;

  2. And of course, is it possible to get the /data/ back?


PS: He did not take snapshot of the disk before.



PS2: As people mention "backups" a lot, we have lots of important users and data coming these 2 days, the purpose of this action was to backup them (for the first time), then they turned out to be entirely deleted.










share|improve this question

















This question already has an answer here:




  • Monday morning mistake: sudo rm -rf --no-preserve-root /

    10 answers




Edit: a follow-up question: Restore mongoDB by --repair and WiredTiger.



My developer committed a huge mistake and we cannot find our Mongo database anywhere in the server.



He logged into the server, and saved the following shell under ~/crontab/mongod_back.sh:



mongod_back.sh



#!/bin/sh
DUMP=mongodump
OUT_DIR=/data/backup/mongod/tmp // 备份文件临时目录
TAR_DIR=/data/backup/mongod // 备份文件正式目录
DATE=`date +%Y_%m_%d_%H_%M_%S` // 备份文件将以备份对间保存
DB_USER=Guitang // 数库操作员
DB_PASS=qq■■■■■■■■■■■■■■■■■■■■■ // 数掘库操作员密码
DAYS=14 // 保留最新14天的份
TARBAK="mongod_bak_$DATE.tar.gz" // 备份文件命名格式
cd $OUT_DIR // 创建文件夹
rm -rf $OUT_DIR/* // 清空临时目录
mkdir -p $OUT_DIR/$DATE // 创建本次备份文件夹
$DUMP -d wecard -u $DB_USER -p $DB_PASS -o $OUT_DIR/$DATE // 执行备份命令
tar -zcvf $TAR_DIR/$TAR_BAK $OUT_DIR/$DATE // 将份文件打包放入正式
find $TAR_DIR/ -mtime +$DAYS -delete // 除14天前的旧备


And then he ran it and it outputted permission denied messages, so he pressed Ctrl+C. The server shut down automatically. He tried to restart it but got a grub error:



GRUB



He contacted AliCloud, the engineer connected the disk to another working server so that he could check the disk. Looks like some folders are gone, including /data/ where the mongodb is!




  1. We don't understand how the script could destroy the disk including /data/;

  2. And of course, is it possible to get the /data/ back?


PS: He did not take snapshot of the disk before.



PS2: As people mention "backups" a lot, we have lots of important users and data coming these 2 days, the purpose of this action was to backup them (for the first time), then they turned out to be entirely deleted.





This question already has an answer here:




  • Monday morning mistake: sudo rm -rf --no-preserve-root /

    10 answers








filesystems shell ubuntu-14.04 data-recovery disaster-recovery






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 14 hours ago







SoftTimur

















asked yesterday









SoftTimurSoftTimur

1238




1238




marked as duplicate by Jenny D, womble yesterday


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.









marked as duplicate by Jenny D, womble yesterday


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.










  • 4





    Your script has no error checking. If the line cd $OUT_DIR fails, it's going to delete everything in the current path, which may well be / . This is why you have backups - use them.

    – Jenny D
    yesterday











  • He run the shell under ~/crontab/, how could rm or find -delete delete folders under /?

    – SoftTimur
    yesterday








  • 8





    Wow - did this script get into your version control system? Did it go through peer review? rm -rf $OUT_DIR/* really? And why was the script not tested on a non-production server? Once you have restored from backup you have many critical procedural failings to address here before automating anything else. I hope you're not too hard on your developer over it, as a result (though they also have quite a bit to answer for)

    – Lightness Races in Orbit
    yesterday








  • 3





    Re: this was to be your backup script, never test a new procedure against the only copy of your data. Prior to your very first backup, create a separate test database, put in some fake data, and restore test that.

    – John Mahowald
    yesterday






  • 2





    Two suggestions to improve your questions: 1) use all-English. The problem with the non-English content is that people don't understanding it, also don't know if it is important or not. Thus, they can't be sure that their answer is okay, and thus they tend to rather don't answer. 2) If you can use textual copy-paste, use that and never use screenshots.

    – peterh
    20 hours ago














  • 4





    Your script has no error checking. If the line cd $OUT_DIR fails, it's going to delete everything in the current path, which may well be / . This is why you have backups - use them.

    – Jenny D
    yesterday











  • He run the shell under ~/crontab/, how could rm or find -delete delete folders under /?

    – SoftTimur
    yesterday








  • 8





    Wow - did this script get into your version control system? Did it go through peer review? rm -rf $OUT_DIR/* really? And why was the script not tested on a non-production server? Once you have restored from backup you have many critical procedural failings to address here before automating anything else. I hope you're not too hard on your developer over it, as a result (though they also have quite a bit to answer for)

    – Lightness Races in Orbit
    yesterday








  • 3





    Re: this was to be your backup script, never test a new procedure against the only copy of your data. Prior to your very first backup, create a separate test database, put in some fake data, and restore test that.

    – John Mahowald
    yesterday






  • 2





    Two suggestions to improve your questions: 1) use all-English. The problem with the non-English content is that people don't understanding it, also don't know if it is important or not. Thus, they can't be sure that their answer is okay, and thus they tend to rather don't answer. 2) If you can use textual copy-paste, use that and never use screenshots.

    – peterh
    20 hours ago








4




4





Your script has no error checking. If the line cd $OUT_DIR fails, it's going to delete everything in the current path, which may well be / . This is why you have backups - use them.

– Jenny D
yesterday





Your script has no error checking. If the line cd $OUT_DIR fails, it's going to delete everything in the current path, which may well be / . This is why you have backups - use them.

– Jenny D
yesterday













He run the shell under ~/crontab/, how could rm or find -delete delete folders under /?

– SoftTimur
yesterday







He run the shell under ~/crontab/, how could rm or find -delete delete folders under /?

– SoftTimur
yesterday






8




8





Wow - did this script get into your version control system? Did it go through peer review? rm -rf $OUT_DIR/* really? And why was the script not tested on a non-production server? Once you have restored from backup you have many critical procedural failings to address here before automating anything else. I hope you're not too hard on your developer over it, as a result (though they also have quite a bit to answer for)

– Lightness Races in Orbit
yesterday







Wow - did this script get into your version control system? Did it go through peer review? rm -rf $OUT_DIR/* really? And why was the script not tested on a non-production server? Once you have restored from backup you have many critical procedural failings to address here before automating anything else. I hope you're not too hard on your developer over it, as a result (though they also have quite a bit to answer for)

– Lightness Races in Orbit
yesterday






3




3





Re: this was to be your backup script, never test a new procedure against the only copy of your data. Prior to your very first backup, create a separate test database, put in some fake data, and restore test that.

– John Mahowald
yesterday





Re: this was to be your backup script, never test a new procedure against the only copy of your data. Prior to your very first backup, create a separate test database, put in some fake data, and restore test that.

– John Mahowald
yesterday




2




2





Two suggestions to improve your questions: 1) use all-English. The problem with the non-English content is that people don't understanding it, also don't know if it is important or not. Thus, they can't be sure that their answer is okay, and thus they tend to rather don't answer. 2) If you can use textual copy-paste, use that and never use screenshots.

– peterh
20 hours ago





Two suggestions to improve your questions: 1) use all-English. The problem with the non-English content is that people don't understanding it, also don't know if it is important or not. Thus, they can't be sure that their answer is okay, and thus they tend to rather don't answer. 2) If you can use textual copy-paste, use that and never use screenshots.

– peterh
20 hours ago










3 Answers
3






active

oldest

votes


















34














Easy enough. The // sequence isn't a comment in bash (# is).



The statement OUT_DIR=x // text had no effect* except a cryptic error message.



Thus, with the OUT_DIR being an empty string, one of the commands eventually executed was rm -rf /*. Some directories placed directly underneath / weren't removed due to user not having permissions, but it appears that some vital directories were removed. You need to restore from backup.





* The peculiar form of bash statement A=b c d e f is roughly similar to:



export A=b
c d e f
unset A


A common example:



export VISUAL=vi                       # A standard visual editor to use is `vi`
visudo -f dummy_sudoers1 # Starts vi to edit a fake sudo config. Type :q! to exit
VISUAL=nano visudo -f dummy_sudoers2 # Starts nano to edit a fake sudo config
visudo -f dummy_sudoers3 # Starts vi again (!)


And the problematic line of script amounted to this:



export OUT_DIR=/data/backup/mongod/tmp
// 备份文件临时目录 # shell error as `//` isn't an executable file!
unset OUT_DIR





share|improve this answer





















  • 1





    This is one of the reasons I always use set -euo pipefail, would have resulted in an exit instead of blundering forward with unset variables

    – ThisGuy
    10 hours ago



















7














1) He erroneously assumed that // was a bash comment. It is not, only # is.



The shell interpreted // text as a normal command, and did not find a binary called //, and did nothing.



In bash, when you have a variable assignment (OUT_DIR=/data/backup/mongod/tmp) directly preceding a command (// text), it only sets the variable while running the command. Therefore, it unsets OUT_DIR immediately, and when the rm line is reached, OUT_DIR is now unset, and rm -rf / is now called, deleting everything you have permission to delete.



2) The solution is the same as all rm -rf / cases: restore from backup. There is no other solution because you do not have physical access to the hard drive.






share|improve this answer








New contributor




Ray Wu is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





















  • why having physical access to the hard drive may help to restore?

    – SoftTimur
    yesterday






  • 1





    Possible forensics, professional hard drive recovery methods. I know this because I know that rm -rf is not extremely secure, and doesn't overwrite the hard drive.

    – Ray Wu
    yesterday






  • 2





    @SoftTimur rm usually just "unlinks" files but the data is still physically there until overwritten. This is why professionals can "undelete" sometimes if they have physical access and you haven't done lots of things with the disk after the catastrophe occurred. If you don't have backups, that's the best you can hope for.

    – Lightness Races in Orbit
    yesterday











  • You don't need physical access, with almost no disk activity since the deletion file restore utilities might be able to relatively easily find almost everything

    – ThisGuy
    10 hours ago



















3














1) Bash comments start with #. Sorry for your loss.
2) Restore from backup is the only way to proceed here, unfortunately.






share|improve this answer








New contributor




RMPJ is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.



























    3 Answers
    3






    active

    oldest

    votes








    3 Answers
    3






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    34














    Easy enough. The // sequence isn't a comment in bash (# is).



    The statement OUT_DIR=x // text had no effect* except a cryptic error message.



    Thus, with the OUT_DIR being an empty string, one of the commands eventually executed was rm -rf /*. Some directories placed directly underneath / weren't removed due to user not having permissions, but it appears that some vital directories were removed. You need to restore from backup.





    * The peculiar form of bash statement A=b c d e f is roughly similar to:



    export A=b
    c d e f
    unset A


    A common example:



    export VISUAL=vi                       # A standard visual editor to use is `vi`
    visudo -f dummy_sudoers1 # Starts vi to edit a fake sudo config. Type :q! to exit
    VISUAL=nano visudo -f dummy_sudoers2 # Starts nano to edit a fake sudo config
    visudo -f dummy_sudoers3 # Starts vi again (!)


    And the problematic line of script amounted to this:



    export OUT_DIR=/data/backup/mongod/tmp
    // 备份文件临时目录 # shell error as `//` isn't an executable file!
    unset OUT_DIR





    share|improve this answer





















    • 1





      This is one of the reasons I always use set -euo pipefail, would have resulted in an exit instead of blundering forward with unset variables

      – ThisGuy
      10 hours ago
















    34














    Easy enough. The // sequence isn't a comment in bash (# is).



    The statement OUT_DIR=x // text had no effect* except a cryptic error message.



    Thus, with the OUT_DIR being an empty string, one of the commands eventually executed was rm -rf /*. Some directories placed directly underneath / weren't removed due to user not having permissions, but it appears that some vital directories were removed. You need to restore from backup.





    * The peculiar form of bash statement A=b c d e f is roughly similar to:



    export A=b
    c d e f
    unset A


    A common example:



    export VISUAL=vi                       # A standard visual editor to use is `vi`
    visudo -f dummy_sudoers1 # Starts vi to edit a fake sudo config. Type :q! to exit
    VISUAL=nano visudo -f dummy_sudoers2 # Starts nano to edit a fake sudo config
    visudo -f dummy_sudoers3 # Starts vi again (!)


    And the problematic line of script amounted to this:



    export OUT_DIR=/data/backup/mongod/tmp
    // 备份文件临时目录 # shell error as `//` isn't an executable file!
    unset OUT_DIR





    share|improve this answer





















    • 1





      This is one of the reasons I always use set -euo pipefail, would have resulted in an exit instead of blundering forward with unset variables

      – ThisGuy
      10 hours ago














    34












    34








    34







    Easy enough. The // sequence isn't a comment in bash (# is).



    The statement OUT_DIR=x // text had no effect* except a cryptic error message.



    Thus, with the OUT_DIR being an empty string, one of the commands eventually executed was rm -rf /*. Some directories placed directly underneath / weren't removed due to user not having permissions, but it appears that some vital directories were removed. You need to restore from backup.





    * The peculiar form of bash statement A=b c d e f is roughly similar to:



    export A=b
    c d e f
    unset A


    A common example:



    export VISUAL=vi                       # A standard visual editor to use is `vi`
    visudo -f dummy_sudoers1 # Starts vi to edit a fake sudo config. Type :q! to exit
    VISUAL=nano visudo -f dummy_sudoers2 # Starts nano to edit a fake sudo config
    visudo -f dummy_sudoers3 # Starts vi again (!)


    And the problematic line of script amounted to this:



    export OUT_DIR=/data/backup/mongod/tmp
    // 备份文件临时目录 # shell error as `//` isn't an executable file!
    unset OUT_DIR





    share|improve this answer















    Easy enough. The // sequence isn't a comment in bash (# is).



    The statement OUT_DIR=x // text had no effect* except a cryptic error message.



    Thus, with the OUT_DIR being an empty string, one of the commands eventually executed was rm -rf /*. Some directories placed directly underneath / weren't removed due to user not having permissions, but it appears that some vital directories were removed. You need to restore from backup.





    * The peculiar form of bash statement A=b c d e f is roughly similar to:



    export A=b
    c d e f
    unset A


    A common example:



    export VISUAL=vi                       # A standard visual editor to use is `vi`
    visudo -f dummy_sudoers1 # Starts vi to edit a fake sudo config. Type :q! to exit
    VISUAL=nano visudo -f dummy_sudoers2 # Starts nano to edit a fake sudo config
    visudo -f dummy_sudoers3 # Starts vi again (!)


    And the problematic line of script amounted to this:



    export OUT_DIR=/data/backup/mongod/tmp
    // 备份文件临时目录 # shell error as `//` isn't an executable file!
    unset OUT_DIR






    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited 19 hours ago

























    answered yesterday









    kubanczykkubanczyk

    10.4k22845




    10.4k22845








    • 1





      This is one of the reasons I always use set -euo pipefail, would have resulted in an exit instead of blundering forward with unset variables

      – ThisGuy
      10 hours ago














    • 1





      This is one of the reasons I always use set -euo pipefail, would have resulted in an exit instead of blundering forward with unset variables

      – ThisGuy
      10 hours ago








    1




    1





    This is one of the reasons I always use set -euo pipefail, would have resulted in an exit instead of blundering forward with unset variables

    – ThisGuy
    10 hours ago





    This is one of the reasons I always use set -euo pipefail, would have resulted in an exit instead of blundering forward with unset variables

    – ThisGuy
    10 hours ago













    7














    1) He erroneously assumed that // was a bash comment. It is not, only # is.



    The shell interpreted // text as a normal command, and did not find a binary called //, and did nothing.



    In bash, when you have a variable assignment (OUT_DIR=/data/backup/mongod/tmp) directly preceding a command (// text), it only sets the variable while running the command. Therefore, it unsets OUT_DIR immediately, and when the rm line is reached, OUT_DIR is now unset, and rm -rf / is now called, deleting everything you have permission to delete.



    2) The solution is the same as all rm -rf / cases: restore from backup. There is no other solution because you do not have physical access to the hard drive.






    share|improve this answer








    New contributor




    Ray Wu is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.





















    • why having physical access to the hard drive may help to restore?

      – SoftTimur
      yesterday






    • 1





      Possible forensics, professional hard drive recovery methods. I know this because I know that rm -rf is not extremely secure, and doesn't overwrite the hard drive.

      – Ray Wu
      yesterday






    • 2





      @SoftTimur rm usually just "unlinks" files but the data is still physically there until overwritten. This is why professionals can "undelete" sometimes if they have physical access and you haven't done lots of things with the disk after the catastrophe occurred. If you don't have backups, that's the best you can hope for.

      – Lightness Races in Orbit
      yesterday











    • You don't need physical access, with almost no disk activity since the deletion file restore utilities might be able to relatively easily find almost everything

      – ThisGuy
      10 hours ago
















    7














    1) He erroneously assumed that // was a bash comment. It is not, only # is.



    The shell interpreted // text as a normal command, and did not find a binary called //, and did nothing.



    In bash, when you have a variable assignment (OUT_DIR=/data/backup/mongod/tmp) directly preceding a command (// text), it only sets the variable while running the command. Therefore, it unsets OUT_DIR immediately, and when the rm line is reached, OUT_DIR is now unset, and rm -rf / is now called, deleting everything you have permission to delete.



    2) The solution is the same as all rm -rf / cases: restore from backup. There is no other solution because you do not have physical access to the hard drive.






    share|improve this answer








    New contributor




    Ray Wu is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.





















    • why having physical access to the hard drive may help to restore?

      – SoftTimur
      yesterday






    • 1





      Possible forensics, professional hard drive recovery methods. I know this because I know that rm -rf is not extremely secure, and doesn't overwrite the hard drive.

      – Ray Wu
      yesterday






    • 2





      @SoftTimur rm usually just "unlinks" files but the data is still physically there until overwritten. This is why professionals can "undelete" sometimes if they have physical access and you haven't done lots of things with the disk after the catastrophe occurred. If you don't have backups, that's the best you can hope for.

      – Lightness Races in Orbit
      yesterday











    • You don't need physical access, with almost no disk activity since the deletion file restore utilities might be able to relatively easily find almost everything

      – ThisGuy
      10 hours ago














    7












    7








    7







    1) He erroneously assumed that // was a bash comment. It is not, only # is.



    The shell interpreted // text as a normal command, and did not find a binary called //, and did nothing.



    In bash, when you have a variable assignment (OUT_DIR=/data/backup/mongod/tmp) directly preceding a command (// text), it only sets the variable while running the command. Therefore, it unsets OUT_DIR immediately, and when the rm line is reached, OUT_DIR is now unset, and rm -rf / is now called, deleting everything you have permission to delete.



    2) The solution is the same as all rm -rf / cases: restore from backup. There is no other solution because you do not have physical access to the hard drive.






    share|improve this answer








    New contributor




    Ray Wu is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.










    1) He erroneously assumed that // was a bash comment. It is not, only # is.



    The shell interpreted // text as a normal command, and did not find a binary called //, and did nothing.



    In bash, when you have a variable assignment (OUT_DIR=/data/backup/mongod/tmp) directly preceding a command (// text), it only sets the variable while running the command. Therefore, it unsets OUT_DIR immediately, and when the rm line is reached, OUT_DIR is now unset, and rm -rf / is now called, deleting everything you have permission to delete.



    2) The solution is the same as all rm -rf / cases: restore from backup. There is no other solution because you do not have physical access to the hard drive.







    share|improve this answer








    New contributor




    Ray Wu is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.









    share|improve this answer



    share|improve this answer






    New contributor




    Ray Wu is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.









    answered yesterday









    Ray WuRay Wu

    711




    711




    New contributor




    Ray Wu is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.





    New contributor





    Ray Wu is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.






    Ray Wu is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.













    • why having physical access to the hard drive may help to restore?

      – SoftTimur
      yesterday






    • 1





      Possible forensics, professional hard drive recovery methods. I know this because I know that rm -rf is not extremely secure, and doesn't overwrite the hard drive.

      – Ray Wu
      yesterday






    • 2





      @SoftTimur rm usually just "unlinks" files but the data is still physically there until overwritten. This is why professionals can "undelete" sometimes if they have physical access and you haven't done lots of things with the disk after the catastrophe occurred. If you don't have backups, that's the best you can hope for.

      – Lightness Races in Orbit
      yesterday











    • You don't need physical access, with almost no disk activity since the deletion file restore utilities might be able to relatively easily find almost everything

      – ThisGuy
      10 hours ago



















    • why having physical access to the hard drive may help to restore?

      – SoftTimur
      yesterday






    • 1





      Possible forensics, professional hard drive recovery methods. I know this because I know that rm -rf is not extremely secure, and doesn't overwrite the hard drive.

      – Ray Wu
      yesterday






    • 2





      @SoftTimur rm usually just "unlinks" files but the data is still physically there until overwritten. This is why professionals can "undelete" sometimes if they have physical access and you haven't done lots of things with the disk after the catastrophe occurred. If you don't have backups, that's the best you can hope for.

      – Lightness Races in Orbit
      yesterday











    • You don't need physical access, with almost no disk activity since the deletion file restore utilities might be able to relatively easily find almost everything

      – ThisGuy
      10 hours ago

















    why having physical access to the hard drive may help to restore?

    – SoftTimur
    yesterday





    why having physical access to the hard drive may help to restore?

    – SoftTimur
    yesterday




    1




    1





    Possible forensics, professional hard drive recovery methods. I know this because I know that rm -rf is not extremely secure, and doesn't overwrite the hard drive.

    – Ray Wu
    yesterday





    Possible forensics, professional hard drive recovery methods. I know this because I know that rm -rf is not extremely secure, and doesn't overwrite the hard drive.

    – Ray Wu
    yesterday




    2




    2





    @SoftTimur rm usually just "unlinks" files but the data is still physically there until overwritten. This is why professionals can "undelete" sometimes if they have physical access and you haven't done lots of things with the disk after the catastrophe occurred. If you don't have backups, that's the best you can hope for.

    – Lightness Races in Orbit
    yesterday





    @SoftTimur rm usually just "unlinks" files but the data is still physically there until overwritten. This is why professionals can "undelete" sometimes if they have physical access and you haven't done lots of things with the disk after the catastrophe occurred. If you don't have backups, that's the best you can hope for.

    – Lightness Races in Orbit
    yesterday













    You don't need physical access, with almost no disk activity since the deletion file restore utilities might be able to relatively easily find almost everything

    – ThisGuy
    10 hours ago





    You don't need physical access, with almost no disk activity since the deletion file restore utilities might be able to relatively easily find almost everything

    – ThisGuy
    10 hours ago











    3














    1) Bash comments start with #. Sorry for your loss.
    2) Restore from backup is the only way to proceed here, unfortunately.






    share|improve this answer








    New contributor




    RMPJ is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.

























      3














      1) Bash comments start with #. Sorry for your loss.
      2) Restore from backup is the only way to proceed here, unfortunately.






      share|improve this answer








      New contributor




      RMPJ is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.























        3












        3








        3







        1) Bash comments start with #. Sorry for your loss.
        2) Restore from backup is the only way to proceed here, unfortunately.






        share|improve this answer








        New contributor




        RMPJ is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.










        1) Bash comments start with #. Sorry for your loss.
        2) Restore from backup is the only way to proceed here, unfortunately.







        share|improve this answer








        New contributor




        RMPJ is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.









        share|improve this answer



        share|improve this answer






        New contributor




        RMPJ is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.









        answered yesterday









        RMPJRMPJ

        311




        311




        New contributor




        RMPJ is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.





        New contributor





        RMPJ is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.






        RMPJ is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.















            Popular posts from this blog

            Færeyskur hestur Heimild | Tengill | Tilvísanir | LeiðsagnarvalRossið - síða um færeyska hrossið á færeyskuGott ár hjá færeyska hestinum

            He _____ here since 1970 . Answer needed [closed]What does “since he was so high” mean?Meaning of “catch birds for”?How do I ensure “since” takes the meaning I want?“Who cares here” meaningWhat does “right round toward” mean?the time tense (had now been detected)What does the phrase “ring around the roses” mean here?Correct usage of “visited upon”Meaning of “foiled rail sabotage bid”It was the third time I had gone to Rome or It is the third time I had been to Rome

            Slayer Innehåll Historia | Stil, komposition och lyrik | Bandets betydelse och framgångar | Sidoprojekt och samarbeten | Kontroverser | Medlemmar | Utmärkelser och nomineringar | Turnéer och festivaler | Diskografi | Referenser | Externa länkar | Navigeringsmenywww.slayer.net”Metal Massacre vol. 1””Metal Massacre vol. 3””Metal Massacre Volume III””Show No Mercy””Haunting the Chapel””Live Undead””Hell Awaits””Reign in Blood””Reign in Blood””Gold & Platinum – Reign in Blood””Golden Gods Awards Winners”originalet”Kerrang! Hall Of Fame””Slayer Looks Back On 37-Year Career In New Video Series: Part Two””South of Heaven””Gold & Platinum – South of Heaven””Seasons in the Abyss””Gold & Platinum - Seasons in the Abyss””Divine Intervention””Divine Intervention - Release group by Slayer””Gold & Platinum - Divine Intervention””Live Intrusion””Undisputed Attitude””Abolish Government/Superficial Love””Release “Slatanic Slaughter: A Tribute to Slayer” by Various Artists””Diabolus in Musica””Soundtrack to the Apocalypse””God Hates Us All””Systematic - Relationships””War at the Warfield””Gold & Platinum - War at the Warfield””Soundtrack to the Apocalypse””Gold & Platinum - Still Reigning””Metallica, Slayer, Iron Mauden Among Winners At Metal Hammer Awards””Eternal Pyre””Eternal Pyre - Slayer release group””Eternal Pyre””Metal Storm Awards 2006””Kerrang! Hall Of Fame””Slayer Wins 'Best Metal' Grammy Award””Slayer Guitarist Jeff Hanneman Dies””Bullet-For My Valentine booed at Metal Hammer Golden Gods Awards””Unholy Aliance””The End Of Slayer?””Slayer: We Could Thrash Out Two More Albums If We're Fast Enough...””'The Unholy Alliance: Chapter III' UK Dates Added”originalet”Megadeth And Slayer To Co-Headline 'Canadian Carnage' Trek”originalet”World Painted Blood””Release “World Painted Blood” by Slayer””Metallica Heading To Cinemas””Slayer, Megadeth To Join Forces For 'European Carnage' Tour - Dec. 18, 2010”originalet”Slayer's Hanneman Contracts Acute Infection; Band To Bring In Guest Guitarist””Cannibal Corpse's Pat O'Brien Will Step In As Slayer's Guest Guitarist”originalet”Slayer’s Jeff Hanneman Dead at 49””Dave Lombardo Says He Made Only $67,000 In 2011 While Touring With Slayer””Slayer: We Do Not Agree With Dave Lombardo's Substance Or Timeline Of Events””Slayer Welcomes Drummer Paul Bostaph Back To The Fold””Slayer Hope to Unveil Never-Before-Heard Jeff Hanneman Material on Next Album””Slayer Debut New Song 'Implode' During Surprise Golden Gods Appearance””Release group Repentless by Slayer””Repentless - Slayer - Credits””Slayer””Metal Storm Awards 2015””Slayer - to release comic book "Repentless #1"””Slayer To Release 'Repentless' 6.66" Vinyl Box Set””BREAKING NEWS: Slayer Announce Farewell Tour””Slayer Recruit Lamb of God, Anthrax, Behemoth + Testament for Final Tour””Slayer lägger ner efter 37 år””Slayer Announces Second North American Leg Of 'Final' Tour””Final World Tour””Slayer Announces Final European Tour With Lamb of God, Anthrax And Obituary””Slayer To Tour Europe With Lamb of God, Anthrax And Obituary””Slayer To Play 'Last French Show Ever' At Next Year's Hellfst””Slayer's Final World Tour Will Extend Into 2019””Death Angel's Rob Cavestany On Slayer's 'Farewell' Tour: 'Some Of Us Could See This Coming'””Testament Has No Plans To Retire Anytime Soon, Says Chuck Billy””Anthrax's Scott Ian On Slayer's 'Farewell' Tour Plans: 'I Was Surprised And I Wasn't Surprised'””Slayer””Slayer's Morbid Schlock””Review/Rock; For Slayer, the Mania Is the Message””Slayer - Biography””Slayer - Reign In Blood”originalet”Dave Lombardo””An exclusive oral history of Slayer”originalet”Exclusive! Interview With Slayer Guitarist Jeff Hanneman”originalet”Thinking Out Loud: Slayer's Kerry King on hair metal, Satan and being polite””Slayer Lyrics””Slayer - Biography””Most influential artists for extreme metal music””Slayer - Reign in Blood””Slayer guitarist Jeff Hanneman dies aged 49””Slatanic Slaughter: A Tribute to Slayer””Gateway to Hell: A Tribute to Slayer””Covered In Blood””Slayer: The Origins of Thrash in San Francisco, CA.””Why They Rule - #6 Slayer”originalet”Guitar World's 100 Greatest Heavy Metal Guitarists Of All Time”originalet”The fans have spoken: Slayer comes out on top in readers' polls”originalet”Tribute to Jeff Hanneman (1964-2013)””Lamb Of God Frontman: We Sound Like A Slayer Rip-Off””BEHEMOTH Frontman Pays Tribute To SLAYER's JEFF HANNEMAN””Slayer, Hatebreed Doing Double Duty On This Year's Ozzfest””System of a Down””Lacuna Coil’s Andrea Ferro Talks Influences, Skateboarding, Band Origins + More””Slayer - Reign in Blood””Into The Lungs of Hell””Slayer rules - en utställning om fans””Slayer and Their Fans Slashed Through a No-Holds-Barred Night at Gas Monkey””Home””Slayer””Gold & Platinum - The Big 4 Live from Sofia, Bulgaria””Exclusive! Interview With Slayer Guitarist Kerry King””2008-02-23: Wiltern, Los Angeles, CA, USA””Slayer's Kerry King To Perform With Megadeth Tonight! - Oct. 21, 2010”originalet”Dave Lombardo - Biography”Slayer Case DismissedArkiveradUltimate Classic Rock: Slayer guitarist Jeff Hanneman dead at 49.”Slayer: "We could never do any thing like Some Kind Of Monster..."””Cannibal Corpse'S Pat O'Brien Will Step In As Slayer'S Guest Guitarist | The Official Slayer Site”originalet”Slayer Wins 'Best Metal' Grammy Award””Slayer Guitarist Jeff Hanneman Dies””Kerrang! Awards 2006 Blog: Kerrang! Hall Of Fame””Kerrang! Awards 2013: Kerrang! Legend”originalet”Metallica, Slayer, Iron Maien Among Winners At Metal Hammer Awards””Metal Hammer Golden Gods Awards””Bullet For My Valentine Booed At Metal Hammer Golden Gods Awards””Metal Storm Awards 2006””Metal Storm Awards 2015””Slayer's Concert History””Slayer - Relationships””Slayer - Releases”Slayers officiella webbplatsSlayer på MusicBrainzOfficiell webbplatsSlayerSlayerr1373445760000 0001 1540 47353068615-5086262726cb13906545x(data)6033143kn20030215029