You should try as long as possible to transfer the data from your old disk even if it is failing. The more data you can move across the more likely the node will continue to function and not be disqualified.
If the disk is failing you should have stopped the node already and just focus on transferring the node data and identity. You can take up to 14 days with the node offline before the offline time becomes an issue.
There is also mixed reasoning as it may be in your interest to be offline longer (still up to the 14 days) so StorJ repair tasks are initiated, causing some missing data from your node to not ever try to be read again - thus you would miss out on those segments being counted against your node disqualification.
you could try to use some data recovery software, when a disk is operating normally it will give up on reading damaged sectors after a while…
recovery software will change parameters so that it might take much longer to retrieve the data…
also i find that often limiting the speed of the a transfer greatly improves the odds of data being retrieved
EaseUS has a pretty good data recovery software is pretty good… but that is proprietary software.
blobs contain 99.9% of the data so it is also the most likely to show problems…
the other files can also have problems, even a retrieved file from a bad hdd or even a good hdd isn’t a sure fire thing.
but like alexeys said, identity and blobs is critical information… max loss that is survivable is like 12% of the blobs or was… not sure if the methodology has changed yet… but you can atleast loose some of the blobs, but you will need most of them and with a smaller node one might be able to outrace DQ with growth.
but ofc first you have to get the storagenode out first…
yeah try EasyUS if anything can fix it then their software can, it’s no magic bullet tho… and there are even more advanced stuff… but one quickly runs into budget and research time issues.
Depends on the mode of failure. In some cases you can recover data from failing sectors if you repeat your reads many times. ddrescue is helpful in these scenarios, already had several cases in which it was useful.
Ive never had any luck recovering data from a dying drive theres always been where the drive just times out while trying to copy no matter what I tried. And Ive tried every single software under the moon, The drive was just to far gone. Theres no guarantee of getting all the data back off even with rescue software…
So, the node is up and running; obviously suspended.
I had another problem I didn’t have before “the crash”: the web interface says that QUIC is misconfigured, I setup the router to forward both TCP and UDP to port 28967, and put this line into my start script:
Just a quick note as for the data recover: it seems that macOS (monterey, the last release), as some routines that acts as data recover.
The Finder tried to copy data, but it seems that he scanned the data and put them in some cache, when found some unreadable blocks/data asked me to stop the copy or finalize it, I choose finalize and then started copying to new disk; this way I recovered almost all the blobs!
just takes a long time but if one is careful and doesn’t write new / change existing data on the disk.
then often i find one can get data back… its just often damage in many or some of the files itself. so one never really gets a flawless data set back…
Good lucky will be interesting to see how it goes long term.