Move files from array to cache

[Allesanddro]

Hello, 
I've been trying to find a way to "recache" files again but I couldn't really find anything about it.
 

Basically I have lancache running in a VM before I had Unraid and im to "newbie" to migrate my current instance to the docker version from the app"store" so I just implemented my existing VM in Unraid, the issue is that the mover moved the files to the array and now I've been getting really slow performance because my parity drive is a HDD (yes reconstruct write is enabled). 
If ya need more Information let me now thanks in advance.

Edited January 8, 2023 by Allesanddro

[MAM59]

The settings look ok to me, but your problem ist supposely that the vm is running all the time, so mover wont touch her.

Stop VM Manager, start Mover and look into the protocol. It then should move over the VM files so the next time you restart the VM, it will run off cache.

Update: do the same for Dockers too. Stop Dockers, set share to prefer, run Mover, start Dockers

 

And optionally: once the files have been moved, change "prefer" to "only". This will ensure that corresponding files never are created offside of cachedrive

Edited January 8, 2023 by MAM59

[trurl]

1 hour ago, Allesanddro said:

more Information

attach diagnostics to your NEXT post in this thread

[Allesanddro]

tower-diagnostics-20230108-1941.zip

 

15 minutes ago, MAM59 said:

The settings look ok to me, but your problem ist supposely that the vm is running all the time, so mover wont touch her.

Stop VM Manager, start Mover and look into the protocol. It then should move over the VM files so the next time you restart the VM, it will run off cache.

Update: do the same for Dockers too. Stop Dockers, set share to prefer, run Mover, start Dockers

 

And optionally: once the files have been moved, change "prefer" to "only". This will ensure that corresponding files never are created offside of cachedrive

will try

 

 

 

 

[trurl]

Your screenshot above is missing a crucial detail. What is the name of that user share?

 

Your appdata, domains, system shares all have files on the array. Ideally, these shares would all be on fast pool (cache) so Docker/VM performance isn't impacted by slower array, and so array disks can spin down since these files are always open.

 

Set appdata, domains, system shares to cache:prefer so these can be moved to cache.

 

Nothing can move open files, so you will have to go to Settings and disable Docker and VM Manager before these can be moved.

 

Then run Mover.

 

When mover completes, post new diagnostics.

 

Why is your docker.img so large?

[Allesanddro]

So this would be the correct config?
 

 

 

 

tower-diagnostics-20230108-2004.zip

Edited January 8, 2023 by Allesanddro

[trurl]

That is the correct settings for those shares, but doesn't look like you have actually done anything about moving them yet.

 

Any idea what these are about?

 

Jan  8 11:04:13 Tower  sshd[13330]: Failed password for invalid user telecomadmin from 152.89.198.211 port 10797 ssh2
Jan  8 11:04:13 Tower  sshd[13330]: Received disconnect from 152.89.198.211 port 10797:11: Client disconnecting normally [preauth]
Jan  8 11:04:13 Tower  sshd[13330]: Disconnected from invalid user telecomadmin 152.89.198.211 port 10797 [preauth]

 

https://www.abuseipdb.com/check/152.89.198.211

 

Have you put your server on the internet?

[Allesanddro]

Now its working, I wanted to hear back before I do anything and yes it is exposed but with a strong enough password secured 

[trurl]

2 minutes ago, Allesanddro said:

yes it is exposed but with a strong enough password secured

Don't do this!!!

 

Wireguard VPN is builtin to Unraid, and My Servers plugin will also allow you to access webUI remotely.

[trurl]

Post new diagnostics after you run mover

[Allesanddro]

tower-diagnostics-20230108-2104.zip

[trurl]

appdata still has files on disk1. Mover won't replace files, so these are probably duplicates.

 

What do you get from command line with this?

ls -lah /mnt/cache/appdata

and this?

ls -lah /mnt/disk1/appdata

 

[trurl]

Jan  8 09:05:18 Tower  sshd[10437]: Connection from 177.249.43.250 port 28776 on 192.168.188.35 port 22 rdomain ""
Jan  8 09:05:18 Tower  sshd[10463]: Connection from 177.249.43.250 port 40493 on 192.168.188.35 port 22 rdomain ""
Jan  8 09:05:44 Tower  sshd[11429]: Connection from 177.249.43.250 port 61677 on 192.168.188.35 port 22 rdomain ""
Jan  8 09:05:49 Tower  sshd[11472]: Connection from 177.249.43.250 port 40261 on 192.168.188.35 port 22 rdomain ""
Jan  8 09:06:16 Tower  sshd[11983]: Connection from 177.249.43.250 port 21986 on 192.168.188.35 port 22 rdomain ""
Jan  8 09:06:21 Tower  sshd[12167]: Connection from 177.249.43.250 port 41884 on 192.168.188.35 port 22 rdomain ""
Jan  8 09:06:25 Tower  sshd[12305]: Connection from 177.249.43.250 port 36204 on 192.168.188.35 port 22 rdomain ""
Jan  8 09:06:30 Tower  sshd[12518]: Connection from 177.249.43.250 port 30418 on 192.168.188.35 port 22 rdomain ""
Jan  8 09:06:49 Tower  sshd[13425]: Connection from 177.249.43.250 port 7815 on 192.168.188.35 port 22 rdomain ""
Jan  8 09:06:53 Tower  sshd[13579]: Connection from 177.249.43.250 port 27394 on 192.168.188.35 port 22 rdomain ""
Jan  8 09:06:58 Tower  sshd[13743]: Connection from 177.249.43.250 port 30672 on 192.168.188.35 port 22 rdomain ""
Jan  8 09:19:00 Tower  sshd[23380]: Connection from 152.89.198.211 port 4625 on 192.168.188.35 port 22 rdomain ""
Jan  8 09:53:40 Tower  sshd[28480]: Connection from 152.89.198.211 port 44439 on 192.168.188.35 port 22 rdomain ""
Jan  8 10:29:11 Tower  sshd[5964]: Connection from 152.89.198.211 port 26488 on 192.168.188.35 port 22 rdomain ""
Jan  8 10:54:38 Tower  sshd[23553]: Connection from 167.94.145.59 port 37924 on 192.168.188.35 port 22 rdomain ""
Jan  8 11:37:58 Tower  sshd[22629]: Connection from 152.89.198.211 port 54618 on 192.168.188.35 port 22 rdomain ""

Notice how quickly and often this is being logged? These are bots. The internet is full of bots, and they will continually and relentlessly and automatically try to get into your server.

 

https://www.abuseipdb.com/check/177.249.43.250   Mexico

https://www.abuseipdb.com/check/152.89.198.211   Russia

https://www.abuseipdb.com/check/167.94.145.59   USA

 

 

 

 

 

[Allesanddro]

they were deleted them on disk1

[Allesanddro]

I know I have ~4k logins daily ^^ 

planned anyway to use fail2ban

https://www.abuseipdb.com/user/13641

Edited January 8, 2023 by Allesanddro

[trurl]

https://wiki.unraid.net/Manual/Security

 

 

[Allesanddro]

Well only ssh is exposed web is done via reverse proxy on a different host in the network

[trurl]

1 minute ago, Allesanddro said:

only ssh is exposed

That is the worst thing you could expose

[trurl]

I use Wireguard builtin to my Unraid server to remotely access everything on my LAN.

[Allesanddro]

7 minutes ago, trurl said:

That is the worst thing you could expose

will never get bruteforced ^^

[trurl]

Don't be surprised if this comes up again when someone looks at your syslog

[Allesanddro]

its a 16 digit 
i would actually disable root login and just use ssh keys like i do for everything else but unraid sadly needs root login to be enabled

[Allesanddro]

3 minutes ago, trurl said:

Don't be surprised if this comes up again when someone looks at your syslog

ye all good 

but thanks for helping with the cache issue 

Edited January 8, 2023 by Allesanddro

[JonathanM]

4 hours ago, Allesanddro said:

Well only ssh is exposed web is done via reverse proxy on a different host in the network

The failed attempts will eventually cripple your server by filling up the /var/log mount. You have been warned.

[trurl]

Just now, JonathanM said:

The failed attempts will eventually crash your server by filling up RAM. You have been warned.

Will it fill rootfs? Or will it just fill /var/log?