Creating identity on storagenode host, seemingly disrupted existing storagenode identity

[Alexey]

If by “issue” you mean the “database is locked”, then it’s unrelated to the identity generation.
It’s known issue: Search results for 'database is locked' - Storj Community Forum (official)
It could be either

Could not rollup bandwidth usage {"error": "bandwidthdb error: database is locked", "errorVerbose": "bandwidthdb error: database is locked

Could not rollup bandwidth usage {“error”: “bandwidthdb error: database is locked”, “errorVerbose”: “bandwidthdb error: database is locked\n\tstorj.io/storj/storagenode/storagenodedb.(*bandwidthDB).Rollup:212\n\tstorj.io/storj/storagenode/bandwidth.(*Service).Rollup:51\n\tstorj.io/storj/internal/sync2.(*Cycle).Run:87\n\tstorj.io/storj/storagenode/bandwidth.(*Service).Run:43\n\tstorj.io/storj/storagenode.(*Peer).Run.func9:417\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57”} stderr 10:42:08

or

Could not rollup bandwidth usage - database is locked

I just did an integrity check on the info.db through sqlite3 (while I had my node temporarily offline), and it went ok, but after starting up the node, I see this error: 2019-09-07T12:10:06.914Z ERROR bandwidth Could not rollup bandwidth usage {"error": "bandwidthdb error: database is locked", "errorVerbose": "bandwidthdb error: database is locked\n\tstorj.io/storj/storagenode/storagenodedb.(*bandwidthDB).Rollup:212\n\tstorj.io/storj/storagenode/bandwidth.(*Service).Rollup…

And there is a little research:

Database is locked. What is the reason? What is the possible solution?

Short update from a meeting with the developers today about the db locking: The piece size is way too small and causing an IOPS bottleneck that we need to fix. I am not sure about the details but the long term goal is to write bigger pieces to disk. That should improve performance. Why do we store serial numbers for 48h in a DB? We should keep that in memory and don’t write it to disk at all. That will solve that problem entirely. We still want to write orders into a DB. If the node is restart…

If you moved your previous identity from the /root/.local/share/storj/identity/storagenode to somewhere (I believe you did that, otherwise the generation would fail with “file is exist”), then there is nothing unusual.
By the way, you can use a different name for the identity to avoid confusion:

identity create storagenode2

for example and then use this new name to sign the identity.
The path would be /root/.local/share/storj/identity/storagenode2.