Critical Audit Failures after migration to new hardware

Hi there,

I transferred the data (about 250GB) to a new platform and now I’ve received 4 critical audit failures. The method I used was to shut down the node and docker then used RSYNC to copy the data. The new server started up fine and all was going well but now it appears its failing audits. I guess all the data didn’t make it but something is definitely wrong. The last time I did this I compressed the data a big file and copied it to the new server and all went well. I was trying to save some time but maybe zipping is a better idea.

Salt Lake has me as DQ but others don’t. This is a fairly new node and had not completed it’s vetting yet and my scores are increasing. If it’s gone DQ on one server will others follow? Should I just nuke the server and start over?

Thanks in advance for your help.

I would just make a new node at this point…250gigs isnt much and all that data is probably from saltlake satellite anyways so your at a complete loss. So not much of a loss if you just started over now. Figure out why it DQed first though my bets are that either the path wasnt correct or all the data didnt get transfered over.

1 Like

Just so I understand the system, once you are DQ’d by a satellite you will never go online there again? I am passing audits from all the others it appears because 8 more have been done over the last 24hrs and my scores are increasing. I don’t think all of the data is bad but you are right about most of the data coming from Salt Lake…

Yes once DQed by that satellite you can never get back again, As for the audits if data was missing for one satellite chances are high that the data will be missing from the other as well the reason salt lake got DQed so fast is because it had the most data, As for the others you have alot less data which its not check audits as often to make sure you have all the data that is there. For an example you may not get DQed right away but if there is enough missing data from the other satellites you will get DQed anyways. Say you had a path /storagenode so then its looking for storage folder but then you set it /storagenode/storage so then it created a folder called storage and started storing new data in the new storage folder.

But without knowning if your data was ever in the right path you could be storing the data in a whole different location then what you may have started with before you moved everything.

Ya, I made the path mistake last year but recovered it shortly after realizing what happened. I copied the new blobs to the old directory and fixed the path. Fortunately that one never failed an audit and to this day still hasn’t. Definitely the best thing to do then is to put another node on that server and consider it a lesson. Thanks for the info!

so you will be DQ if you LOOSE data, so either your copy or setup is broken, or something else is. you don’t have to shutdown your node, if you read the forum here there are multiple guidelines how it can be done.

once you been DQ there is no way back

Hi again, I just moved data from a node to a new server and this time I put the files into a tar.gz and extracted them on the new server. I’m trying to avoid the DQ issue I had last time and was wondering if there are any file permissions or anything I need to reset on the new server. I compressed the files as root from the old server and decompressed as root on the new. Will Docker take care of everything or should I worry?

Make sure, that you will specify the path to the new location in your --mount type=bind,source=/your/new/location,destination=/app/config option of the docker run command
If you are not sure - post the list of the /your/new/location here with ls -l