-
-
Notifications
You must be signed in to change notification settings - Fork 29
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
Comments
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. |
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? |
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. |
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:
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. |
Are you saying there were files and folders in the |
Yes. |
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? |
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. |
To delete the leftover folders and files:
|
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! |
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. |
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.
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:
Has anyone else moved IDrive with this script and had a similar problem?
The text was updated successfully, but these errors were encountered: