It seems like the node restarts on itself

[Alexey]

@TrickyZerg

I assume that this must be the watchtower updating my node or am I mistaking here?

Not a watchtower, the storagenode-updater. It has been downloaded when the container is started.
We now publishing a docker image, which downloads the latest storagenode-updater, then it’s started and checks for a new version of storagenode, allowed for your NodeID.
So, in short - the image now is self updating.
See

Changelog v1.52.2

Yeah, you’re right. The storagenode image contains neither the storagenode nor the storagenode-updater binaries. It has only supervisord, and the entrypoint script. The entrypoint scripts checks and installs the minimum version of the storagenode-updater binary if it’s not already installed, and later installs the storagenode binary. Once both the storagenode and storagenode-updater are installed, the entrypoint scripts starts supervisord which then starts the storagenode and updater processes…

These errors related to the locked databases

@TrickyZerg

2022-04-11T06:42:00.487Z        ERROR   services        unexpected shutdown of a runner {"name": "trust", "error": "satellitesdb: database is locked", "errorVerbose": "satellitesdb: database is locked\n\tstorj.io/storj/storagenode/storagenodedb.(*satellitesDB).SetAddress:40\n\tstorj.io/storj/storagenode/trust.(*Pool).Run:124\n\tstorj.io/storj/private/lifecycle.(*Group).Run.func2.1:87\n\truntime/pprof.Do:40\n\tstorj.io/storj/private/lifecycle.(*Group).Run.func2:86\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57"}
2022-04-11T06:42:04.111Z        ERROR   piecestore      failed to add bandwidth usage   {"error": "bandwidthdb: database is locked", "errorVerbose": "bandwidthdb: database is locked\n\tstorj.io/storj/storagenode/storagenodedb.(*bandwidthDB).Add:60\n\tstorj.io/storj/storagenode/piecestore.(*Endpoint).beginSaveOrder.func1:723\n\tstorj.io/storj/storagenode/piecestore.(*Endpoint).Upload:435\n\tstorj.io/common/pb.DRPCPiecestoreDescription.Method.func1:220\n\tstorj.io/drpc/drpcmux.(*Mux).HandleRPC:33\n\tstorj.io/common/rpc/rpctracing.(*Handler).HandleRPC:58\n\tstorj.io/drpc/drpcserver.(*Server).handleRPC:122\n\tstorj.io/drpc/drpcserver.(*Server).ServeOne:66\n\tstorj.io/drpc/drpcserver.(*Server).Serve.func2:112\n\tstorj.io/drpc/drpcctx.(*Tracker).track:52"}

This is due the fact that the Docker Desktop for Windows uses the network to mount your disks. SQLite databases cannot work normally on a network drives when there is a concurrent access.
From provided excerpts I can only assume, that since the runner is died, the storagenode has been restarted.