Immich Guide to moving Old Storage Configuration (Deprecated) datasets to new single Uploads datatset

Apps and Virtualization
1

Hello Immich chaps and chapettes,

In the hope that this may help others move the datasets from the original 7 required (Backups, Videos, Library, Profile, Thumbs, Uploads, PGData and MLData), to the new 3 datasets suggested by the latest Immich app (Userdata, PGData and MLData).

After following the steps below, you will end up with 3 data
The steps to follow are as below.

1 - Stop Immich app
2 - Create new Userdata Dataset with the same ACL permissions of the current datasets.
3 - Copy all the lines from my example below and replace the paths with yours as required.
4 - Open Shell and take control as Sudo and paste each line below separately to ensure no errors occur.
5 - As you can see below, we are leaving the PGData and MLData be and outside of the Userdata dataset.

rsync -avh --progress /mnt/SSD-Storage/App_Config/Immich/backup/ /mnt/SSD-Storage/App_Config/Immich/userdata/backups
rsync -avh --progress /mnt/SSD-Storage/App_Config/Immich/videos/ /mnt/SSD-Storage/App_Config/Immich/userdata/encoded-video
rsync -avh --progress /mnt/SSD-Storage/App_Config/Immich/library/ /mnt/SSD-Storage/App_Config/Immich/userdata/library
rsync -avh --progress /mnt/SSD-Storage/App_Config/Immich/profile/ /mnt/SSD-Storage/App_Config/Immich/userdata/profile
rsync -avh --progress /mnt/SSD-Storage/App_Config/Immich/thumbs/ /mnt/SSD-Storage/App_Config/Immich/userdata/thumbs
rsync -avh --progress /mnt/SSD-Storage/App_Config/Immich/uploads/ /mnt/SSD-Storage/App_Config/Immich/userdata/upload

6 - When you have finished Rsyncing the datasets above into the new Userdata dataset, go to edit the app and deselect the Old Storage Configuration, and select the new Data Storage Host path to the new Userdata dataset.
7 - Leave the PGData and ML data unchanged. You want these to be outside of the Userdata dataset.
8 - Update and start Immich app. It should successfully start if none of the new folder name were changed. If Immich keeps restarting, view the Server logs and find out what folder is it complaining about and ensure that the rsync command for that is creating the same folder.

When this is all done and Immich has successfully started, you are welcome to delete the old Datasets. My advice is to keep them for a while and ensure that there are no issues with the new structure and delete when safe.

This is my new Storage config in case it helps with visualising the change.

image
image1434×1169 46.2 KB

If for some reason you can not start the Immich app, you can always move back to the old storage configuration while troubleshooting the issue.

Hope this helps.

13 Likes
Trouble updating immich (1.123 to 1.137)
Tried to Update Immich and I get an error
Immich major version upgrade alarm
2

Hi ic2_Alpha,
first of all thx for the information. Amazing. In my case, I don’t have Backups, Videos, Library, Profile, Thumbs, Uploads … All Immich data is under one dataset. How do I proceed in this scenario?

3

This was very helpful,
thank you for the detailed explanation.

4

This is an awesome guide. I was wondering, since they are ZFS datasets. Would it be possible to do a ZFS replication? I would think this would make the migration times way faster because its being done at a block level

5

Hi ic2_Alpha,

I am having major problems upgrading. Cannot get to Immich web on latest version or rolling back to previously working version and attempting to switch back to old storage configuration. I believe I followed all the steps in your tutorial correctly, however after changing everything over and upgrading the server container remained in a “boot-loop”, I checked the logs and it says

`Starting microservices worker

[Nest] 7 - 10/01/2025, 11:35:59 PM LOG [Microservices:EventRepository] Initialized websocket server
[Nest] 7 - 10/01/2025, 11:35:59 PM LOG [Microservices:DatabaseRepository] targetLists=1, current=1 for clip_index of 41288 rows
[Nest] 7 - 10/01/2025, 11:35:59 PM LOG [Microservices:DatabaseRepository] targetLists=1, current=1 for face_index of 28905 rows
[Nest] 7 - 10/01/2025, 11:35:59 PM WARN [Microservices:DatabaseRepository] Migration “1744910873969-InitialMigration” failed
[Nest] 7 - 10/01/2025, 11:35:59 PM ERROR [Microservices:DatabaseRepository] Migrations failed: Error: Invalid upgrade path.
For more information, see: https ://immich.app/errors#typeorm-upgrade

Error: Invalid upgrade path
at Object.up (/usr/src/app/server/dist/schema/migrations/1744910873969-InitialMigration.js:19:19)
at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
at async #migrateUp (…/node_modules/kysely/dist/cjs/migration/migrator.js:557:17)
at async run (…/node_modules/kysely/dist/cjs/migration/migrator.js:421:28)
at async …/kysely.js:569:32
at async DefaultConnectionProvider.provideConnection (…/default-connection-provider.js:12:20)
at async migrate (…/migrator.js:268:20)
at async DatabaseRepository.runMigrations (…/database.repository.js:325:36)
at async …/database.service.js:110:17
at async …/database.repository.js:379:27

microservices worker exited with code 1
Killing api process
`

I believe this means that I am skipping too many versions between updates like for example if you were going from v1.100.0, however that is not the case I am attempting to upgrade from v1.142.1 to v1.143.1. The error message links me to https ://docs.immich.app/errors/#typeorm-upgrade, which seems wrong since it is referencing upgrading to v1.137.0 and above, meanwhile I was already above that version prior to updating. Yet, I still thought to give it a try, so I rolled back to v1.135.3 to see if it would help, with no success. Anyway, I am really at a loss for what to do or try, so any help from anyone would be appreciated.

Thanks!

6

I had the same issue, for me it helped to go into “edit” then change the “Data Storage (aka Upload Location)” dataset and add ACL with ID 568 and “Modification Access”.
After this everything started up as normal.

Hope it helps

7

so… not to sound negative BUT, how is this a good thing? How can I separate my deep storage (HDD) and blazing fast thumbs (Nvme) ?

8

Splitting these is still possible, but I can only suggest it to be done via docker compose. I moved my Immich instance away from ix apps to my own docker compose file to follow the Immich project using their suggested deployment just after I posted this migration post.

1 Like
9

Hi,

I did the update but i have this message now. Why that ?

1
12854×1566 29.8 KB

EDIT : now it’s work :wink:

10

so it looks like they decided to stay with the multipe dataset option - which is good news -

TrueNAS [Community] | Immich

1 Like
11

Thanks for this post! I’ve been waiting for this to magically fix itself, and it didn’t.

I’ve had a bunch of performance issues with rsync when trying to multi-thread for SSDs, so I updated your commands to use rclone instead:

rclone copy --progress --transfers 4 /mnt/<POOL_NAME>/Immich/backups/ /mnt/<POOL_NAME>/Immich/userdata/backups

rclone copy --progress --transfers 4 /mnt/<POOL_NAME>/Immich/library/ /mnt/<POOL_NAME>/Immich/userdata/library

rclone copy --progress --transfers 4 /mnt/<POOL_NAME>/Immich/profile/ /mnt/<POOL_NAME>/Immich/userdata/profile

rclone copy --progress --transfers 4 /mnt/<POOL_NAME>/Immich/thumbs/ /mnt/<POOL_NAME>/Immich/userdata/thumbs

rclone copy --progress --transfers 4 /mnt/<POOL_NAME>/Immich/upload/ /mnt/<POOL_NAME>/Immich/userdata/upload

rclone copy --progress --transfers 4 /mnt/<POOL_NAME>/Immich/video/ /mnt/<POOL_NAME>/Immich/userdata/encoded-video

Some of my directories were named differently to yours, so I changed them here too and simplified it to make modifications easier.

Change the thread count to whatever works for your system. I set it here as 4, but I used 16 threads on my system and got some pretty decent transfer speeds considering how small these files are:

image
image1592×813 119 KB

12

Hi everyone,
I could go through the above transition smoothly with rsync and it has been running fine since couple of weeks now. I wanted to delete the old storage (which is in /mnt/.ix-apps/app_mounts but I am getting Device or resource busy when trying with rm -r. What is a correct way to remove the old app folders?
Thanks!

13

I mean, I removed them at the ZFS dataset level. Not sure how else to do it. Also not sure what app_mounts/ correlates to.

14

thats the TrueNas internal Apps Storage Path if you not decide to configure a dedicated host path

15

Hi everyone, I solved my problem and reporting here for future reference. The issue may have been caused by the existence of snapshots on the old path. This aspect isn’t mentioned in the various guides, posts and instructions I found online. The solution was to delete the datasets and it has to be done via command line, since ix-apps isn’t shown in TNS GUI. So, sudo zfs destroy -r <complete name of the dataset>. This will destroy dataset and it’s snapshots.

16

So the issue you had with destroying those datasets got me recently too.

When you back up or set up a TrueNAS Apps dataset, it has them all set to a specific mountpoint that’s not the default. Because of this, you have to first unmount them if you can, and then you can destroy the dataset.

In my case, I changed the ZFS config to remove the mountpoint, and then I think I was able to remove them.

17

I just want to say that the IMMICH App Team for TrueNAS App handled this with extreme immaturity and amaterism. I am appaled at how bad they handeled this >> completley arbitrary and unnecesary change, breaking working installations and risking widespread data corruption.

Who is even maintaing this App? I think we might need someone to replace tham, as they are doing the worst job imaginable…

1 Like
18

smart

19

Always room for improvement, but at the end of the day, they see it as “you are responsible for your data” which is a valid outlook for a company that can’t handle every bug report or feature request like an enthusiastic GitHub self-hosted app developer that engages intimately with their community for those kinds of feedback.

This guide worked great for me and even though I used TrueNAS’s “immature” implementation of the immich upgrade, I was able to use a snapshot to rollback, and then use this guide to fully transition to the new storage system.

Also keep in mind that anyone can contribute to the apps catalog. It’s just tricky for people like me to understand, otherwise I would contribute! Maybe people like @ic2_Alpha would too with this type of guide they made, if the apps catalog framework was more easier to navigate.

Anyways, hope you’re able to sort your issues. I know it’s not convenient at times indeed. Take your time.

20

Here’s what I did. maybe someone witll find it usefull. no RSYNC needed.

Add ADITIONAL STORADGE for your storadge datasets that you used to have

01 |
First, create a ‘dummy’ datasetthat the new App asks for . I called it

ZFS/Immich/DataDIR_Placeholder

Link it as the new ‘library’

02 |

Now, relink your old datasets, followint this criteria

Additional Storage ::::

where
Mount Path is the following paths I will give you
and Host Path are your old dataset paths that you used before

Immich Library Storage
Mount Path >>>>> /data/library
Host Path >>>>> ZFS/Immich/Library **YOUR OLD PATH

Immich Uploads Storage
Mount Path >>>>> /data/upload
Host Path >>>>> ZFS/Immich/Uploads **YOUR OLD PATH

Immich Thumbs Storage
Mount Path >>>>> /data/thumbs
Host Path >>>>> ZFS/Immich/Thumbs **YOUR OLD PATH

Immich Profile Storage
Mount Path >>>>> /data/profile
Host Path >>>>> ZFS/Immich/Profile **YOUR OLD PATH

Immich Video Storage
Mount Path >>>>> /data/encoded-video
Host Path >>>>> /Immich/Video **YOUR OLD PATH

Immich Backups Storage
Mount Path >>>>> /data/backups
Host Path >>>>> /Immich/Backups **YOUR OLD PATH

i’ll let you know if any issues arise