Use btrfs restore on cache drives

[3ajs]

Hello, I have a couple files that seem to have disappeared in transit between cache and data drives when mover was running. I have taken the 2 cache drives off for now and I'm hoping someone can help with recovering the files from the cache drives.

 

I'm using the command

btrfs restore -d /dev/sdc /mnt/disk4/recovery

 

The error I'm getting is:

No valid Btrfs found on /dev/sdb

Could not open root, trying backup super

 

I have tried this command in the following ways:

1. mounted as a 2 drive cache pool (original configuration)

2. mounted as an unassigned device

3. unmounted as an unassigned device

 

All 3 methods produce the same error. I have also run btrfs scrub already and it does say that it has scrubbed 2.5GB - even though it only shows 183MB as being used at the moment. Is there any way to use either btrfs scrub or btrfs restore to recover the lost files from the cache drives?

 

I've disabled trim schedule for now and taken the shares off the cache to preserve the data.

 

The first priority is to recover the files but secondarily here is the diagnostics log hinting at why the files are gone....

 

Nov 12 04:47:27 Tower emhttpd: shcmd (55198): /usr/sbin/hdparm -y /dev/sdb
Nov 12 04:47:27 Tower root: 
Nov 12 04:47:27 Tower root: /dev/sdb:
Nov 12 04:47:27 Tower root:  issuing standby command
Nov 12 04:47:27 Tower emhttpd: shcmd (55199): /usr/sbin/hdparm -y /dev/sdc
Nov 12 04:47:28 Tower root: 
Nov 12 04:47:28 Tower root: /dev/sdc:
Nov 12 04:47:28 Tower root:  issuing standby command
Nov 12 04:48:44 Tower kernel: mdcmd (327): spindown 1
Nov 12 04:48:45 Tower kernel: mdcmd (328): spindown 4
Nov 12 04:48:46 Tower kernel: mdcmd (329): spindown 5
Nov 12 04:48:46 Tower kernel: mdcmd (330): spindown 6
Nov 12 04:48:47 Tower kernel: mdcmd (331): spindown 7
Nov 12 04:48:47 Tower kernel: mdcmd (332): spindown 8
Nov 12 04:48:49 Tower kernel: mdcmd (333): spindown 2
Nov 12 04:49:45 Tower kernel: mdcmd (334): spindown 0
Nov 12 04:49:46 Tower kernel: mdcmd (335): spindown 3
Nov 12 04:49:47 Tower kernel: mdcmd (336): spindown 29
Nov 12 05:41:04 Tower afpd[15406]: dsi_stream_read: len:0, unexpected EOF
Nov 12 05:45:36 Tower afpd[18851]: dsi_stream_read: len:0, unexpected EOF
Nov 12 05:45:48 Tower shfs: share cache full
### [PREVIOUS LINE REPEATED 3 TIMES] ###
Nov 12 07:37:11 Tower emhttpd: req (34): cmdStartMover=Move+now&csrf_token=****************
Nov 12 07:37:11 Tower emhttpd: shcmd (55540): /usr/local/sbin/mover &> /dev/null &
Nov 12 08:28:09 Tower afpd[13050]: dsi_stream_read: len:0, unexpected EOF
Nov 12 10:17:00 Tower afpd[12653]: dsi_stream_read: len:0, unexpected EOF
Nov 12 13:08:32 Tower afpd[14473]: dsi_stream_read: len:0, unexpected EOF
Nov 12 13:16:09 Tower kernel: mdcmd (337): spindown 2
Nov 12 13:16:10 Tower kernel: mdcmd (338): spindown 4
Nov 12 13:16:11 Tower kernel: mdcmd (339): spindown 5
Nov 12 13:16:11 Tower kernel: mdcmd (340): spindown 6
Nov 12 13:16:12 Tower kernel: mdcmd (341): spindown 7
Nov 12 13:16:12 Tower kernel: mdcmd (342): spindown 8
Nov 12 13:17:10 Tower kernel: mdcmd (343): spindown 0
Nov 12 13:17:11 Tower kernel: mdcmd (344): spindown 29
Nov 12 14:38:33 Tower crond[2767]: exit status 1 from user root /usr/local/sbin/mover &> /dev/null
Nov 12 16:21:27 Tower afpd[807]: dsi_stream_read: len:0, unexpected EOF

 

[JorgeB]

You need to specify the partition, e.g., sdc1, though doubt btrfs restore is going to work for this scenario.

[3ajs]

Thanks so much for your reply @johnnie.black. Any idea why this happened? It seems like mover deleted the file from cache before it was transferred to data drive?

[JorgeB]

18 minutes ago, 3ajs said:

Any idea why this happened?

No, mover logging appears to be disable so not much info on the syslog, but don't recall this happening before.