Guide to migrating Sherpa apps using backup to a new Qnap NAS

[Kvothe1970]

@OneCDOnly this may be a little self serving from my side but I‘d appreciate guidance on a Best Practice approach with steps to getting Sherpa Apps cleanly migrated to a new NAS with the help of the backups we can create on the existing installation. Would you be up for that?

[OneCDOnly]

Good idea. I should really make a wiki page for this.

How long until you receive your new NAS? That will let me know how long I have to write something up. 😉

[OneCDOnly]

Hi mate, made some good progress on this already.

Something eventually occurred to me: the migration routines I've written so-far don't update any paths within the databases for each application. This will need to be done if the source volume name is different between the old and new NAS.

On your TS-431+, what is the name of the volume your QPKGs are stored in? You can find this by examining the installation path for the Medusa QPKG:

getcfg Medusa Install_Path -f /etc/config/qpkg.conf

The volume name is the bit that usually says CACHEDEV1_DATA, but if you have an older NAS (one configured before storage pools became a thing), it might say MD0_DATA, or HDA_DATA for a single-drive volume.

[Kvothe1970]

good catch!

/share/CACHEDEV1_DATA/.qpkg/Medusa

[OneCDOnly]

Ah, that's great. If your new volume name is the same (quite-likely), and you're putting everything in the same locations, then the transfer should be quite straight-forward. 🤓

[OneCDOnly]

Hi mate, the new wiki page is done, and ready-to-use when you are.
https://github.com/OneCDOnly/sherpa/wiki/Migrating-QPKGs-between-NAS

[Kvothe1970]

That is fantastic! Thank you so much. I'll give it all a go once I have assembled and performed basic setup. I truly appreciate this!

[Kvothe1970]

Rsync is still working but I’m making progress. Will have to check how the NFS mounts on Kodi can be changed / or I might just try to flip the static v4 IPs between the old and the new NAS via my DHCP. This ought to work for this. I‘ll provide feedback / will update the thread once I’m done with the app migration to the new NAS 😊

[Kvothe1970]

Old NAS:

[~] # sherpa backup installed
sherpa v251023-stable
done: actions complete.

• Package actions started @ 3:55:02 PM, ended @ 4:22:18 PM, elapsed = 27m:16s

• These package actions completed OK:
    backup nzbToMedia QPKG in 2 seconds
    backup SABnzbd QPKG in 6 seconds
    backup Medusa QPKG in 27m:06s
    backup SortMyQPKGs QPKG in 5 seconds

• These package actions were skipped (and why):
    backup Entware QPKG in 1 second (unsupported by this QPKG)
    backup IncreaseTimeouts QPKG in 1 second (unsupported by this QPKG)
    backup Par2turbo QPKG in 1 second (unsupported by this QPKG)
    backup sherpa QPKG in 1 second (unsupported by this QPKG)
    backup Unrar QPKG in 1 second (unsupported by this QPKG)

I am in the middle of the migration, just now transferring the archive to the new NAS.

[OneCDOnly]

Looks good. 👍🏽

When the target package scope is installed, there can be packages that don't support the requested action, so they must be skipped.

[Kvothe1970]

Feedback: Backup Restore Behavior in Sherpa

Okay, there seems to be a slight logic gap when having prior backups on the old NAS.
I assume the backup collection script grabbed all backups, not just those created via the backup installed command.

As a result, it tried to restore QPKGs that are no longer installed.

🧩 Execution Log

[dirk@valinor ~]$ curl -skL https://tinyurl.com/deploy-sherpa-archive | sudo bash

> restore backups from archive ... done

[dirk@valinor ~]$ sudo sherpa rebuild all
sherpa v251023-stable
done: actions complete.

• Package actions started @ 5:03:43 PM, ended @ 5:07:53 PM, elapsed = 4m:10s

• These package actions completed OK:
    meta-rebuild Medusa QPKG in 1 second
    meta-rebuild nzbToMedia QPKG in 1 second
    meta-rebuild SABnzbd QPKG in 1 second
    meta-rebuild SortMyQPKGs QPKG in 1 second
    download nzbToMedia QPKG in 1 second
    download Entware QPKG in 1 second
    download Medusa QPKG in 1 second
    download SABnzbd QPKG in 1 second
    download Unrar QPKG in 1 second
    download Par2turbo QPKG in 1 second
    "sign" Entware QPKG in 1 second
    "sign" Par2turbo QPKG in 1 second
    "sign" Unrar QPKG in 1 second
    install Entware QPKG in 12 seconds (v1.03a)
    install Par2turbo QPKG in 6 seconds (v1.2.0)
    install Unrar QPKG in 6 seconds (v7.0.8)
    install 89 auxiliary IPKs in 48 seconds
    install auxiliary PIP in 4 seconds
    "sign" Medusa QPKG in 1 second
    "sign" nzbToMedia QPKG in 1 second
    "sign" SABnzbd QPKG in 1 second
    install Medusa QPKG in 1m:01s (v251023)
    install nzbToMedia QPKG in 8 seconds (v251019)
    install SABnzbd QPKG in 39 seconds (v251024)
    restore nzbToMedia QPKG in 1 second
    restore SABnzbd QPKG in 16 seconds
    restore Medusa QPKG in 53 seconds

• These package actions were skipped (and why):
    ... (removed lines)

    download OMedusa QPKG in 1 second (prohibited package)
    download SortMyQPKGs QPKG in 1 second (incompatible QTS version)
    restore SortMyQPKGs QPKG in 1 second (not installed, try 'rebuild' instead)
    restore OMedusa QPKG in 1 second (not installed, try 'rebuild' instead)

As shown above, it attempted to restore the old OMedusa, which probably shouldn’t happen.

🧾 Current System State

sudo sherpa status
Password:
sherpa v251023-stable
done: actions complete.

QPKG name:    Status:            Last action (result):  QPKG version:  Appl. version:  Location:
  Entware     - enabled, active    unsupported            1.03a          1.03a           /share/CACHEDEV1_DATA/.qpkg/Entware
  Medusa      - enabled, active    restore (OK)           251023         dynamic         /share/CACHEDEV1_DATA/.qpkg/Medusa
  nzbToMedia  - enabled, active    unsupported            251019         dynamic         /share/CACHEDEV1_DATA/.qpkg/nzbToMe>
  Par2turbo   - enabled, active    unsupported            1.2.0          1.2.0           /share/CACHEDEV1_DATA/.qpkg/Par2tur>
  SABnzbd     - enabled, active    restore (OK)           251024         dynamic         /share/CACHEDEV1_DATA/.qpkg/SABnzbd
  sherpa      - enabled, active    start (OK)             250927         250927          /share/CACHEDEV1_DATA/.qpkg/sherpa
  Unrar       - enabled, active    unsupported            7.0.8          7.01 beta 1     /share/CACHEDEV1_DATA/.qpkg/Unrar

✅ Functional Check

Medusa accessible via
http://valinor:7073/home/ → works 👍

SABnzbd on
http://valinor:8800/ → initially failed 👎
Error:
Access denied - Hostname verification failed: https://sabnzbd.org/hostname-check

Fixed by updating the host_whitelist in config.ini (it still had the old hostname).
After restarting SAB → all good 👍

Additional Note: Symlink for nzbToMedia scripts broke again

After the restore, the symlink to the nzbToMedia scripts directory was missing or replaced by a directory. I had to recreate it manually.

[dirk@valinor ~]$ sudo [[ -L /share/Download/nzbToMedia ]] && echo symlink || echo directory
Password:
directory

[dirk@valinor ~]$ sudo ln -s /share/CACHEDEV1_DATA/.qpkg/nzbToMedia/repo-cache/ /share/Download/nzbToMedia
[dirk@valinor ~]$ sudo [[ -L /share/Download/nzbToMedia ]] && echo symlink || echo directory
directory

[dirk@valinor ~]$ mv /share/Download/nzbToMedia /share/Download/nzbToMedia.old
[dirk@valinor ~]$ ln -s /share/CACHEDEV1_DATA/.qpkg/nzbToMedia/repo-cache/ /share/Download/nzbToMedia
[dirk@valinor ~]$ [[ -L /share/Download/nzbToMedia ]] && echo symlink || echo directory
symlink

[dirk@valinor repo-cache]$ sudo rm -r /share/Download/nzbToMedia.old
Password:
[dirk@valinor repo-cache]$

So it looks like the restore process recreated /share/Download/nzbToMedia as a directory instead of a symlink. But I could be completely off here.

After manually removing it and re-creating the symbolic link, everything works fine again.

🧠 Follow-up & Questions

However, on QNAP, I can’t use the admin account (deprecated), so I’m running everything as my own user (in the administrators group with full rights).

Question:
Is there anything specific I need to check regarding permissions or ownerships for this configuration and the Installation we have done?

[OneCDOnly]

As shown above, it attempted to restore the old OMedusa, which probably shouldn’t happen.

But, it's exactly in-line with what should happen. If you request rebuild all, every QPKG backup will be tried, even if it's now prohibited. 😉

There are a couple of ways around this:

1. If you have migrated the QPKG names, the old 'O' backups can be deleted.
2. Or, request only specific QPKG names instead of all.

Fixed by updating the host_whitelist in config.ini (it still had the old hostname).
After restarting SAB → all good 👍

Good pickup. 👍🏽

So it looks like the restore process recreated /share/Download/nzbToMedia as a directory instead of a symlink. But I could be completely off here.

Ah, that's something I'll need to test-for. It does look like a directory instead of a symlink. Your fix is correct. 👍🏽

However, on QNAP, I can’t use the admin account (deprecated), so I’m running everything as my own user (in the administrators group with full rights).

Question:
Is there anything specific I need to check regarding permissions or ownerships for this configuration and the Installation we have done?

Nothing I can think-of. SABnzbd will still be run as admin because that's how QTS does things.

[Kvothe1970]

As shown above, it attempted to restore the old OMedusa, which probably shouldn’t happen.

But, it's exactly in-line with what should happen. If you request rebuild all, every QPKG backup will be tried, even if it's now prohibited. 😉

There are a couple of ways around this:

1. If you have migrated the QPKG names, the old 'O' backups can be deleted.
2. Or, request only specific QPKG names instead of all.

Fair enough. I should have thought of that. It did obviously not cause harm and you are right :)

So it looks like the restore process recreated /share/Download/nzbToMedia as a directory instead of a symlink. But I could be completely off here.

Ah, that's something I'll need to test-for. It does look like a directory instead of a symlink. Your fix is correct. 👍🏽

Question:
Is there anything specific I need to check regarding permissions or ownerships for this configuration and the Installation we have done?

Nothing I can think-of. SABnzbd will still be run as admin because that's how QTS does things.

Thanks for reassuring me. Everything is up and running now and working smoothly as far as I cal tell. Your guide and scripts are invaluable mate.

[Kvothe1970]

Okay, this is odd. Sab cannot write to a mounted external drive, but it works just fine when I write something to it manually via filestation. Any idea?

[dirk@valinor ~]$ mount | grep /share
tmpfs on /share type tmpfs (rw,size=16M)
/dev/mapper/cachedev1 on /share/CACHEDEV1_DATA type ext4 (rw,usrjquota=aquota.user,jqfmt=vfsv1,user_xattr,data=ordered,data_err=abort,delalloc,nopriv,nodiscard,noacl)
tmpfs on /share/NFSv=4 type tmpfs (rw,size=16M)
tmpfs on /share/.quftp_client type tmpfs (rw,size=1m)
/share/CACHEDEV1_DATA/Download on /share/NFSv=4/Download type none (rw,bind)
/share/CACHEDEV1_DATA/MoviesEN on /share/NFSv=4/MoviesEN type none (rw,bind)
/share/CACHEDEV1_DATA/TVShows on /share/NFSv=4/TVShows type none (rw,bind)
/share/CACHEDEV1_DATA/MoviesGER on /share/NFSv=4/MoviesGER type none (rw,bind)
/dev/sde1 on /share/external/DEV3303_1 type ext4 (rw,usrjquota=aquota.user,jqfmt=vfsv1,user_xattr,data=ordered,data_err=abort,delalloc,nopriv,nodiscard,noacl)
[dirk@valinor ~]$ ls -ld /share/external/DEV3303_1
drwxrwxrwx 3 admin administrators 4096 2025-10-24 18:58 /share/external/DEV3303_1/
[dirk@valinor ~]$

This is probably another weird QNAP thing..

So I tried out a few things. Do not hate but I used chatgbt for that one :D

admin@valinor ~]# ps aux | grep sabnzbd
14779 admin       972 S   grep sabnzbd
[admin@valinor ~]# sudo -u admin touch /share/external/DEV3303_1/testfile
[admin@valinor ~]# ps -ef | grep -i sabnzbd
 3986 admin       908 R   grep -i sabnzbd
24487 admin     89380 S   /share/CACHEDEV1_DATA/.qpkg/SABnzbd/venv/bin/python3 /share/CACHEDEV1_DATA/.qpkg/SABnzbd/repo-cache/SABnzbd.py --daemon --browser 0 --config-file /share/CACHEDEV1_DATA/.qpkg/SABnzbd/config/config.ini --pidfile /var/run/SABnzbd.pid
[admin@valinor ~]# mkdir -p /share/external/DEV3303_1/sab/incomplete
[admin@valinor ~]# sudo -u admin touch /share/external/DEV3303_1/sab/incomplete/.writetest
[admin@valinor ~]#

And I set the path for test purposes specifically to /share/external/DEV3303_1/sab/incomplete
and that works. 👍

But I guess this how Qnap mounts the external drives in a "user friendly" manner that works fine in Filestation etc. which will not work for non Qnap qpkgs

[OneCDOnly]

Yup, external drive mounts can be a pain. QTS doesn't deterministically mount them unless you give each one a label. Then they are mounted with the label name instead of DEVxxxx_x.

Also, be-careful using external drives for your incomplete path, I recall seeing something from the SABnzbd folks warning against this. Not sure of the reason though.

[Kvothe1970]

Yup, external drive mounts can be a pain. QTS doesn't deterministically mount them unless you give each one a label. Then they are mounted with the label name instead of DEVxxxx_x.

Also, be-careful using external drives for your incomplete path, I recall seeing something from the SABnzbd folks warning against this. Not sure of the reason though.

Oh I switched back to the HDD RAID. the read / write speed difference on the new NAS alone is crazy, It was however mich faster on the old NAS and of course, did not put as much strain on the HDDs. It was also fun to just tune all the parameters in sab on this device and watch it fly during downloads 🚀

[OneCDOnly]

@Kvothe1970 appreciate your feedback, some things for me to fix there.

Cheers!

[Kvothe1970]

@Kvothe1970 appreciate your feedback, some things for me to fix there.

Cheers!

Thank you for creating the guide and all your help throughout the years @OneCDOnly I truly appreciate it! I saw you have already added some pointers to the guide in particular for hardcoded hostnames / IPs in the config files of the applications from the old NAS. Excellent work, as always.