Data migration to new server - ccnet config and seahub-db needed?

On my way to migrate my data from server A to server B (6.1.1, both MySQL installations, Ubuntu LTS 14.04 (A), 16.04 (B)) I have following two open questions:

  1. I would like to know what is really needed to be transferred to migrate my data (the manual wants me to transfer the whole seafile folder; whereas a lot of it can be auto-generated via script setting option USE_EXISTING_DB).
    Concretely, next to seafile-data/ and seahub-data/, is ccnet/ also required to be transferred? Within conf/ccnet.conf I see USER_NAME, ID and NAME as something used internally ( - do I need to migrate it, or can I use my ccnet installation at server B?
  2. Concerning migrating databases: I saw that upon running script with USE_EXISTING_DB, the seahub-db was already created and even contains fewer tables than the one at A. On A, I assume I have several (outdated) tables at seahub-db from previous Seafile versions that the upgrade scripts did not clean/remove (correct?). Can I use seahub-db at B when migrating my data?

Thanks a lot!

Best from Munich

Let me answer my question myself, after I migrated successfully:

  1. ccnet/ is not required to migrate, only seafile-data/ and seahub-data/ worked out
  2. This is crucial: I first copied my seahub-db MySQL database, but then I realized the structure was never updated since I first installed seafile, like 4.1 version or something. How do you assure that my old seahub-db will continue to work even for new versions of seahub? I tried to take the structure of latest seahub-db and copy over data, but it requires further tuning on the structure to do so (e.g. table ‘django_content_type’ does not contain a column ‘name’ anymore).

Could you comment at least on point 2 to understand how Seafile plans to cope with structure migration of databases?


Just run the upgrade script if upgrading seafile versions. All changes are made automatically. Please see:

Yes, I am sure for each upgrade I did I run the appropriate script(s) over the past years.
I mean it might still work, different database structure compared to what a fresh version has does not necessarily have to fail, I just realized it by accident and wondered about this issue.
Is the structure checked and fully upgraded upon each upgrade? I don’t think so.