Possible to recover deleted data from NSA325 v2 without RAID?

AleXSR700
AleXSR700 Posts: 41  Freshman Member
edited January 2020 in Personal Cloud Storage
Hi everyone,
I wanted to create a backup using rsync and pointed to the wrong target directory. Now rsync of course started to delete the data in the target folder. Nothing was overwritten. Just deleted.

Question now is if there is a way to recover this data? Normally I would hook up the drive to my notebook and use Recuva or Easeus Data Recovery, but since the NAS uses a different filesystem not supported by Windows, that does not seem to be an option.

does anybody have any ideas? I lost around 1 TB worth of data and since it wasn't overwritten, it should still all be there :-(

Thank you for your help!

Alex


#NAS_Jan_2020

All Replies

  • AleXSR700
    AleXSR700 Posts: 41  Freshman Member
    Hi,
    I managed to find the disk using a GParted Live CD and running testdisk.

    But the question is what the correct system type and filesystem is. Does anybody know?
    According to 'df -Th' it should be ext4 as a filesystem. But which "type" in testdisk because selection e.g. MBR results in the error message that the filesystem is damaged eventhough it works perfectly fine in my NAS?
  • AleXSR700
    AleXSR700 Posts: 41  Freshman Member
    More info:

    <code>
    TestDisk 7.0, Data Recovery Utility, April 2015
    Christophe GRENIER <grenier@cgsecurity.org>
    http://www.cgsecurity.org

    Disk /dev/sdb - 1801 GB / 1678 GiB - CHS 219051 255 63
    Current partition structure:
         Partition                  Start        End    Size in sectors

     1 P MS Data                     2048     999423     997376 [firmware]
    No FAT, NTFS, ext2, JFS, Reiser, cramfs or XFS marker
     2 P MS Data                   999424 7814035455 7813036032 [eexxtt44]
     2 P MS Data                   999424 7814035455 7813036032 [eexxtt44]
    </code>

    As soon as I select the correct partition the "undelete" option disappears:
    <code>
    TestDisk 7.0, Data Recovery Utility, April 2015
    Christophe GRENIER <grenier@cgsecurity.org>
    http://www.cgsecurity.org

    Disk /dev/sdb - 1801 GB / 1678 GiB - CHS 219051 255 63

         Partition                  Start        End    Size in sectors
      1 P MS Data                     2048     999423     997376 [firmware]
    > 2 P MS Data                   999424 7814035455 7813036032 [eexxtt44]

     [  Type  ] >[Image Creation]  [  Quit  ]
                                    Create an image
    </code>

    But it shows on the "firmware" partition and I can also successfully "List" the items on that partition.

    Does anybody know how I can get the second partition to properly list so I can then undelete?



  • Mijzelf
    Mijzelf Posts: 2,605  Guru Member
    First Anniversary 10 Comments Friend Collector First Answer
    You have made yourself a problem.

    First, the filesystem is ext3, and even if you didn't have raid, the 325 puts it in a raid container, which can explain an offset testdisk finds compared to the partition table. But if you can create a partition around the filesystem, omitting the raid header, that's fine for recovery purposes.

    ext3 doesn't really have an 'undelete' function. Yet someone wrote a tool (http://extundelete.sourceforge.net/) which might do the trick. Of course every write to the filesystem lowers that chance.

    You already found testdisk. It's cousin photorec can recover files from raw space, it doesn't need any help from the filesystem. That's great if the filesystem is unknown, or beyond repair. A downside of that approach is that it won't recover any metadata from the filesystem. So you'll get a bunch of random named files, without timestamp.

  • AleXSR700
    AleXSR700 Posts: 41  Freshman Member

    Hi Mijzelf,

    thank you for your reply. I also found extundelete but that did not work as easily either. But then of coure command line tools never quite look as promising as a good GUI ;-)

    I stumbled across Diskinternals Linux Recovery and also then found EaseUS to support Linux systems. So I will first give Diskinternals a try. It immediately recognized the HDD as being a RAID system and even named it according to the IP of the NAS. So it seems to correctly identify everything. Unfortunately the scan process on my 4 TB HDD does not just take the estimated 4 h. I am guessing it will be closer to 24 h. If I can recover the files with correct filenames, I will do so. If not, I will try EaseUS next and then extundelete and testdisk last (primarily because Linux live distributions are far less comfortable than my running Windows system.

    I will let you know how it goes.


    But speaking of all this trouble. Is there no way of having the NAS work with normal exFAT filesystems internally? You can hook up an exFAT, NTFS, FAT32 USB drive and share it but the internal disks are always formatted to a LINUX RAID ext3 partition. Why? I am not even using a RAID system.

  • Mijzelf
    Mijzelf Posts: 2,605  Guru Member
    First Anniversary 10 Comments Friend Collector First Answer
    edited January 2020
    But speaking of all this trouble. Is there no way of having the NAS work with normal exFAT filesystems internally? You can hook up an exFAT, NTFS, FAT32 USB drive and share it but the internal disks are always formatted to a LINUX RAID ext3 partition. Why?
    Why would exFAT be more 'normal' than ext3?

    The reason that the internal disks are ext3 (and on the NAS series ext4) is performance. On Linux ext is (much) faster than NTFS.  Further it's not possible to install Linux software on a Windows filesystem, due to the lack of execute bits and symlinks. So the installable packages can't be installed on NTFS.

    exFAT and FAT32 are not robust. Both have to many single points of failure.

    I am not even using a RAID system.
    That is unrelated. Raid and the filesystem are different issues. It's perfectly possible to install NTFS on Linux software raid.


    And last but not least, would it help? A damaged filesystem is not usable, no matter which filesystem it is.
  • AleXSR700
    AleXSR700 Posts: 41  Freshman Member
    No, the point would be that Linux is not really common and recovery tools for Linux are sparse and not as good as their Windows counterparts.
    If I could simply hook up the HDD to my Windows notebook and run one of the many data recovery tools, I would have access to all my files already.

    But it being ext3, almost no Windows programs can access the drive and recovery of the data is far more difficult.

    The first attempt using Diskinternals Linux Recovery failed. The files were not found.

    And all of this ecen though the filesystem and everything are in perfect working order. If it were an NTFS or exFAT filesystem, Windows would recognize the disk and the superior software packages available would have long recovered the files.

    It is a bit annoying that a safety function like using ext3 ultimately causes more issues in case of data loss than an NTFS drive would.
    Given the lack of processing power of NAS like the NSA325v2, there also seems no real performance benefit.

    Only reason I can see is that Linux is free and therefor a lot of manufacturers use it.

    Anyway, it should be a piece of cake to recover deleted files on a working harddrive. But because of the ext3 filesystem it is a very difficult task. May even turn out to be impossible. If that is the case I might even put the drives into external cases, hook them up via USB and use them as external shares. Just so I can use a Windows compatible filesystem :-(
  • Mijzelf
    Mijzelf Posts: 2,605  Guru Member
    First Anniversary 10 Comments Friend Collector First Answer
    Given the lack of processing power of NAS like the NSA325v2, there also seems no real performance benefit.
    Especially on a low processing power system there is benefit. If your NAS can saturate either the disk or the network with a negligible cpu load, then a few percent extra cpu cycles for a more demanding filesystem is no problem. But the 325 is cpu limited. I think you can get around 50MB/sec throughput, which saturates neither the disk, nor the network. So every extra cpu cycle used for that more demanding filesystem, is paid directly in throughput.
    Anyway, it should be a piece of cake to recover deleted files on a working harddrive. But because of the ext3 filesystem it is a very difficult task.
    As far as I know the only filesystems which have build-in support for undelete are ZFS and BTRFS, and then only when the files are still available in the latest snapshot.
    Why do you think you could delete 1TB of files from an NTFS disk, and then still be able to recover it?



Categories

Consumer Product Help Center

EnglishTiếng ViệtРусскийไทย中文（台灣）