Depending on a reason for suspension.
If it’s because of offline (the online score is below 60%), then it went from suspension when the online score would be greater than 60%, how fast is depend on amount of data and audits frequency, and the node’s age. To fully recover your node should be online for the next 30 days.
If it’s because of suspension score below 60% (your node answering on audits with unknown errors), then it went from the suspension when the suspension score will be greater than 60%. It will grow with each successful audit.
Since your node has a low suspension score, it answers on audits with unknown error (“file not found”, “I/o” and corrupted files are known errors and they affect an audit score instead).
To check the reason of falling suspension score you may use this article:
Dropping of suspension score is unrelated to downtime, only the online score depends on your online status.
The suspension score is dropping when your node answers on audits (i.e. it’s online), but returned an unexpected error instead of the requested piece. This is much more dangerous than falling of online score, because the next stage is failing audits and disqualification.
The online score will fully recover in the next 30 days online. The suspension score would recover with each successful audit. If it’s still falling, you need to figure out the issue and fix it ASAP.
In this case it would be a timeout, and it doesn’t affect neither of scores immediately, only if the audit of the same piece would timeout two more times then it will be considered as failed and will affect the audit score.
In other words, to get a suspension score affected the node must be online and must answer on audit with unknown error, so it cannot be a timeout like in case of interruption.
I would insist on searching for a reason of failed audits in the log.
sudo docker logs storagenode 2>&1 | grep -E “GET_AUDIT|GET_REPAIR” | grep failed
I ran it with sudo because accessing my logs file is access denied otherwise, “docker logs storagenode” for example is denied if sudo is not used.
This returns nothing as well but it just takes a long time.
Since they uses docker logs, the log is not redirected to the file, it’s in the container. And when the container is re-created, the log will be deleted with the container.
For honestly I do not know, how to see a log size for the container except searching for the container’s storage location.