February 25, 20233 yr The Problem Postgresql reports missing folders when attempting to start the service after replacing a bad cache drive. What I had running: 2 NMVe SSD drives, each 1TB, configured as a cache pool. /appdata, /Databases, /Documents, /system, and /isos were all set to Prefer Cache. I'm running various docker containers, one of which is postgresql14. The database directory for postgresql is set to /mnt/cache/appdata/postgresql14 What happened: One of my cache drives failed. When that happened, I set all of the above shares to Yes:Cache, disabled all of the dockers and running vm, and ran a manual move to get all of the data moved to the array...it took a loooooong time, unfortunately. I also removed that drive from the cache pool. Here's where I think I screwed up, but correct me if I'm wrong. Before re-starting those containers and vm, I didn't set the cache preference for those shares to No. I left them at Yes:Cache. At that point, I was waiting for a replacement drive, but needed the system up and running. So now I see files split between the cache and disk(whatever) for the cache share. Again, not sure if this is actually an issue. What I did next: When I received the replacement drive, I shut down the system, put the drive in, rebooted, stopped the array, assigned the new drive to the cache pool, fired up the array, and all seemed well until I noticed that Zoneminder was down. Zoneminder uses postgresql14. I also noticed that postgresql14 was down. When I attempted to start it, I found that it was unable to locate the pg_notify folder. Incidentally, the pg_notify folder is actually on the system but it's not in the /mnt/cache/appdata/postgresql14 path. It's in /mnt/user/appdata/postgresl14 path. As an experiment: I created a temporary folder so I could first sync what was in /mnt/cache/appdata/postgresql14 to the temp folder. Then I used rsync to sync the contents of /mnt/user/appdata/postgresql14 to the existing /mnt/cache/appdata/postgresql14 folder. I started postgresql and Zoneminder and they both seem to be working. Final Question: How could I have avoided this experience and thus risky maneuver?
February 25, 20233 yr 53 minutes ago, arretx said: How could I have avoided this experience and thus risky maneuver? By referencing the appdata path as /mnt/user/appdata instead of /mnt/cache/appdata Then it would follow where ever the files happen to be placed. 55 minutes ago, arretx said: and ran a manual move to get all of the data moved to the array...it took a loooooong time, mover (and for that matter all filesystems ever created) are very inefficient at creating and moving around tons and tons of small files. If you're ever in the situation again where effectively you're doing a backup of appdata and then restoring it you're better off using the appdata backup plugin. Probably about 100 times faster in handling a backup and restore than doing two mover operations
February 26, 20233 yr Author 8 hours ago, Squid said: By referencing the appdata path as /mnt/user/appdata instead of /mnt/cache/appdata Help me out here. Not sure where this would have occurred. Are you referring to the data path configured in the docker container?
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.