Sign in to follow this  
multra

Fresh start?

Recommended Posts

I am trying to re-do synced folder between two NASes.

So far I tried:

  • removed shared folder on both ends
  • deleted .sync folder on both ends
  • added the folder on the source NAS and let it index

when adding this folder on the destination NAS by means of of shared key, the folder indexes multiple TBs in a span of a few minutes! sadly incorrectly also because the sizes do not match on source and destination. Where on earth is it getting this "cached" indexed info? I need to delete it! The idea to start fresh.

Thanks,

Share this post


Link to post
Share on other sites

Thanks for your response.

 

I have not removed the app no. The reason is because i have other shared (standard) folders that are syncing OK.

The destination (troubled) NAS is a Synology DS1511+ with ResilioSync package 2.6.3.1 installed (as per Resilio instructions)

The source is actually an Ubuntu server with ResilioSync installed and NAS mounted with CIFs.

By the way, I found this and this article describing where the .db files reside. It is not clear how to cross-reference a .db to a shared folder so I tried logically deriving the connection using last-modified. Long story short, removing a .db file did not do anything for me.

I am OK with starting completely fresh if that's what is required but I need help making sure I leave no traces of old install, database, config files.

Share this post


Link to post
Share on other sites

I went ahead and uninstalled Resilio package from Synology and confirmed the folder /volume1/@appdata/resiliosync was gone.

I then reinstalled the latest Resilio package (current 2.6.3_1) and added the problematic folder using the shared key from source.

Now, I am getting flooded with this error in the sync.log:

assert failed /home/jenkins/slave-root/workspace/Build-Sync-Manually-EC2@6/sync/fs/tree/SyncFileEntryTree.cpp:167

Also, the shared folder I just added, its size jumps all over the map, from GB to TB to 0 and so forth. Seems like it isn't indexing at all.

I read one another forum post that this may be because I am adding that folder using a modified shared key, but that is not the case, triple checked.

Help pretty please

Share this post


Link to post
Share on other sites

Resolved the issue.

In case this is useful to anyone, here goes:

On linux source, /var/lib/resilio-sync/ there is a hidden directory starting with .SyncUserxxxxx

in .SyncUserxxxxx/folder I found directories that represent the standard folders in Resilio. Each of these directories contained info.dat file which when inspected (cat or vim) contain the shared secret key and the name of the standard folder.

so: /var/lib/resilio-sync/.SyncUserxxxxx/folder/12345678976543221/info.dat

I ended up finding duplicate of these directories all representing the same standard folder, which were probably created as I kept deleting, re-adding the standard/shared folder. Long story short, I quite easily identified the duplicate directories and deleted them all.

I then inspected all of the long named .db files /var/lib/resilio-sync/ which represent the scanned content of the standard/shared folders. The listing of scanned directories within the .db file can be discerned with a little effort. I found some stale .dbs by determining the creation date as well as size and content. I am sure there is an easier method of loading .db into some sort of program and inspecting that way but VIM did fine.

I then proceeded (this step I am not 100% was useful) to rename the storage.db to storage.db_old.

At this point, I had to repeat above steps on the NAS with resilio path being different /volume1/@appstore/resiliosync/var (or /usr/local/resiliosync/var/ ).

As a final step, I deleted the .sync directories in both source and destination(the ones I am trying to synchronize), re-added the directory I had troubles sharing, let it initialize locally and then added it on the destination successfully. It's now happy. The one thing I am still not sure about is that the initialization on the destination happened within 30 seconds for roughly 3 TBs of data. it is still cached ...somewhere but no one here would point me to where that may be ... the mystery which is attainable probably through paid support, fair enough.

 

Anyway, if this was useful, cheers

 

Share this post


Link to post
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this