Files Disappeared! Thanks QNAP!

[SupaMonkey]

So I have a TS-431P for some time now working fine with 3 non-RAID disks just hosting a variety of videos / photos / etc.
Today I brought my 3TB Seagate externall hdd (NTFS) and plugged it into the USB port in the front and using the web interface / File Station - I 'moved' a bunch of videos from the 3TB to QNAP. I saw the process was moving along swimmingly - but after a while, I was only at 30% - so decided to just leave it.
When I come back to check hours later; I see:
1) A bunch of errors on QNAP (unfortunately I cant paste a copy of such an error because the NAS has restarted since and seems to have cleared the log since the restart).
2) Files not on the QNAP
3) Files not on the Seagate HDD

GONE! Terrabytes of data, just gone. Call me stupid/a noob for "moving" instead of copying. But I assumed in the 21st century, a simple 'move' operation wasnt rocket science. Surely if something fails in the move, it should abort, hence leaving whats left at the source intact (at least, this is what windows does) instead of just carrying on and deleting the source files even though they werent moved to the destination successfully (at least, this is what appears to have happened). Im rather annoyed. At this stage, this NAS has cause me more headaches than conveniences and I'm thinking a cheap computer with HDD's would of worked out better.

[CylonCenturion]

So I have a TS-431P for some time now working fine with 3 non-RAID disks just hosting a variety of videos / photos / etc.
Today I brought my 3TB Seagate externall hdd (NTFS) and plugged it into the USB port in the front and using the web interface / File Station - I 'moved' a bunch of videos from the 3TB to QNAP. I saw the process was moving along swimmingly - but after a while, I was only at 30% - so decided to just leave it.
When I come back to check hours later; I see:
1) A bunch of errors on QNAP (unfortunately I cant paste a copy of such an error because the NAS has restarted since and seems to have cleared the log since the restart).
2) Files not on the QNAP
3) Files not on the Seagate HDD

GONE! Terrabytes of data, just gone. Call me stupid/a noob for "moving" instead of copying. But I assumed in the 21st century, a simple 'move' operation wasnt rocket science. Surely if something fails in the move, it should abort, hence leaving whats left at the source intact (at least, this is what windows does) instead of just carrying on and deleting the source files even though they werent moved to the destination successfully (at least, this is what appears to have happened). Im rather annoyed. At this stage, this NAS has cause me more headaches than conveniences and I'm thinking a cheap computer with HDD's would of worked out better.

Nothing in the $recycle ?

[P3R]

Regarding the topic of the thread, Qnap and everyone else that know anything about data storage says that you should always keep backups of your data. So blaming Qnap for lost data is simply wrong. Look in a mirror and you will see the one person responsible.

So I have a TS-431P for some time now working fine with 3 non-RAID disks just hosting a variety of videos / photos / etc.

It's strongly recommended by all experienced administrators to use some kind of RAID (RAID 0 isn't really RAID) for at least the first, the system volume in the NAS. Unless you do that, then when (not if) the first disk fail you will lose access to the complete NAS and all data on all disks.

Call me stupid/a noob for "moving" instead of copying.

Keeping data as a single instance is an accident waiting to happen. Using less safe methods (like move instead of copy+delete) of administering that data adds to the risk and it seems your luck finally run out.

At this stage, this NAS has cause me more headaches than conveniences...

1. You're apparently not having backups of your data
2. You're using an non-recommended disk configuration in the NAS
3. In your other thread I notice that you're reading an incorrect documentation for the NAS model you have.

If you're having problems, I'm not very surprised about that.

...I'm thinking a cheap computer with HDD's would of worked out better.

Maybe or maybe not but every computer regardless of operating system can fail and if you haven't got a backup you will eventually lose data. And when you do lose that data, it's not the fault of the computer or the OS but the user that didn't have his backups in order.

You could try to use file recovery software on the external disk. Please use something well-known and not the malware-infected ones that spam forums to get coverage.

[dolbyman]

sounds like the common move via file station bug...several people have lost data that way

a copy instead of a move would have resulted in no data loss

[Moogle Stiltzkin]

sounds like the common move via file station bug...several people have lost data that way

a copy instead of a move would have resulted in no data loss

i'd do 'move' most of the time rather than copy, but then again i don't really use filestation unless i'm going for max performance for internal transfers. though in his scenario where he plugged in an external usb direct to the qnap i'd probably use filestation or backup station.

but what is this bug ? i would just normally expect the move function to just work ... o_O; what firmware were you using supa ?

what hdds are using for your qnap?

usually when i make an accident on delete on my desktop i use recuva
https://www.piriform.com/recuva


but your accident happened on the nas during a usb external transfer :/ did you create a support ticket? did that give you any suggestions for recovery method ?

maybe using recuva on your usb hdd for recovery MAY work, but i'm not sure.
[youtube=]KFwq8KKVvhw[/youtube]



anyway i do recommend for the future to strongly have a backup option. i opted for the more pricer 2 qnap units for a 1:1 ratio backup using a lan rtrr sync share folder method (1 way source to destination) manual not scheduled method.

[OneCD]

but what is this bug ? i would just normally expect the move function to just work o_O; what firmware were you using supa ?

viewtopic.php?f=15&t=126824

[Moogle Stiltzkin]

but what is this bug ? i would just normally expect the move function to just work o_O; what firmware were you using supa ?

viewtopic.php?f=15&t=126824

thx, wow i missed that important alert

i'll keep this in mind

- File integrity is now checked when copying/moving files.

uh... yeah when i tested this option a while back, to see what happened with it not selected in rtrr, i was a bit worried about the result. so i redid it and kept this option enabled from then on.

[acpiper]

I was upgrading my hard drives, making some changes to the configuration, adding RAID capability, and used an external drive to temporarily copy the contents. After all this configuration I then started a move routine from the external to the new QNAP volume. Imagine my surprise when I realized that the save wasn't going where I intended, and the cancellation afterwards caused 2 terabytes of data to suddenly vanish. Now - you may chide us on on backup practices, or using something other than a "move" command, but the bottom line is is that's apparently a known issue within the OS that QNAP has not addressed. The data that I lost I'm sure can be recovered - the 5 seconds that it took me to realize my mistake could not have done that much damage. Besides, life goes on...

[eldor]

Ok. You made several mistakes which have caused data lost with any OS and you blame qnap for it? Cool. Sooo what should have qnap done to avoid your Problem? Allow the move command only when you have passed a test that you really know what you are doing? Just kidding.

Lessons learned: NEVER use the move command! NEVER!! Only copy the data and delete them from the source AFTER you have checked that everything is fine.

Gesendet von meinem HUAWEI GRA-L09 mit Tapatalk

[P3R]

Lessons learned: NEVER use the move command! NEVER!!

A more important lesson in my opinion is to always have backups of all data that have any importance. Data stored at only a single system will eventually be lost.

[eldor]

Of course. But when he started, he had one Set of his data he could have copied to the new storage. Then there would be a Backup...

Gesendet von meinem HUAWEI GRA-L09 mit Tapatalk

[kherr4377]

i always thought the 'move' command was only for moving files within the same share. it doesn't actually 'move' the date, just alters the allocation file, or whatever you call it that points to the actual location on the disk.

[P3R]

i always thought the 'move' command was only for moving files within the same share. it doesn't actually 'move' the date, just alters the allocation file, or whatever you call it that points to the actual location on the disk.

Yes that's how it works within a shared folder.

Between shared folders/volumes/systems a move is really a copy and then a delete of the source data. Or at least that's the way a move is supposed to work.

[schumaku]

i always thought the 'move' command was only for moving files within the same share. it doesn't actually 'move' the date, just alters the allocation file, or whatever you call it that points to the actual location on the disk.

Yes that's how it works within a shared folder.

This is true when it comes ie. to a SAMBA operation.

The more generic U**x-like commands (assumingly used under the File Station hood) don't know anything about shared folders.

Between shared folders/volumes/systems a move is really a copy and then a delete of the source data. Or at least that's the way a move is supposed to work.

Yes. Last time I've tested this it must have been a plain U**x move: If you have Advanced Folder Permissions in place (ACLs), and move folders and files from one shared folder to another (with different ACLs), you see that the ACLs are not updated according to the destination share settings.

[jnai9]

I completely understand SupaMonkey's anger. If he had to this on any computer, this would not happen. QNAP failed to COPY files, but the second step of MOVE is DELETE and it did that anyway. Data destruction should be more protected. There should be an option to compare if the files were copied successfully before delete on MOVE.
Don't lecture me about backup. There is just a limited amount of USB drives available (which are mostly full) and I don't believe any of you have spare empty TBs of drives laying around to make double backup before copying or moving data to/from QNAP. It's just too much hassle and not that important.

I had a similar problem with Sync. I thought I set the sync task to copy files to an external USB disk folder.
Instead, QNAP "SYNCED" selected share to USB root and DELETE ALL FILES FROM EXTERNAL USB.
4TB of movies gone, because I wanted to copy about 300GB of photos to external USB.
Recovery on NTFS USB disk was unsuccessful.
I'm still not sure what is the proper way to copy a bunch of folders to external USB disk and there is no proper protocol described anywhere. I don't want to copy files through the network (300GB takes 12 hours).

What could QNAP do? Definitely Sync Station SHOULD WARN that ALL DATA on destination drive will be deleted before finishing the configuration wizard.