Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IDrive can no longer browse volume after move #132

Open
jradwan opened this issue Oct 20, 2024 · 11 comments
Open

IDrive can no longer browse volume after move #132

jradwan opened this issue Oct 20, 2024 · 11 comments

Comments

@jradwan
Copy link

jradwan commented Oct 20, 2024

I know IDrive is listed as "not tested" but I see a few other folks here have IDrive installed on the Syno.

My move from volume1 to volume2 for IDrive was successful (along with Web Station and PHP 8.0) and the package is running normally.

admin@DiskStation:/volume2/jcr_scripts/Synology_app_mover-4.0.73$ sudo -s ./syno_app_mover.sh
Synology_app_mover v4.0.73
DS720+ DSM 7.2.2-72806

Running from: /volume2/jcr_scripts/Synology_app_mover-4.0.73/syno_app_mover.sh

1) Move
2) Backup
3) Restore
Select the mode: 1
You selected Move

[Installed package list]
1) /volume1  Cloud Sync           6) /volume1  PHP 8.0
2) /volume1  Container Manager    7) /volume1  Plex Media Server
3) /volume1  Hyper Backup         8) /volume2  Storage Analyzer
4) /volume1  IDrive               9) /volume2  Text Editor
5) /volume1  PHP 7.4             10) /volume2  Web Station
Select the package to move: 4
You selected IDrive in /volume1

Destination volume is /volume2

Checking size of IDrive
Size of selected app(s) is 1 GB

Ready to Move IDrive to /volume2? [y/n]
y

Moving /volume1/@appconf/IDrive to /volume2
Moving /volume1/@appdata/IDrive to /volume2
Moving /volume1/@apphome/IDrive to /volume2
Moving /volume1/@appshare/IDrive to /volume2
Moving /volume1/@appstore/IDrive to /volume2
Moving /volume1/@apptemp/IDrive to /volume2

Finished moving IDrive

Duration: 54 seconds

All my settings seem to have been preserved but all of my backup sets show "empty" with no paths in them. And if I try to
browse the shared folders on the Backup tab, they all come back with "no files." Not sure if this is a permissions thing or something else:

image

Has anyone else moved IDrive with this script and had a similar problem?

@jradwan
Copy link
Author

jradwan commented Oct 21, 2024

I'm thinking moving IDrive is a bad idea. I haven't gotten the migrated package to work properly yet, but I've realized that my backup sets have the old paths (/volume1/blah) in them so if I do get the app working, it will see /volume2/blah as a completely new folder that needs to be backed up and I'll have to re-upload multiple terrabytes. 😞

Fellow IDrive users ... how have you approached this?

Sorry for using an issue as a forum thread.

@007revad
Copy link
Owner

I installed iDrive yesterday but then remembered I'd need an iDrive account to be able to test it.

Looking in the iDrive package there are no config files that reference where it's database is located. But one of them does mention sqlite so there's a database somewhere.

Where are your backup sets located? Is there as /volume1/iDrive folder?

@jradwan
Copy link
Author

jradwan commented Oct 22, 2024

There's no separate IDrive folder that I can find. The DB containing the settings/backup sets, etc. must all be somewhere in the package folders.

As my continuining btrfs file system conversion, I moved everything back to a new storage pool on /volume1, thinking that would fix the issue with my IDrive paths not matching. However, the app itself is still "broken" (I even tried restoring the backup of the settings I had made with this script from before I originally moved it to /volume2).

I'm thinking at this point I'll just need to remove and re-install the package and set up my backup sets again and see what happens.

@jradwan
Copy link
Author

jradwan commented Oct 22, 2024

I've ended up removing the IDrive package and re-installing. I'm going to set up all my backup sets again and hopefully they will work without needing to re-upload.

One strange thing I noticed: after removing the IDrive package, I poked around in the various /volume1/@**** folders and found IDrive components under /volume1/appstore so I had leftover folders like:

  • /volume1/@appstore/app
  • /volume1/@appstore/etc
  • /volume1/@appstore/ui
  • /volume1/@appstore/IDrive.ini
  • /volume1/@appstore/www.IDrive.conf

With the re-installed package, those are under /volume1/@appstore/IDrive where they belong. Not sure if that was caused by the move script or not.

@007revad
Copy link
Owner

Are you saying there were files and folders in the @appstore folder that should have been in @appstore/IDrive?

@jradwan
Copy link
Author

jradwan commented Oct 31, 2024

Yes.

@007revad
Copy link
Owner

007revad commented Nov 4, 2024

Those 4 folders and the IDrive.ini file should be in /volume1/@appstore/IDrive

Did you use the script to backup IDrive and later use the script to restore IDrive, while it was installed on volume 1?

@jradwan
Copy link
Author

jradwan commented Nov 4, 2024

Yes. I had made a backup before attempting to move IDrive to /volume2. When that didn't work, I moved it back to /volume1, which still didn't fix the app, so I tried restoring the backup, which also didn't fix the problem. That's why I ended up removing the app completely and starting over from scratch and that's when I found the "leftover" items under /volume1.

@007revad
Copy link
Owner

007revad commented Nov 4, 2024

To delete the leftover folders and files:

sudo rm -rf /volume1/@appstore/app
sudo rm -rf /volume1/@appstore/etc
sudo rm -rf /volume1/@appstore/ui
sudo rm /volume1/@appstore/IDrive.ini
sudo rm /volume1/@appstore/www.IDrive.conf

@jradwan
Copy link
Author

jradwan commented Nov 4, 2024

I did that back after I re-installed the app, yeah.

I'm still not sure why IDrive got messed up during the migration, but they're probably doing something different internally than other Syno apps. I was hoping I could get this to work so you could update it as "tested" for this, but it looks like that can't be the case. Thanks for your help!

@007revad
Copy link
Owner

007revad commented Nov 5, 2024

It could be a bug in the Restore mode of the script. I'll run some tests and see if I can reproduce the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants