# Cloned HDD OS to SSD which contained DB files - what to look for in logs

**URL:** <https://forum.storj.io/t/cloned-hdd-os-to-ssd-which-contained-db-files-what-to-look-for-in-logs/21061>\
**Category:** Node Operators\
**Tags:** database, hardware\
**Created:** [January 18, 2023, 5:51pm UTC](https://forum.storj.io/t/cloned-hdd-os-to-ssd-which-contained-db-files-what-to-look-for-in-logs/21061 "2023-01-18T17:51:02Z")\
**Posts on this page:** 17\
**Page:** 1

<div class="post-metadata">

**Author:** ![thelastspark](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/thelastspark/32/1132_2.png) [@thelastspark](https://forum.storj.io/u/thelastspark)\
**Post date:** [January 18, 2023, 5:51pm UTC](https://forum.storj.io/t/cloned-hdd-os-to-ssd-which-contained-db-files-what-to-look-for-in-logs/21061/1 "2023-01-18T17:51:02Z")

</div>

Hi all,

As per the title, for the longest time I was running (Win 10) 3 nodes on 3 drives (one of which was the OS). All the nodes .exe’s are on the OS drive with folder as below

 ![image](https://storj-s3.bcdn.literatehosting.net/original/2X/3/3fb82c1636380bc83ad5cfcc3f02f2ef1726a7fe.png)

The 2 nodes (data folders) are on their own drives are as follows:

 ![image](https://storj-s3.bcdn.literatehosting.net/original/2X/2/283f0dcc0b63c03407df897a867b13e92c9d1087.png)

I have now purchased an SSD and cloned my HDD and booted. Everything seems to be running fine…

My question is, is the DB for each NODE currently in the data folder? And if so is that the best, or should I move their DB’s to the SSD (and why?)? If yes, is there a link or guide to doing that?

Second question, what should I look for in the logs do indicate anything going awry with my nodes? I’m planning on wiping my previous HDD and using it to move the node currently on the OS onto it, but don’t want to wipe my HDD until I’m certain everything got moved okay.

Thanks!

---

<div class="post-metadata">

**Author:** ![Stob](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/stob/32/1137_2.png) [@Stob](https://forum.storj.io/u/Stob)\
**Post date:** [January 18, 2023, 9:12pm UTC](https://forum.storj.io/t/cloned-hdd-os-to-ssd-which-contained-db-files-what-to-look-for-in-logs/21061/2 "2023-01-18T21:12:48Z")

</div>

> [@thelastspark](#):
>
> what should I look for in the logs do indicate anything going awry with my nodes?

ERROR and WARN entries in the logs.

> [@thelastspark](#):
>
> is the DB for each NODE currently in the data folder?

Yes, that is the default.

> [@thelastspark](#):
>
> if so is that the best, or should I move their DB’s to the SSD (and why?)? If yes, is there a link or guide to doing that?

Possibly, probably but it depends.

Warning - [How to move DB’s to SSD on Docker - #2 by BrightSilence](https://forum.storj.io/t/how-to-move-db-s-to-ssd-on-docker/7064/2)

Procedure - you would use the new SSD drive letter and path, instead of S:\Storj

> [@Storagenode: allow configuring database path independently (v1.4.2 and above only)](https://forum.storj.io/t/storagenode-allow-configuring-database-path-independently-v1-4-2-and-above-only/6811/1):
>
> - Stopped both services
> - I edited the “ **config.yaml** ” file and added “Storage2.Database-Dir: S:\Storj\Databases”
> - Moved **all** the \ ***.db** files from their orriginal location to the new one “S:\Storj\Databases”
> - Restarted the services and looked at the loog, no errors

---

<div class="post-metadata">

**Author:** ![BrightSilence](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/brightsilence/32/6048_2.png) [@BrightSilence](https://forum.storj.io/u/BrightSilence)\
**Post date:** [January 19, 2023, 1:39am UTC](https://forum.storj.io/t/cloned-hdd-os-to-ssd-which-contained-db-files-what-to-look-for-in-logs/21061/3 "2023-01-19T01:39:19Z")

</div>

Moving DB’s is a process you can easily mess up. Unless you have large amounts of trash regularly or bad success rates, it’s not worth it. Especially because you will also introduce a new failure service to your nodes. If your SSD fails all nodes will initially fail and while you can fix that, you will have lost all historic stats. So yeah, only do this if you’re having issues with your nodes.

---

<div class="post-metadata">

**Author:** ![thelastspark](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/thelastspark/32/1132_2.png) [@thelastspark](https://forum.storj.io/u/thelastspark)\
**Post date:** [January 19, 2023, 2:55am UTC](https://forum.storj.io/t/cloned-hdd-os-to-ssd-which-contained-db-files-what-to-look-for-in-logs/21061/4 "2023-01-19T02:55:54Z")

</div>

I’m trying to run [Success rate script - Now updated for new delete terminology since v1.29.3](https://forum.storj.io/t/success-rate-script-now-updated-for-new-delete-terminology-since-v1-29-3/5114) tool to get the success rates but it’s just not completing. It’s consuming all my ram (I have 32gb) and just churning. My log files are 3.5 and 7gb respectively. I can’t even complete the 3.5gb one. Is there another tool or anything I can do to speed it up?

---

<div class="post-metadata">

**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\
**Post date:** [January 19, 2023, 3:47am UTC](https://forum.storj.io/t/cloned-hdd-os-to-ssd-which-contained-db-files-what-to-look-for-in-logs/21061/5 "2023-01-19T03:47:55Z")

</div>

You need to stop your node and rename the log file (or archive it and remove the source) and start the node back, wait for several hours to have stats and run this script.

---

<div class="post-metadata">

**Author:** ![Stob](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/stob/32/1137_2.png) [@Stob](https://forum.storj.io/u/Stob)\
**Post date:** [January 19, 2023, 7:35am UTC](https://forum.storj.io/t/cloned-hdd-os-to-ssd-which-contained-db-files-what-to-look-for-in-logs/21061/6 "2023-01-19T07:35:16Z")

</div>

My edited version of the powershell success rate script does not max out the RAM and is much quicker for large logs - [Success rate script - Now updated for new delete terminology since v1.29.3 - #81 by Stob](https://forum.storj.io/t/success-rate-script-now-updated-for-new-delete-terminology-since-v1-29-3/5114/81)

---

<div class="post-metadata">

**Author:** ![thelastspark](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/thelastspark/32/1132_2.png) [@thelastspark](https://forum.storj.io/u/thelastspark)\
**Post date:** [January 19, 2023, 6:17pm UTC](https://forum.storj.io/t/cloned-hdd-os-to-ssd-which-contained-db-files-what-to-look-for-in-logs/21061/7 "2023-01-19T18:17:56Z")

</div>

Thanks, I’ll give it a shot after…maybe. Problem is, running the original script on a 32gb, i7 (doesn’t matter much since it seems to be single-threaded) is taking well over 12 hours now. I started it at ~11pm, at 7:30am it was still going. I have taken the machine to work and it’s running in the background. Now it is 1:16pm and still going strong lol.

It is currently on repair downloads. At this rate, it would take it days to process my 7gb file.

I have copied the files over so they are not being touched by the nodes.

---

<div class="post-metadata">

**Author:** ![Stob](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/stob/32/1137_2.png) [@Stob](https://forum.storj.io/u/Stob)\
**Post date:** [January 19, 2023, 7:42pm UTC](https://forum.storj.io/t/cloned-hdd-os-to-ssd-which-contained-db-files-what-to-look-for-in-logs/21061/8 "2023-01-19T19:42:12Z")

</div>

I would say don’t persevere with the original script on a large log file. There’s just no need!

For you, I just ran a 1.44GB log from last month through my script and it came back after 6 minutes and 42 seconds…

 ![image](https://storj-s3.bcdn.literatehosting.net/original/2X/4/4c08f460ce2d299d136693096294657c4bd8333d.png)

By comparison the original script running on the same log file on the same machine (Ryzen 3, 30GB, SSD storing the logs) 5 hours and 38 minutes!..

 ![image](https://storj-s3.bcdn.literatehosting.net/original/2X/b/bf6324145924133a77b41545ce6578dfb7051d5e.png)

…this was where the RAM filled and the pagefile access started on my HDD:  
 ![image](https://storj-s3.bcdn.literatehosting.net/original/2X/3/340075322661a81ff1d93b4d91df3c0ebf20eea9.png)

---

<div class="post-metadata">

**Author:** ![thelastspark](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/thelastspark/32/1132_2.png) [@thelastspark](https://forum.storj.io/u/thelastspark)\
**Post date:** [January 19, 2023, 9:08pm UTC](https://forum.storj.io/t/cloned-hdd-os-to-ssd-which-contained-db-files-what-to-look-for-in-logs/21061/9 "2023-01-19T21:08:40Z")

</div>

Okay wow, yea that was much faster, they both finished within the hour:

 ![image](https://storj-s3.bcdn.literatehosting.net/original/2X/f/fbce3945568dbdda7c9975508f691d6804f4e69a.jpeg)  
At that point it’s not 10-30% faster, it’s like 10-30x faster lol.

I’ll keep this thread open for a bit longer in case any errors do show up in my logs though

---

<div class="post-metadata">

**Author:** ![thelastspark](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/thelastspark/32/1132_2.png) [@thelastspark](https://forum.storj.io/u/thelastspark)\
**Post date:** [January 20, 2023, 4:58pm UTC](https://forum.storj.io/t/cloned-hdd-os-to-ssd-which-contained-db-files-what-to-look-for-in-logs/21061/10 "2023-01-20T16:58:56Z")

</div>

```auto
2023-01-16T09:05:47.327-0500	ERROR	orders.121RTSDpyNZVcEU84Ticf2L1ntiuUimbWgfATz21tuvgk3vzoA6	failed to settle orders for satellite	{"satellite ID": "121RTSDpyNZVcEU84Ticf2L1ntiuUimbWgfATz21tuvgk3vzoA6", "error": "order: failed to start settlement: rpc: tcp connector failed: rpc: dial tcp: lookup ap1.storj.io: no such host", "errorVerbose": "order: failed to start settlement: rpc: tcp connector failed: rpc: dial tcp: lookup ap1.storj.io: no such host\n\tstorj.io/storj/storagenode/orders.(*Service).settleWindow:254\n\tstorj.io/storj/storagenode/orders.(*Service).SendOrders.func1:205\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:75"}
2023-01-16T09:05:47.327-0500	ERROR	orders.1wFTAgs9DP5RSnCqKV1eLf6N9wtk4EAtmN5DpSxcs8EjT69tGE	failed to settle orders for satellite	{"satellite ID": "1wFTAgs9DP5RSnCqKV1eLf6N9wtk4EAtmN5DpSxcs8EjT69tGE", "error": "order: failed to start settlement: rpc: tcp connector failed: rpc: dial tcp: lookup saltlake.tardigrade.io: no such host", "errorVerbose": "order: failed to start settlement: rpc: tcp connector failed: rpc: dial tcp: lookup saltlake.tardigrade.io: no such host\n\tstorj.io/storj/storagenode/orders.(*Service).settleWindow:254\n\tstorj.io/storj/storagenode/orders.(*Service).SendOrders.func1:205\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:75"}
2023-01-16T09:05:47.328-0500	ERROR	orders.12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S	failed to settle orders for satellite	{"satellite ID": "12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S", "error": "order: failed to start settlement: rpc: tcp connector failed: rpc: dial tcp: lookup us1.storj.io: no such host", "errorVerbose": "order: failed to start settlement: rpc: tcp connector failed: rpc: dial tcp: lookup us1.storj.io: no such host\n\tstorj.io/storj/storagenode/orders.(*Service).settleWindow:254\n\tstorj.io/storj/storagenode/orders.(*Service).SendOrders.func1:205\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:75"}
2023-01-16T09:05:47.344-0500	ERROR	orders.12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs	failed to settle orders for satellite	{"satellite ID": "12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs", "error": "order: failed to start settlement: rpc: tcp connector failed: rpc: dial tcp: lookup eu1.storj.io: no such host", "errorVerbose": "order: failed to start settlement: rpc: tcp connector failed: rpc: dial tcp: lookup eu1.storj.io: no such host\n\tstorj.io/storj/storagenode/orders.(*Service).settleWindow:254\n\tstorj.io/storj/storagenode/orders.(*Service).SendOrders.func1:205\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:75"}

```

These are the only errors of their kind I see so far - should I be concerned?

---

<div class="post-metadata">

**Author:** ![Stob](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/stob/32/1137_2.png) [@Stob](https://forum.storj.io/u/Stob)\
**Post date:** [January 20, 2023, 5:18pm UTC](https://forum.storj.io/t/cloned-hdd-os-to-ssd-which-contained-db-files-what-to-look-for-in-logs/21061/11 "2023-01-20T17:18:48Z")

</div>

This is a while ago, and beyond the order submission time limit.

> [@thelastspark](#):
>
> `dial tcp: lookup ap1.storj.io: no such host`

This suggests you had a DNS resolution problem on the 16th around 9:05am.

Next thing to do is check the Orders folder doesn’t have any files older than today.

---

<div class="post-metadata">

**Author:** ![thelastspark](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/thelastspark/32/1132_2.png) [@thelastspark](https://forum.storj.io/u/thelastspark)\
**Post date:** [January 20, 2023, 8:40pm UTC](https://forum.storj.io/t/cloned-hdd-os-to-ssd-which-contained-db-files-what-to-look-for-in-logs/21061/12 "2023-01-20T20:40:26Z")

</div>

in the `archive` folder or `unsent`?

---

<div class="post-metadata">

**Author:** ![Stob](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/stob/32/1137_2.png) [@Stob](https://forum.storj.io/u/Stob)\
**Post date:** [January 20, 2023, 9:54pm UTC](https://forum.storj.io/t/cloned-hdd-os-to-ssd-which-contained-db-files-what-to-look-for-in-logs/21061/13 "2023-01-20T21:54:57Z")

</div>

Check for anything older than today in the unsent folder.

Files in the archive folder will have already been sent.

---

<div class="post-metadata">

**Author:** ![thelastspark](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/thelastspark/32/1132_2.png) [@thelastspark](https://forum.storj.io/u/thelastspark)\
**Post date:** [January 21, 2023, 3:20am UTC](https://forum.storj.io/t/cloned-hdd-os-to-ssd-which-contained-db-files-what-to-look-for-in-logs/21061/14 "2023-01-21T03:20:00Z")

</div>

In that case, no, there is nothing older than today in the unsent folder. The archive has some from the 13th though

---

<div class="post-metadata">

**Author:** ![BrightSilence](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/brightsilence/32/6048_2.png) [@BrightSilence](https://forum.storj.io/u/BrightSilence)\
**Post date:** [January 21, 2023, 3:48am UTC](https://forum.storj.io/t/cloned-hdd-os-to-ssd-which-contained-db-files-what-to-look-for-in-logs/21061/15 "2023-01-21T03:48:48Z")

</div>

Looks like download success rates are a little low. You may see some, but limited improvements from moving db’s to SSD. Just be sure to follow the steps carefully and don’t mess it up. It’s not worth losing your nodes over. We’re talking probably at best a 2-5% improvement. But there may even be no noticeable difference.

---

<div class="post-metadata">

**Author:** ![thelastspark](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/thelastspark/32/1132_2.png) [@thelastspark](https://forum.storj.io/u/thelastspark)\
**Post date:** [January 21, 2023, 6:17pm UTC](https://forum.storj.io/t/cloned-hdd-os-to-ssd-which-contained-db-files-what-to-look-for-in-logs/21061/16 "2023-01-21T18:17:34Z")

</div>

Should I be worried about the stress or the extra reads/writes to the ssd significantly wearing it out? I am using a samsung 870 1tb.

And the steps are, shut down node. Copy over files (what files exactly) to desired location on ssd. Change the config file to point there, restart node?

---

<div class="post-metadata">

**Author:** ![BrightSilence](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/brightsilence/32/6048_2.png) [@BrightSilence](https://forum.storj.io/u/BrightSilence)\
**Post date:** [January 21, 2023, 6:54pm UTC](https://forum.storj.io/t/cloned-hdd-os-to-ssd-which-contained-db-files-what-to-look-for-in-logs/21061/17 "2023-01-21T18:54:15Z")

</div>

For just the db files I wouldn’t worry about that. It’d be different if you cached the entire node, which I don’t recommend (I do this myself for some of my nodes, but it’s a do as I say, not as I do situation).

There are instructions here: [How to move DB’s to SSD on Docker](https://forum.storj.io/t/how-to-move-db-s-to-ssd-on-docker/7064)
