extundelete-users Mailing List for extundelete (Page 4)
Status: Beta
Brought to you by:
necase
Menu
▾
▴
extundelete-users — Discussion about using and improving extundelete
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(3) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
|
Feb
|
Mar
(2) |
Apr
(3) |
May
(2) |
Jun
(13) |
Jul
(6) |
Aug
(9) |
Sep
(2) |
Oct
(10) |
Nov
|
Dec
|
| 2011 |
Jan
(2) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(2) |
Jun
(5) |
Jul
(4) |
Aug
(1) |
Sep
(3) |
Oct
(3) |
Nov
|
Dec
(2) |
| 2012 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
(11) |
Jun
(1) |
Jul
|
Aug
(8) |
Sep
(15) |
Oct
(4) |
Nov
(17) |
Dec
(10) |
| 2013 |
Jan
(4) |
Feb
(5) |
Mar
(2) |
Apr
(5) |
May
|
Jun
(7) |
Jul
(1) |
Aug
(1) |
Sep
(3) |
Oct
(3) |
Nov
(3) |
Dec
(3) |
| 2014 |
Jan
(19) |
Feb
(1) |
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
(1) |
Aug
(3) |
Sep
(2) |
Oct
(2) |
Nov
(2) |
Dec
|
| 2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
|
Jul
|
Aug
(3) |
Sep
(3) |
Oct
|
Nov
|
Dec
(1) |
| 2016 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2017 |
Jan
|
Feb
|
Mar
(3) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
(2) |
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ext...@li...> - 2014-01-10 17:16:56
|
Hi,
> On Friday, January 10, 2014 10:47 AM, "ext...@li..." <ext...@li...> wrote:
> > Hello all,
>
> I accidentally deleted a still used snapshot file of a VirtualBox hard disk
> image on an ext3 partition of an ubuntu 12.04/precise box. I immediately noticed
> my mistake and remounted the filesystem read-only after around 20 seconds after
> the deletion.
>
> This was the file BEFORE the deletion:
> # ls -l
> total 1071324
> -rw------- 1 root root 1095950336 Jan 3 23:32
> {59a29cb2-0871-4da7-b650-4d870deb3bf2}.vdi
>
> It is around 10GB in size.
>
> The version of extundelete included with ubuntu 12.04:
> # extundelete --version
> extundelete version 0.2.0
> libext2fs version 1.42
> Processor is little endian.
>
> Because I saw Nic’s e-mail from 2012-12-04 01:35 to this mailing list, which
> describes the ability to recover large files (>4GB) with extundelete versions
> greater than 0.2.2, I downloaded the most recent version and I compiled it:
> # /root/extundelete-0.2.4/src/extundelete --version
> extundelete version 0.2.4
> libext2fs version 1.42
> Processor is little endian.
>
> I tried to recover my file:
> # /root/extundelete-0.2.4/src/extundelete --restore-file
> "Snapshots/{59a29cb2-0871-4da7-b650-4d870deb3bf2}.vdi" /dev/vde
> NOTICE: Extended attributes are not restored.
> Loading filesystem metadata ... 1120 groups loaded.
> Loading journal descriptors ... 32455 descriptors loaded.
> Successfully restored file
> Snapshots/{59a29cb2-0871-4da7-b650-4d870deb3bf2}.vdi
>
> The recovered file looks like this:
> # ls -l
> total 4176060
> -rw-r--r-- 1 root root 4276281344 Jan 4 00:48
> {59a29cb2-0871-4da7-b650-4d870deb3bf2}.vdi
>
> Basically extundelete works fine and the file could be restorable. Can I do
> anything to get all the bytes of the file back or supply more information
> regarding the issue?
>
From the numbers you pasted here, doesn't it show the original file is about 1 GB and the restored is 4 GB? extundelete could be finding the wrong file, or the difference could be due to the original sparse file possibly being converted to a non-sparse file. Did you try to run the virtualbox file and see if it was recognized?
Nic
> Thank you very much!
>
> Goodbye
> juergen
|
|
From: <ext...@li...> - 2014-01-10 16:45:54
|
Hi, > I got the backtrace, I attached it and a link to the core file. I hope > you find useful information there, in case you need something else,let > me know. > Thanks > Core was generated by `./extundelete --restore-directory jisern > /dev/mapper/vgdata-lvdata -o /mnt/extu'. > Program terminated with signal 6, Aborted. > #0 0x00007fd29ae7a425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 > (gdb) bt > #0 0x00007fd29ae7a425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 > #1 0x00007fd29ae7db8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 > #2 0x00007fd29aeb839e in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > #3 0x00007fd29aec2b96 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > #4 0x000000000040ec2a in init_journal (fs=<optimised out>, > jfs=0xf69100, jsb=<optimised out>) > at extundelete.cc:1167 > #5 0x0000000000412094 in examine_fs (fs=0xf69100) at cli.cc:287 > #6 0x000000000040612d in main (argc=1, argv=0x7fff85ff3f40) at cli.cc:806 > (gdb) > Thanks, that trace tells me exactly where the program crashed (line 1167 in extundelete.cc). Unfortunately, I'm not really sure how that could happen. What does the output of extundelete --superblock /dev/mapper/vgdata-lvdata look like? Does it match dumpe2fs -h /dev/mapper/vgdata-lvdata ? You might also try to run extundelete from a live CD if you are not already, as this particular error could be related to how extundelete was compiled. This one currently has me a little confused. Nic |
|
From: <ext...@li...> - 2014-01-09 08:47:11
|
Hi, I got the backtrace, I attached it and a link to the core file. I hope you find useful information there, in case you need something else,let me know. Thanks And here is the generated core file: https://dl.dropboxusercontent.com/u/4129164/core.gz root@main:/tmp/extundelete-0.2.4/src# gdb ./extundelete core GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://bugs.launchpad.net/gdb-linaro/>... Reading symbols from /tmp/extundelete-0.2.4/src/extundelete...done. [New LWP 22684] warning: Can't read pathname for load map: Input/output error. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `./extundelete --restore-directory jisern /dev/mapper/vgdata-lvdata -o /mnt/extu'. Program terminated with signal 6, Aborted. #0 0x00007fd29ae7a425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x00007fd29ae7a425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007fd29ae7db8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007fd29aeb839e in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x00007fd29aec2b96 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x000000000040ec2a in init_journal (fs=<optimised out>, jfs=0xf69100, jsb=<optimised out>) at extundelete.cc:1167 #5 0x0000000000412094 in examine_fs (fs=0xf69100) at cli.cc:287 #6 0x000000000040612d in main (argc=1, argv=0x7fff85ff3f40) at cli.cc:806 (gdb) On 12/29/2013 02:54 PM, ext...@li... wrote: > Hi, > Thank you for trying to find the fix for this bug, but unfortunately I > have no idea about how to get the backtrace from gdb, I've never used it > before, so it would be very helpful if you can guide me on how to get it. > > Thank you. > > >>>> Hi all, >>> That's my first time here, I am writing this email regarding an error I >>> get after compiling extundelete app and trying to run it. I am going to >>> attach the error: >>> >>> Is it a bug or am I doing something wrong? >>> >> You ran into a bug in extundelete. I don't immediately know where the >> problem is from that trace, but will try to find it. Meanwhile, if you >> are able to try to diagnose the problem further, by perhaps getting the >> backtrace from gdb, that may be helpful in fixing it. >> >> Nic >> >> >>> root@boole:/tmp/extundelete-0.2.4/src# ./extundelete --restore-directory >>> useradmin /dev/mapper/vgdata-lvdata -o /mnt/ >>> NOTICE: Extended attributes are not restored. >>> Loading filesystem metadata ... 353742 groups loaded. >>> Loading journal descriptors ... 4752 descriptors loaded. >>> *** glibc detected *** ./extundelete: double free or corruption (!prev): >>> 0x000000000242dfd0 *** >>> ======= Backtrace: ========= >>> /lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7fd3b1c24b96] >>> ./extundelete[0x40ec2a] >>> ./extundelete[0x412094] >>> ./extundelete[0x40612d] >>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7fd3b1bc776d] >>> ./extundelete[0x4065c1] >>> ======= Memory map: ======== >>> 00400000-00420000 r-xp 00000000 09:00 19529804 >>> /tmp/extundelete-0.2.4/src/extundelete >>> 0061f000-00620000 r--p 0001f000 09:00 19529804 >>> /tmp/extundelete-0.2.4/src/extundelete >>> 00620000-00621000 rw-p 00020000 09:00 19529804 >>> /tmp/extundelete-0.2.4/src/extundelete >>> 00621000-00622000 rw-p 00000000 00:00 0 >>> 02425000-024be000 rw-p 00000000 00:00 0 >>> [heap] >>> 7fd3544c8000-7fd3b168d000 rw-p 00000000 00:00 0 >>> 7fd3b168d000-7fd3b1788000 r-xp 00000000 09:00 18743751 >>> /lib/x86_64-linux-gnu/libm-2.15.so >>> 7fd3b1788000-7fd3b1987000 ---p 000fb000 09:00 18743751 >>> /lib/x86_64-linux-gnu/libm-2.15.so >>> 7fd3b1987000-7fd3b1988000 r--p 000fa000 09:00 18743751 >>> /lib/x86_64-linux-gnu/libm-2.15.so >>> 7fd3b1988000-7fd3b1989000 rw-p 000fb000 09:00 18743751 >>> /lib/x86_64-linux-gnu/libm-2.15.so >>> 7fd3b1989000-7fd3b19a1000 r-xp 00000000 09:00 18743749 >>> /lib/x86_64-linux-gnu/libpthread-2.15.so >>> 7fd3b19a1000-7fd3b1ba0000 ---p 00018000 09:00 18743749 >>> /lib/x86_64-linux-gnu/libpthread-2.15.so >>> 7fd3b1ba0000-7fd3b1ba1000 r--p 00017000 09:00 18743749 >>> /lib/x86_64-linux-gnu/libpthread-2.15.so >>> 7fd3b1ba1000-7fd3b1ba2000 rw-p 00018000 09:00 18743749 >>> /lib/x86_64-linux-gnu/libpthread-2.15.so >>> 7fd3b1ba2000-7fd3b1ba6000 rw-p 00000000 00:00 0 >>> 7fd3b1ba6000-7fd3b1d5b000 r-xp 00000000 09:00 18743328 >>> /lib/x86_64-linux-gnu/libc-2.15.so >>> 7fd3b1d5b000-7fd3b1f5b000 ---p 001b5000 09:00 18743328 >>> /lib/x86_64-linux-gnu/libc-2.15.so >>> 7fd3b1f5b000-7fd3b1f5f000 r--p 001b5000 09:00 18743328 >>> /lib/x86_64-linux-gnu/libc-2.15.so >>> 7fd3b1f5f000-7fd3b1f61000 rw-p 001b9000 09:00 18743328 >>> /lib/x86_64-linux-gnu/libc-2.15.so >>> 7fd3b1f61000-7fd3b1f66000 rw-p 00000000 00:00 0 >>> 7fd3b1f66000-7fd3b1f7b000 r-xp 00000000 09:00 18743340 >>> /lib/x86_64-linux-gnu/libgcc_s.so.1 >>> 7fd3b1f7b000-7fd3b217a000 ---p 00015000 09:00 18743340 >>> /lib/x86_64-linux-gnu/libgcc_s.so.1 >>> 7fd3b217a000-7fd3b217b000 r--p 00014000 09:00 18743340 >>> /lib/x86_64-linux-gnu/libgcc_s.so.1 >>> 7fd3b217b000-7fd3b217c000 rw-p 00015000 09:00 18743340 >>> /lib/x86_64-linux-gnu/libgcc_s.so.1 >>> 7fd3b217c000-7fd3b225e000 r-xp 00000000 09:00 529254 >>> /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 >>> 7fd3b225e000-7fd3b245d000 ---p 000e2000 09:00 529254 >>> /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 >>> 7fd3b245d000-7fd3b2465000 r--p 000e1000 09:00 529254 >>> /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 >>> 7fd3b2465000-7fd3b2467000 rw-p 000e9000 09:00 529254 >>> /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 >>> 7fd3b2467000-7fd3b247c000 rw-p 00000000 00:00 0 >>> 7fd3b247c000-7fd3b24b6000 r-xp 00000000 09:00 18743306 >>> /lib/x86_64-linux-gnu/libext2fs.so.2.4 >>> 7fd3b24b6000-7fd3b26b6000 ---p 0003a000 09:00 18743306 >>> /lib/x86_64-linux-gnu/libext2fs.so.2.4 >>> 7fd3b26b6000-7fd3b26b7000 r--p 0003a000 09:00 18743306 >>> /lib/x86_64-linux-gnu/libext2fs.so.2.4 >>> 7fd3b26b7000-7fd3b26b8000 rw-p 0003b000 09:00 18743306 >>> /lib/x86_64-linux-gnu/libext2fs.so.2.4 >>> 7fd3b26b8000-7fd3b26bb000 r-xp 00000000 09:00 18743308 >>> /lib/x86_64-linux-gnu/libcom_err.so.2.1 >>> 7fd3b26bb000-7fd3b28ba000 ---p 00003000 09:00 18743308 >>> /lib/x86_64-linux-gnu/libcom_err.so.2.1 >>> 7fd3b28ba000-7fd3b28bb000 r--p 00002000 09:00 18743308 >>> /lib/x86_64-linux-gnu/libcom_err.so.2.1 >>> 7fd3b28bb000-7fd3b28bc000 rw-p 00003000 09:00 18743308 >>> /lib/x86_64-linux-gnu/libcom_err.so.2.1 >>> 7fd3b28bc000-7fd3b28de000 r-xp 00000000 09:00 18743752 >>> /lib/x86_64-linux-gnu/ld-2.15.so >>> 7fd3b2a59000-7fd3b2ad1000 rw-p 00000000 00:00 0 >>> 7fd3b2ada000-7fd3b2ade000 rw-p 00000000 00:00 0 >>> 7fd3b2ade000-7fd3b2adf000 r--p 00022000 09:00 18743752 >>> /lib/x86_64-linux-gnu/ld-2.15.so >>> 7fd3b2adf000-7fd3b2ae1000 rw-p 00023000 09:00 18743752 >>> /lib/x86_64-linux-gnu/ld-2.15.so >>> 7fff97bca000-7fff97beb000 rw-p 00000000 00:00 0 >>> [stack] >>> 7fff97bf6000-7fff97bf7000 r-xp 00000000 00:00 0 >>> [vdso] >>> ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 >>> [vsyscall] >>> Aborted (core dumped) >>> >>> -- >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics >> Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >> _______________________________________________ >> Extundelete-users mailing list >> Ext...@li... >> https://lists.sourceforge.net/lists/listinfo/extundelete-users >> >> > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Extundelete-users mailing list > Ext...@li... > https://lists.sourceforge.net/lists/listinfo/extundelete-users > -- --------------------------- Josep Manel Andrés Moscardó IT Technician at IC3 --------------------------- |
|
From: <ext...@li...> - 2014-01-04 00:21:28
|
Hello all,
I accidentally deleted a still used snapshot file of a VirtualBox hard disk image on an ext3 partition of an ubuntu 12.04/precise box. I immediately noticed my mistake and remounted the filesystem read-only after around 20 seconds after the deletion.
This was the file BEFORE the deletion:
# ls -l
total 1071324
-rw------- 1 root root 1095950336 Jan 3 23:32 {59a29cb2-0871-4da7-b650-4d870deb3bf2}.vdi
It is around 10GB in size.
The version of extundelete included with ubuntu 12.04:
# extundelete --version
extundelete version 0.2.0
libext2fs version 1.42
Processor is little endian.
Because I saw Nic’s e-mail from 2012-12-04 01:35 to this mailing list, which describes the ability to recover large files (>4GB) with extundelete versions greater than 0.2.2, I downloaded the most recent version and I compiled it:
# /root/extundelete-0.2.4/src/extundelete --version
extundelete version 0.2.4
libext2fs version 1.42
Processor is little endian.
I tried to recover my file:
# /root/extundelete-0.2.4/src/extundelete --restore-file "Snapshots/{59a29cb2-0871-4da7-b650-4d870deb3bf2}.vdi" /dev/vde
NOTICE: Extended attributes are not restored.
Loading filesystem metadata ... 1120 groups loaded.
Loading journal descriptors ... 32455 descriptors loaded.
Successfully restored file Snapshots/{59a29cb2-0871-4da7-b650-4d870deb3bf2}.vdi
The recovered file looks like this:
# ls -l
total 4176060
-rw-r--r-- 1 root root 4276281344 Jan 4 00:48 {59a29cb2-0871-4da7-b650-4d870deb3bf2}.vdi
Basically extundelete works fine and the file could be restorable. Can I do anything to get all the bytes of the file back or supply more information regarding the issue?
Thank you very much!
Goodbye
juergen
|
|
From: <ext...@li...> - 2013-12-29 13:54:10
|
Hi, Thank you for trying to find the fix for this bug, but unfortunately I have no idea about how to get the backtrace from gdb, I've never used it before, so it would be very helpful if you can guide me on how to get it. Thank you. >> > Hi all, > >> That's my first time here, I am writing this email regarding an error I >> get after compiling extundelete app and trying to run it. I am going to >> attach the error: >> >> Is it a bug or am I doing something wrong? >> > > You ran into a bug in extundelete. I don't immediately know where the > problem is from that trace, but will try to find it. Meanwhile, if you > are able to try to diagnose the problem further, by perhaps getting the > backtrace from gdb, that may be helpful in fixing it. > > Nic > > >> root@boole:/tmp/extundelete-0.2.4/src# ./extundelete --restore-directory >> useradmin /dev/mapper/vgdata-lvdata -o /mnt/ >> NOTICE: Extended attributes are not restored. >> Loading filesystem metadata ... 353742 groups loaded. >> Loading journal descriptors ... 4752 descriptors loaded. >> *** glibc detected *** ./extundelete: double free or corruption (!prev): >> 0x000000000242dfd0 *** >> ======= Backtrace: ========= >> /lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7fd3b1c24b96] >> ./extundelete[0x40ec2a] >> ./extundelete[0x412094] >> ./extundelete[0x40612d] >> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7fd3b1bc776d] >> ./extundelete[0x4065c1] >> ======= Memory map: ======== >> 00400000-00420000 r-xp 00000000 09:00 19529804 >> /tmp/extundelete-0.2.4/src/extundelete >> 0061f000-00620000 r--p 0001f000 09:00 19529804 >> /tmp/extundelete-0.2.4/src/extundelete >> 00620000-00621000 rw-p 00020000 09:00 19529804 >> /tmp/extundelete-0.2.4/src/extundelete >> 00621000-00622000 rw-p 00000000 00:00 0 >> 02425000-024be000 rw-p 00000000 00:00 0 >> [heap] >> 7fd3544c8000-7fd3b168d000 rw-p 00000000 00:00 0 >> 7fd3b168d000-7fd3b1788000 r-xp 00000000 09:00 18743751 >> /lib/x86_64-linux-gnu/libm-2.15.so >> 7fd3b1788000-7fd3b1987000 ---p 000fb000 09:00 18743751 >> /lib/x86_64-linux-gnu/libm-2.15.so >> 7fd3b1987000-7fd3b1988000 r--p 000fa000 09:00 18743751 >> /lib/x86_64-linux-gnu/libm-2.15.so >> 7fd3b1988000-7fd3b1989000 rw-p 000fb000 09:00 18743751 >> /lib/x86_64-linux-gnu/libm-2.15.so >> 7fd3b1989000-7fd3b19a1000 r-xp 00000000 09:00 18743749 >> /lib/x86_64-linux-gnu/libpthread-2.15.so >> 7fd3b19a1000-7fd3b1ba0000 ---p 00018000 09:00 18743749 >> /lib/x86_64-linux-gnu/libpthread-2.15.so >> 7fd3b1ba0000-7fd3b1ba1000 r--p 00017000 09:00 18743749 >> /lib/x86_64-linux-gnu/libpthread-2.15.so >> 7fd3b1ba1000-7fd3b1ba2000 rw-p 00018000 09:00 18743749 >> /lib/x86_64-linux-gnu/libpthread-2.15.so >> 7fd3b1ba2000-7fd3b1ba6000 rw-p 00000000 00:00 0 >> 7fd3b1ba6000-7fd3b1d5b000 r-xp 00000000 09:00 18743328 >> /lib/x86_64-linux-gnu/libc-2.15.so >> 7fd3b1d5b000-7fd3b1f5b000 ---p 001b5000 09:00 18743328 >> /lib/x86_64-linux-gnu/libc-2.15.so >> 7fd3b1f5b000-7fd3b1f5f000 r--p 001b5000 09:00 18743328 >> /lib/x86_64-linux-gnu/libc-2.15.so >> 7fd3b1f5f000-7fd3b1f61000 rw-p 001b9000 09:00 18743328 >> /lib/x86_64-linux-gnu/libc-2.15.so >> 7fd3b1f61000-7fd3b1f66000 rw-p 00000000 00:00 0 >> 7fd3b1f66000-7fd3b1f7b000 r-xp 00000000 09:00 18743340 >> /lib/x86_64-linux-gnu/libgcc_s.so.1 >> 7fd3b1f7b000-7fd3b217a000 ---p 00015000 09:00 18743340 >> /lib/x86_64-linux-gnu/libgcc_s.so.1 >> 7fd3b217a000-7fd3b217b000 r--p 00014000 09:00 18743340 >> /lib/x86_64-linux-gnu/libgcc_s.so.1 >> 7fd3b217b000-7fd3b217c000 rw-p 00015000 09:00 18743340 >> /lib/x86_64-linux-gnu/libgcc_s.so.1 >> 7fd3b217c000-7fd3b225e000 r-xp 00000000 09:00 529254 >> /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 >> 7fd3b225e000-7fd3b245d000 ---p 000e2000 09:00 529254 >> /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 >> 7fd3b245d000-7fd3b2465000 r--p 000e1000 09:00 529254 >> /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 >> 7fd3b2465000-7fd3b2467000 rw-p 000e9000 09:00 529254 >> /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 >> 7fd3b2467000-7fd3b247c000 rw-p 00000000 00:00 0 >> 7fd3b247c000-7fd3b24b6000 r-xp 00000000 09:00 18743306 >> /lib/x86_64-linux-gnu/libext2fs.so.2.4 >> 7fd3b24b6000-7fd3b26b6000 ---p 0003a000 09:00 18743306 >> /lib/x86_64-linux-gnu/libext2fs.so.2.4 >> 7fd3b26b6000-7fd3b26b7000 r--p 0003a000 09:00 18743306 >> /lib/x86_64-linux-gnu/libext2fs.so.2.4 >> 7fd3b26b7000-7fd3b26b8000 rw-p 0003b000 09:00 18743306 >> /lib/x86_64-linux-gnu/libext2fs.so.2.4 >> 7fd3b26b8000-7fd3b26bb000 r-xp 00000000 09:00 18743308 >> /lib/x86_64-linux-gnu/libcom_err.so.2.1 >> 7fd3b26bb000-7fd3b28ba000 ---p 00003000 09:00 18743308 >> /lib/x86_64-linux-gnu/libcom_err.so.2.1 >> 7fd3b28ba000-7fd3b28bb000 r--p 00002000 09:00 18743308 >> /lib/x86_64-linux-gnu/libcom_err.so.2.1 >> 7fd3b28bb000-7fd3b28bc000 rw-p 00003000 09:00 18743308 >> /lib/x86_64-linux-gnu/libcom_err.so.2.1 >> 7fd3b28bc000-7fd3b28de000 r-xp 00000000 09:00 18743752 >> /lib/x86_64-linux-gnu/ld-2.15.so >> 7fd3b2a59000-7fd3b2ad1000 rw-p 00000000 00:00 0 >> 7fd3b2ada000-7fd3b2ade000 rw-p 00000000 00:00 0 >> 7fd3b2ade000-7fd3b2adf000 r--p 00022000 09:00 18743752 >> /lib/x86_64-linux-gnu/ld-2.15.so >> 7fd3b2adf000-7fd3b2ae1000 rw-p 00023000 09:00 18743752 >> /lib/x86_64-linux-gnu/ld-2.15.so >> 7fff97bca000-7fff97beb000 rw-p 00000000 00:00 0 >> [stack] >> 7fff97bf6000-7fff97bf7000 r-xp 00000000 00:00 0 >> [vdso] >> ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 >> [vsyscall] >> Aborted (core dumped) >> >> -- > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Extundelete-users mailing list > Ext...@li... > https://lists.sourceforge.net/lists/listinfo/extundelete-users > > |
|
From: <ext...@li...> - 2013-12-23 15:44:04
|
> > Hi all, > That's my first time here, I am writing this email regarding an error I > get after compiling extundelete app and trying to run it. I am going to > attach the error: > > Is it a bug or am I doing something wrong? > You ran into a bug in extundelete. I don't immediately know where the problem is from that trace, but will try to find it. Meanwhile, if you are able to try to diagnose the problem further, by perhaps getting the backtrace from gdb, that may be helpful in fixing it. Nic > root@boole:/tmp/extundelete-0.2.4/src# ./extundelete --restore-directory > useradmin /dev/mapper/vgdata-lvdata -o /mnt/ > NOTICE: Extended attributes are not restored. > Loading filesystem metadata ... 353742 groups loaded. > Loading journal descriptors ... 4752 descriptors loaded. > *** glibc detected *** ./extundelete: double free or corruption (!prev): > 0x000000000242dfd0 *** > ======= Backtrace: ========= > /lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7fd3b1c24b96] > ./extundelete[0x40ec2a] > ./extundelete[0x412094] > ./extundelete[0x40612d] > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7fd3b1bc776d] > ./extundelete[0x4065c1] > ======= Memory map: ======== > 00400000-00420000 r-xp 00000000 09:00 19529804 > /tmp/extundelete-0.2.4/src/extundelete > 0061f000-00620000 r--p 0001f000 09:00 19529804 > /tmp/extundelete-0.2.4/src/extundelete > 00620000-00621000 rw-p 00020000 09:00 19529804 > /tmp/extundelete-0.2.4/src/extundelete > 00621000-00622000 rw-p 00000000 00:00 0 > 02425000-024be000 rw-p 00000000 00:00 0 > [heap] > 7fd3544c8000-7fd3b168d000 rw-p 00000000 00:00 0 > 7fd3b168d000-7fd3b1788000 r-xp 00000000 09:00 18743751 > /lib/x86_64-linux-gnu/libm-2.15.so > 7fd3b1788000-7fd3b1987000 ---p 000fb000 09:00 18743751 > /lib/x86_64-linux-gnu/libm-2.15.so > 7fd3b1987000-7fd3b1988000 r--p 000fa000 09:00 18743751 > /lib/x86_64-linux-gnu/libm-2.15.so > 7fd3b1988000-7fd3b1989000 rw-p 000fb000 09:00 18743751 > /lib/x86_64-linux-gnu/libm-2.15.so > 7fd3b1989000-7fd3b19a1000 r-xp 00000000 09:00 18743749 > /lib/x86_64-linux-gnu/libpthread-2.15.so > 7fd3b19a1000-7fd3b1ba0000 ---p 00018000 09:00 18743749 > /lib/x86_64-linux-gnu/libpthread-2.15.so > 7fd3b1ba0000-7fd3b1ba1000 r--p 00017000 09:00 18743749 > /lib/x86_64-linux-gnu/libpthread-2.15.so > 7fd3b1ba1000-7fd3b1ba2000 rw-p 00018000 09:00 18743749 > /lib/x86_64-linux-gnu/libpthread-2.15.so > 7fd3b1ba2000-7fd3b1ba6000 rw-p 00000000 00:00 0 > 7fd3b1ba6000-7fd3b1d5b000 r-xp 00000000 09:00 18743328 > /lib/x86_64-linux-gnu/libc-2.15.so > 7fd3b1d5b000-7fd3b1f5b000 ---p 001b5000 09:00 18743328 > /lib/x86_64-linux-gnu/libc-2.15.so > 7fd3b1f5b000-7fd3b1f5f000 r--p 001b5000 09:00 18743328 > /lib/x86_64-linux-gnu/libc-2.15.so > 7fd3b1f5f000-7fd3b1f61000 rw-p 001b9000 09:00 18743328 > /lib/x86_64-linux-gnu/libc-2.15.so > 7fd3b1f61000-7fd3b1f66000 rw-p 00000000 00:00 0 > 7fd3b1f66000-7fd3b1f7b000 r-xp 00000000 09:00 18743340 > /lib/x86_64-linux-gnu/libgcc_s.so.1 > 7fd3b1f7b000-7fd3b217a000 ---p 00015000 09:00 18743340 > /lib/x86_64-linux-gnu/libgcc_s.so.1 > 7fd3b217a000-7fd3b217b000 r--p 00014000 09:00 18743340 > /lib/x86_64-linux-gnu/libgcc_s.so.1 > 7fd3b217b000-7fd3b217c000 rw-p 00015000 09:00 18743340 > /lib/x86_64-linux-gnu/libgcc_s.so.1 > 7fd3b217c000-7fd3b225e000 r-xp 00000000 09:00 529254 > /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 > 7fd3b225e000-7fd3b245d000 ---p 000e2000 09:00 529254 > /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 > 7fd3b245d000-7fd3b2465000 r--p 000e1000 09:00 529254 > /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 > 7fd3b2465000-7fd3b2467000 rw-p 000e9000 09:00 529254 > /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 > 7fd3b2467000-7fd3b247c000 rw-p 00000000 00:00 0 > 7fd3b247c000-7fd3b24b6000 r-xp 00000000 09:00 18743306 > /lib/x86_64-linux-gnu/libext2fs.so.2.4 > 7fd3b24b6000-7fd3b26b6000 ---p 0003a000 09:00 18743306 > /lib/x86_64-linux-gnu/libext2fs.so.2.4 > 7fd3b26b6000-7fd3b26b7000 r--p 0003a000 09:00 18743306 > /lib/x86_64-linux-gnu/libext2fs.so.2.4 > 7fd3b26b7000-7fd3b26b8000 rw-p 0003b000 09:00 18743306 > /lib/x86_64-linux-gnu/libext2fs.so.2.4 > 7fd3b26b8000-7fd3b26bb000 r-xp 00000000 09:00 18743308 > /lib/x86_64-linux-gnu/libcom_err.so.2.1 > 7fd3b26bb000-7fd3b28ba000 ---p 00003000 09:00 18743308 > /lib/x86_64-linux-gnu/libcom_err.so.2.1 > 7fd3b28ba000-7fd3b28bb000 r--p 00002000 09:00 18743308 > /lib/x86_64-linux-gnu/libcom_err.so.2.1 > 7fd3b28bb000-7fd3b28bc000 rw-p 00003000 09:00 18743308 > /lib/x86_64-linux-gnu/libcom_err.so.2.1 > 7fd3b28bc000-7fd3b28de000 r-xp 00000000 09:00 18743752 > /lib/x86_64-linux-gnu/ld-2.15.so > 7fd3b2a59000-7fd3b2ad1000 rw-p 00000000 00:00 0 > 7fd3b2ada000-7fd3b2ade000 rw-p 00000000 00:00 0 > 7fd3b2ade000-7fd3b2adf000 r--p 00022000 09:00 18743752 > /lib/x86_64-linux-gnu/ld-2.15.so > 7fd3b2adf000-7fd3b2ae1000 rw-p 00023000 09:00 18743752 > /lib/x86_64-linux-gnu/ld-2.15.so > 7fff97bca000-7fff97beb000 rw-p 00000000 00:00 0 > [stack] > 7fff97bf6000-7fff97bf7000 r-xp 00000000 00:00 0 > [vdso] > ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 > [vsyscall] > Aborted (core dumped) > > -- |
|
From: <ext...@li...> - 2013-12-18 18:22:01
|
Hi all, That's my first time here, I am writing this email regarding an error I get after compiling extundelete app and trying to run it. I am going to attach the error: Is it a bug or am I doing something wrong? Thank you, I appreciate your help, I have lost all the data of the company. They didn't have any backup..... root@boole:/tmp/extundelete-0.2.4/src# ./extundelete --restore-directory useradmin /dev/mapper/vgdata-lvdata -o /mnt/ NOTICE: Extended attributes are not restored. Loading filesystem metadata ... 353742 groups loaded. Loading journal descriptors ... 4752 descriptors loaded. *** glibc detected *** ./extundelete: double free or corruption (!prev): 0x000000000242dfd0 *** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7fd3b1c24b96] ./extundelete[0x40ec2a] ./extundelete[0x412094] ./extundelete[0x40612d] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7fd3b1bc776d] ./extundelete[0x4065c1] ======= Memory map: ======== 00400000-00420000 r-xp 00000000 09:00 19529804 /tmp/extundelete-0.2.4/src/extundelete 0061f000-00620000 r--p 0001f000 09:00 19529804 /tmp/extundelete-0.2.4/src/extundelete 00620000-00621000 rw-p 00020000 09:00 19529804 /tmp/extundelete-0.2.4/src/extundelete 00621000-00622000 rw-p 00000000 00:00 0 02425000-024be000 rw-p 00000000 00:00 0 [heap] 7fd3544c8000-7fd3b168d000 rw-p 00000000 00:00 0 7fd3b168d000-7fd3b1788000 r-xp 00000000 09:00 18743751 /lib/x86_64-linux-gnu/libm-2.15.so 7fd3b1788000-7fd3b1987000 ---p 000fb000 09:00 18743751 /lib/x86_64-linux-gnu/libm-2.15.so 7fd3b1987000-7fd3b1988000 r--p 000fa000 09:00 18743751 /lib/x86_64-linux-gnu/libm-2.15.so 7fd3b1988000-7fd3b1989000 rw-p 000fb000 09:00 18743751 /lib/x86_64-linux-gnu/libm-2.15.so 7fd3b1989000-7fd3b19a1000 r-xp 00000000 09:00 18743749 /lib/x86_64-linux-gnu/libpthread-2.15.so 7fd3b19a1000-7fd3b1ba0000 ---p 00018000 09:00 18743749 /lib/x86_64-linux-gnu/libpthread-2.15.so 7fd3b1ba0000-7fd3b1ba1000 r--p 00017000 09:00 18743749 /lib/x86_64-linux-gnu/libpthread-2.15.so 7fd3b1ba1000-7fd3b1ba2000 rw-p 00018000 09:00 18743749 /lib/x86_64-linux-gnu/libpthread-2.15.so 7fd3b1ba2000-7fd3b1ba6000 rw-p 00000000 00:00 0 7fd3b1ba6000-7fd3b1d5b000 r-xp 00000000 09:00 18743328 /lib/x86_64-linux-gnu/libc-2.15.so 7fd3b1d5b000-7fd3b1f5b000 ---p 001b5000 09:00 18743328 /lib/x86_64-linux-gnu/libc-2.15.so 7fd3b1f5b000-7fd3b1f5f000 r--p 001b5000 09:00 18743328 /lib/x86_64-linux-gnu/libc-2.15.so 7fd3b1f5f000-7fd3b1f61000 rw-p 001b9000 09:00 18743328 /lib/x86_64-linux-gnu/libc-2.15.so 7fd3b1f61000-7fd3b1f66000 rw-p 00000000 00:00 0 7fd3b1f66000-7fd3b1f7b000 r-xp 00000000 09:00 18743340 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fd3b1f7b000-7fd3b217a000 ---p 00015000 09:00 18743340 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fd3b217a000-7fd3b217b000 r--p 00014000 09:00 18743340 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fd3b217b000-7fd3b217c000 rw-p 00015000 09:00 18743340 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fd3b217c000-7fd3b225e000 r-xp 00000000 09:00 529254 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 7fd3b225e000-7fd3b245d000 ---p 000e2000 09:00 529254 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 7fd3b245d000-7fd3b2465000 r--p 000e1000 09:00 529254 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 7fd3b2465000-7fd3b2467000 rw-p 000e9000 09:00 529254 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 7fd3b2467000-7fd3b247c000 rw-p 00000000 00:00 0 7fd3b247c000-7fd3b24b6000 r-xp 00000000 09:00 18743306 /lib/x86_64-linux-gnu/libext2fs.so.2.4 7fd3b24b6000-7fd3b26b6000 ---p 0003a000 09:00 18743306 /lib/x86_64-linux-gnu/libext2fs.so.2.4 7fd3b26b6000-7fd3b26b7000 r--p 0003a000 09:00 18743306 /lib/x86_64-linux-gnu/libext2fs.so.2.4 7fd3b26b7000-7fd3b26b8000 rw-p 0003b000 09:00 18743306 /lib/x86_64-linux-gnu/libext2fs.so.2.4 7fd3b26b8000-7fd3b26bb000 r-xp 00000000 09:00 18743308 /lib/x86_64-linux-gnu/libcom_err.so.2.1 7fd3b26bb000-7fd3b28ba000 ---p 00003000 09:00 18743308 /lib/x86_64-linux-gnu/libcom_err.so.2.1 7fd3b28ba000-7fd3b28bb000 r--p 00002000 09:00 18743308 /lib/x86_64-linux-gnu/libcom_err.so.2.1 7fd3b28bb000-7fd3b28bc000 rw-p 00003000 09:00 18743308 /lib/x86_64-linux-gnu/libcom_err.so.2.1 7fd3b28bc000-7fd3b28de000 r-xp 00000000 09:00 18743752 /lib/x86_64-linux-gnu/ld-2.15.so 7fd3b2a59000-7fd3b2ad1000 rw-p 00000000 00:00 0 7fd3b2ada000-7fd3b2ade000 rw-p 00000000 00:00 0 7fd3b2ade000-7fd3b2adf000 r--p 00022000 09:00 18743752 /lib/x86_64-linux-gnu/ld-2.15.so 7fd3b2adf000-7fd3b2ae1000 rw-p 00023000 09:00 18743752 /lib/x86_64-linux-gnu/ld-2.15.so 7fff97bca000-7fff97beb000 rw-p 00000000 00:00 0 [stack] 7fff97bf6000-7fff97bf7000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Aborted (core dumped) -- --------------------------- Josep Manel Andrés Moscardó IT Technician at IC3 --------------------------- |
|
From: <ext...@li...> - 2013-11-17 20:49:56
|
ext...@li... a écrit : > Hello, > I removed an xbmc-app on my Thecus NAS (N2520, 2BAY-NAS) and after the > reboot I couldn't find by data-directory (/raid0/data). > The Thecus-support is not able to help me. So I pulled out the second > HDD for recovery my data. > > Now I connected the HDD on my linux system (Ubuntu 12.4) > > This is the output of---------------------------------------> > root@optibuntu:~# parted -l > Modell: ATA ST3120026AS (scsi) > Festplatte /dev/sda: 120GB > Sektorgröße (logisch/physisch): 512B/512B > Partitionstabelle: msdos > > Nummer Anfang Ende Größe Typ Dateisystem Flags > 1 1049kB 116GB 116GB primary ext4 boot > 2 116GB 120GB 4214MB extended > 5 116GB 120GB 4214MB logical linux-swap(v1) > > > Modell: ATA ST3000DM001-1CH1 (scsi) > Festplatte /dev/sdb: 3001GB > Sektorgröße (logisch/physisch): 512B/4096B > Partitionstabelle: gpt > > Nummer Anfang Ende Größe Dateisystem Name Flags > 4 1049kB 10,7GB 10,7GB RAID > 5 10,7GB 21,5GB 10,7GB RAID > 1 21,5GB 23,6GB 2147MB RAID > 3 23,6GB 24,2GB 537MB RAID > 2 24,2GB 3001GB 2976GB RAID > > This is the output of ----------------------------------------> > root@optibuntu:~# extundelete /dev/sdb --restore-all > extundelete: failed to read-only open device "/dev/sdb": Error code > 2133571347 > > This is the output of -----------------------------------------> > root@optibuntu:~# tune2fs -l /dev/sdb > tune2fs 1.42 (29-Nov-2011) > tune2fs: Ungültige magische Zahl im Superblock beim Versuch, /dev/sdb > zu öffnen > Kann keinen gültigen Dateisystem-Superblock finden. > root@optibuntu:~# > > Do you have an idea how to get it work? > > Best regards > eli You have to let the booting system know the raid configuration on sdb. You will need raid software installed on the boot system. I've never used raid, so I don't have details. BTW, why are you using raid ? Do you have a high volume system, where speed is critical ? Since one of the 'advantages' of raid is complications like this when there are problems. Essentially all raid does is speed up disk access, particularly where there is constant access. It also can (depending on the raid configuration) add somewhat to security against losing data. If not a high volume system, daily 5-minute incremental backups (instead of raid) is generally more than adequate to avoid losing data. There is also software available that does constant real-time backups. Regards -- André |
|
From: <ext...@li...> - 2013-11-17 14:02:22
|
Hello, I removed an xbmc-app on my Thecus NAS (N2520, 2BAY-NAS) and after the reboot I couldn't find by data-directory (/raid0/data). The Thecus-support is not able to help me. So I pulled out the second HDD for recovery my data. Now I connected the HDD on my linux system (Ubuntu 12.4) This is the output of---------------------------------------> root@optibuntu:~# parted -l Modell: ATA ST3120026AS (scsi) Festplatte /dev/sda: 120GB Sektorgröße (logisch/physisch): 512B/512B Partitionstabelle: msdos Nummer Anfang Ende Größe Typ Dateisystem Flags 1 1049kB 116GB 116GB primary ext4 boot 2 116GB 120GB 4214MB extended 5 116GB 120GB 4214MB logical linux-swap(v1) Modell: ATA ST3000DM001-1CH1 (scsi) Festplatte /dev/sdb: 3001GB Sektorgröße (logisch/physisch): 512B/4096B Partitionstabelle: gpt Nummer Anfang Ende Größe Dateisystem Name Flags 4 1049kB 10,7GB 10,7GB RAID 5 10,7GB 21,5GB 10,7GB RAID 1 21,5GB 23,6GB 2147MB RAID 3 23,6GB 24,2GB 537MB RAID 2 24,2GB 3001GB 2976GB RAID This is the output of ----------------------------------------> root@optibuntu:~# extundelete /dev/sdb --restore-all extundelete: failed to read-only open device "/dev/sdb": Error code 2133571347 This is the output of -----------------------------------------> root@optibuntu:~# tune2fs -l /dev/sdb tune2fs 1.42 (29-Nov-2011) tune2fs: Ungültige magische Zahl im Superblock beim Versuch, /dev/sdb zu öffnen Kann keinen gültigen Dateisystem-Superblock finden. root@optibuntu:~# Do you have an idea how to get it work? Best regards eli |
|
From: <ext...@li...> - 2013-11-11 15:23:29
|
Hi all I have an SSD mounted with the "discard" option; which I understand means TRIM commands are supported by the SSD. My questions are: - can extundelete recover deleted files on an SSD when discard (TRIM) is *disabled*? my feeling is that this does not reliably work because of the FTL: fs journaling system is only aware of the "logical" blocks, not the physical ones. When extundelete tries to read a block, it points to a "new" physical block where the file content is inaccessible. The file content might still be in the old "physical" block but how can we read it? - can extundelete recover deleted files on an SSD when discard (TRIM) is *enabled* (my case)? certainly no, because TRIM will zero the physical block. Thanks for time and answer. Wasa |
|
From: <ext...@li...> - 2013-10-24 18:08:02
|
Hi, As I pressed enter after a misplaced rm command I'm in the process of recovering with Extundelete. Excellent tool, thanks Quickly unmounted the disk and installed an NFS mount where to write recovered files to. However I was wondering if the original dates of the files could be restored as the file dates are all of today/now. Since the existence of the - -after parameter I thought this might be possible. Much obliged. Vincent Pieper |
|
From: <ext...@li...> - 2013-10-04 16:39:18
|
Hello, There is no option to list all files, but you can recovery all files by using something like this: extundelete --restore-all /dev/sda1 Change /dev/sda1 with your block device. Regards On Fri, Oct 4, 2013 at 4:33 PM, <ext...@li...>wrote: > I'm a newbie to extundelete and yes I have deleted an important folder > containing lots of files on an ext3 drive. Problem is I can't remember the > complete name of the directory I want to undelete, it had a long name. Is > it possible to display the deleted directories before running the restore > command? > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > Extundelete-users mailing list > Ext...@li... > https://lists.sourceforge.net/lists/listinfo/extundelete-users > > |
|
From: <ext...@li...> - 2013-10-04 14:33:41
|
I'm a newbie to extundelete and yes I have deleted an important folder containing lots of files on an ext3 drive. Problem is I can't remember the complete name of the directory I want to undelete, it had a long name. Is it possible to display the deleted directories before running the restore command? |
|
From: <ext...@li...> - 2013-09-28 10:20:53
|
Hello, Is there a option that allow me to first list files, and then do recovering? e.g. extundelete --list-files Regards |
|
From: <ext...@li...> - 2013-09-27 08:16:05
|
I also had a rm mishap a couple of months ago which was brilliantly restored with Extundelete. Fabulous!! Cheers, Olav On 26/09/13 20:57, ext...@li... wrote: > Dear all, > > I would like to sincerely thank all authors and contributors to the > excellent ext-undelete tool! It flawlessly recovered many hours of work > due to a 'rm' mishap. Just downloaded the source, compiled it, > unmounted, and recovered it, no fuss. > > > Met hartelijke groet / With kind regards, |
|
From: <ext...@li...> - 2013-09-26 18:58:00
|
Dear all, I would like to sincerely thank all authors and contributors to the excellent ext-undelete tool! It flawlessly recovered many hours of work due to a 'rm' mishap. Just downloaded the source, compiled it, unmounted, and recovered it, no fuss. Met hartelijke groet / With kind regards, -- H. Beijeman Brinkgreverweg 170 7413AH Deventer The Netherlands |
|
From: <ext...@li...> - 2013-08-08 18:10:12
|
Hi, >I have a hard drive that came out of a Seagate NAS device. I was running a program to copy files from the main server to this storage device and did not notice that the software was set to "Mirror" rather than "Update Target". Mirror copied all the new files on the server to the NAS then proceeded to delete all the files on the target (the NAS) that were not on the source (the server). I immediately shut the NAS device down and replaced it with another one. I then found a software that found several thousand inodes that could be undeleted but could not find any names for the files. Based on the various results of different file recovery programs I have used, the file system is an ext3 partition. I called Seagate to see if they had any software that can recover lost files, but they said that because it is an ext3 filesystem, they can not recover the lost data. > > >I have set up a CENTOS box and loaded extundelete on it. I then attached the hard drive from the NAS device and tried to run extundelete. It immediately came back with an error that the file system was mounted. Evidently, the device did not shut down properly and left the file system flagged as mounted. I tried using fdisk -l to see what the status is but it gave me an error and told me to use GNU Parted. I ran Parted check and it seemed to go through the partition just fine, but did not report anything. > > >First, I would like to grab a byte by byte copy of this partition since this is the only copy of the files I have. Can you recommend a good ghosting program to copy an image over to another 2TB hard drive? Second - How do I fix the mounted flag on this partition so that extundelete can read it? > To get a byte by byte copy, use dd (or ddrescue if there is some problem with the hardware). The command will be something like "dd if=/dev/olddisk of=/mnt/dir/file.img bs=4M". If you have enough extra space, make two copies so you have an extra in case you do something to compromise the first one during recovery. To fix the mount flag, fdisk is the right tool, so try that on the image file, and if it doesn't work, try upgrading to the newest version of fdisk (you may have run into a known bug in fdisk) or report your problem to the mailing list run by the developers of fdisk (which I believe is the linux-ext4 list). Nic |
|
From: <ext...@li...> - 2013-07-26 12:25:17
|
Dear Sirs, I have a hard drive that came out of a Seagate NAS device. I was running a program to copy files from the main server to this storage device and did not notice that the software was set to "Mirror" rather than "Update Target". Mirror copied all the new files on the server to the NAS then proceeded to delete all the files on the target (the NAS) that were not on the source (the server). I immediately shut the NAS device down and replaced it with another one. I then found a software that found several thousand inodes that could be undeleted but could not find any names for the files. Based on the various results of different file recovery programs I have used, the file system is an ext3 partition. I called Seagate to see if they had any software that can recover lost files, but they said that because it is an ext3 filesystem, they can not recover the lost data. I have set up a CENTOS box and loaded extundelete on it. I then attached the hard drive from the NAS device and tried to run extundelete. It immediately came back with an error that the file system was mounted. Evidently, the device did not shut down properly and left the file system flagged as mounted. I tried using fdisk -l to see what the status is but it gave me an error and told me to use GNU Parted. I ran Parted check and it seemed to go through the partition just fine, but did not report anything. First, I would like to grab a byte by byte copy of this partition since this is the only copy of the files I have. Can you recommend a good ghosting program to copy an image over to another 2TB hard drive? Second - How do I fix the mounted flag on this partition so that extundelete can read it? Thank You |
|
From: <ext...@li...> - 2013-06-25 18:37:24
|
Hi All, I tried to use extundelete, but received an error and my recovered files folder was indeed empty. Here's the output: xyz@xyz-System-Product-Name:~/Desktop/file recovery info$ sudo extundelete /dev/sdb1 --restore-all [sudo] password for xyz: WARNING: Extended attributes are not restored. Loading filesystem metadata ... 177 groups loaded. Loading journal descriptors ... 30810 descriptors loaded. Writing output to directory RECOVERED_FILES/ Searching for recoverable inodes in directory / ... 4062 recoverable inodes found. Looking through the directory structure for deleted files ... Unable to restore inode 655426 (lost+found/agent.1570): No data found. Unable to restore inode 655509 (lost+found/1589): No undeleted copies found in the journal. Unable to restore inode 655512 (lost+found/autospawn.lock): No undeleted copies found in the journal. Unable to restore inode 655579 (lost+found/pid): No data found. Unable to restore inode 1052133 (lost+found/safebrowsing): No data found. xyz@xyz-System-Product-Name:~/Desktop/file recovery info$ The drive needing files recovered is a small ssd, which was manually unmounted. I did not unmount the sdb5 partition as it is a swap partition. The files I am trying to recover are those from the home folder (some are in the hidden application folders) and those from the desktop, so I did a --restore-all. I assume the program also recovers folders too. What did I do wrong?? tia Art |
|
From: <ext...@li...> - 2013-06-10 19:46:03
|
On 10/06/2013 21:55, ext...@li... wrote: > inodes independent of the superblock and other structures, and then > just follow the series of pointers down to blocks to recover files > that way. It seems like inodes and directory structures would > probably have a fairly distinct signature that could be used as the > starting point. Since the files aren't deleted, the pointers to I think there should be many copies of superblock, one at the end of a modern file system. I'm wrong? Valerio |
|
From: <ext...@li...> - 2013-06-10 19:10:07
|
Hi Nic, Thanks for the quick reply and your suggestions. I haven't tried it yet, but I suspect fsck isn't going to get me far. I'll need to repair the partition table first as well. My hope was that perhaps there was at tool that can identify EXT inodes independent of the superblock and other structures, and then just follow the series of pointers down to blocks to recover files that way. It seems like inodes and directory structures would probably have a fairly distinct signature that could be used as the starting point. Since the files aren't deleted, the pointers to blocks would be intact with no need to reference the journal. Perhaps ext4magic handles this situation. I'll look into it. thanks, tim On Mon, Jun 10, 2013 at 11:18:21AM -0700, ext...@li... wrote: > > I'm have a situation where I have a number of EXT partitions that are > > corrupted and need to recover some files from them. The files I need > > are likely not deleted, but by ill fate, something like the following > > happened: > > > > dd if=/dev/zero of=/dev/hda bs=1 count=1G > > > > > > So the first gig or so of the underlying device was overwritten. I > > haven't yet seen a way to use your tools to address this situation, > > but I may have missed something. Do you have any suggestions, beyond > > just using traditional carving tools? > > > > tim > > Hi tim, > > First of all, as far as I know there is no method to recover any > data overwritten by dd (unless there is a copy of it somewhere else). > extundelete assumes that the partition it is working on is not > corrupted, so it is probably not the right tool to recover these > files. The best way to try to recover here probably involves using > fsck on a copy of the partition to try to repair the corruption and > then your files might just be there, though you would have to be > careful that parts of them weren't overwritten by zeros. I think > even if fsck doesn't repair the corruption automatically, you might be > able to manually repair it, but look to the linux-ext4 list on help > with that. I've had bad experience with file carving, so I tend to > recommend that only after other options have failed. |
|
From: <ext...@li...> - 2013-06-10 18:21:13
|
Hi, >Will extundelete work onRHEL6x using EXT4 and LVM? >I did a test and got an error, see below please. >Any thoughts? It should work, as I think I've seen others post examples using LVM and as far as I know, Redhat doesn't do anything that would break extundelete. I have sometimes had some trouble testing like this, and I've found that sometimes a few syncs are needed to ensure the file and metadata is properly written to disk. Other than that, you could be having problems because you have the wrong file name (maybe it should be "important.txt" instead of "tmp/important.txt" or because the partition was mounted while you were testing it. I think I'll see if the error messages could be more helpful here. Nic > >I create a file in /tmp called important.txt >Delete that file: >rm /tmp/important.txt > > >I try to restore and get an error: > > >extundelete /dev/mapper/vg_rhel6-lv_tmp --restore-file tmp/important.txt > > >NOTICE: Extended attributes are not restored. >WARNING: EXT3_FEATURE_INCOMPAT_RECOVER is set. >The partition should be unmounted to undelete any files without further data loss. >If the partition is not currently mounted, this message indicates >it was improperly unmounted, and you should run fsck before continuing. >If you decide to continue, extundelete may overwrite some of the deleted >files and make recovering those files impossible. You should unmount the >file system and check it with fsck before using extundelete. >Would you like to continue? (y/n) >y >Loading filesystem metadata ... 65 groups loaded. >Loading journal descriptors ... 26398 descriptors loaded. >Failed to restore file tmp/important.txt >Could not find correct inode number past inode 129838. >File name | Inode number | Deleted status >extundelete: Operation not permitted while restoring file. >extundelete: Operation not permitted when trying to examine filesystem > > >Extundelete-users mailing list >Ext...@li... >https://lists.sourceforge.net/lists/listinfo/extundelete-users > > > |
|
From: <ext...@li...> - 2013-06-10 18:18:28
|
> I'm have a situation where I have a number of EXT partitions that are > corrupted and need to recover some files from them. The files I need > are likely not deleted, but by ill fate, something like the following > happened: > > dd if=/dev/zero of=/dev/hda bs=1 count=1G > > > So the first gig or so of the underlying device was overwritten. I > haven't yet seen a way to use your tools to address this situation, > but I may have missed something. Do you have any suggestions, beyond > just using traditional carving tools? > > tim Hi tim, First of all, as far as I know there is no method to recover any data overwritten by dd (unless there is a copy of it somewhere else). extundelete assumes that the partition it is working on is not corrupted, so it is probably not the right tool to recover these files. The best way to try to recover here probably involves using fsck on a copy of the partition to try to repair the corruption and then your files might just be there, though you would have to be careful that parts of them weren't overwritten by zeros. I think even if fsck doesn't repair the corruption automatically, you might be able to manually repair it, but look to the linux-ext4 list on help with that. I've had bad experience with file carving, so I tend to recommend that only after other options have failed. Nic |
|
From: <ext...@li...> - 2013-06-10 15:28:28
|
Hello, I'm have a situation where I have a number of EXT partitions that are corrupted and need to recover some files from them. The files I need are likely not deleted, but by ill fate, something like the following happened: dd if=/dev/zero of=/dev/hda bs=1 count=1G So the first gig or so of the underlying device was overwritten. I haven't yet seen a way to use your tools to address this situation, but I may have missed something. Do you have any suggestions, beyond just using traditional carving tools? tim |
|
From: <ext...@li...> - 2013-06-07 01:28:09
|
Will *extundelete* work on* RHEL6x using EXT4 and LVM*?
I did a test and got an error, see below please.
Any thoughts?
I create a file in /tmp called important.txt
Delete that file:
*rm /tmp/important.txt*
I try to restore and get an error:
*extundelete /dev/mapper/vg_rhel6-lv_tmp --restore-file tmp/important.txt*
NOTICE: Extended attributes are not restored.
WARNING: EXT3_FEATURE_INCOMPAT_RECOVER is set.
The partition should be unmounted to undelete any files without further
data loss.
If the partition is not currently mounted, this message indicates
it was improperly unmounted, and you should run fsck before continuing.
If you decide to continue, extundelete may overwrite some of the deleted
files and make recovering those files impossible. You should unmount the
file system and check it with fsck before using extundelete.
Would you like to continue? (y/n)
y
Loading filesystem metadata ... 65 groups loaded.
Loading journal descriptors ... 26398 descriptors loaded.
Failed to restore file tmp/important.txt
Could not find correct inode number past inode 129838.
File name | Inode number | Deleted
status
extundelete: Operation not permitted while restoring file.
extundelete: Operation not permitted when trying to examine filesystem
My* /tmp* file system is EXT4 using LVM
*fdisk -l*
Disk /dev/sda: 214.7 GB, 214748364800 bytes
255 heads, 63 sectors/track, 26108 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000ba6c0
Device Boot Start End Blocks Id System
/dev/sda1 * 1 66 527360 83 Linux
Partition 1 does not end on cylinder boundary.
*/dev/sda2 66 26109 209186816 8e Linux LVM*
Disk /dev/mapper/vg_rhel6-lv_root: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Disk /dev/mapper/vg_rhel6-lv_swap: 17.2 GB, 17184063488 bytes
255 heads, 63 sectors/track, 2089 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Disk /dev/mapper/vg_rhel6-lv_mysql: 2147 MB, 2147483648 bytes
255 heads, 63 sectors/track, 261 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Disk /dev/mapper/vg_rhel6-lv_opt: 6442 MB, 6442450944 bytes
255 heads, 63 sectors/track, 783 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Disk /dev/mapper/vg_rhel6-lv_var: 8631 MB, 8631877632 bytes
255 heads, 63 sectors/track, 1049 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Disk /dev/mapper/vg_rhel6-lv_www: 4294 MB, 4294967296 bytes
255 heads, 63 sectors/track, 522 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Disk /dev/mapper/vg_rhel6-lv_home: 1090 MB, 1090519040 bytes
255 heads, 63 sectors/track, 132 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Disk* /dev/mapper/vg_rhel6-lv_tmp*: 8631 MB, 8631877632 bytes
255 heads, 63 sectors/track, 1049 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Disk /dev/mapper/vg_rhel6-lv_usr: 8631 MB, 8631877632 bytes
255 heads, 63 sectors/track, 1049 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Disk /dev/mapper/vg_rhel6-lv_avamar: 2147 MB, 2147483648 bytes
255 heads, 63 sectors/track, 261 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
*cat /etc/fstab*
#
# /etc/fstab
# Created by anaconda on Fri May 4 07:31:12 2012
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/vg_rhel6-lv_root / ext4 defaults
1 1
UUID=db106174-3523-42bf-9f9b-a626bc56ad0a /boot ext2
defaults 1 2
/dev/mapper/vg_rhel6-lv_home /home ext4 defaults
1 2
/dev/vg_rhel6/lv_opt /opt ext4 defaults 1 2
*/dev/mapper/vg_rhel6-lv_tmp /tmp ext4 defaults
1 2*
/dev/mapper/vg_rhel6-lv_usr /usr ext4 defaults
1 2
/dev/mapper/vg_rhel6-lv_var /var ext4 defaults
1 2
/dev/vg_rhel6/lv_mysql /var/lib/mysql ext4
defaults,noatime 1 2
/dev/vg_rhel6/lv_www /var/www ext4 defaults
1 2
/dev/mapper/vg_rhel6-lv_swap swap swap defaults
0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/vg_rhel6/lv_avamar /opt/csc/avamar ext4 defaults
1 2
*uname -a*
Linux rh6-template 2.6.32-358.6.2.el6.x86_64 #1 SMP Tue May 14 15:48:21 EDT
2013 x86_64 x86_64 x86_64 GNU/Linux
Thank you,
Ernest G. Wilson II
|
6 messages has been excluded from this view by a project administrator.