MIgrate Seafile 6.0.7 on Windows to Seafile 8.x.x on Docker

I plan doing migration in the following way:
Seafile 6.0.3 Windows => Seafile 6.0.3 Linux => Seafile 8.0.8 Linux => Seafile 8.0.8 Docker

These are the first questions I have:

  1. Is it worth to migrate from SQLite to MariaDB?
  2. Is the suggested migration way good? Is there something to improve?
  3. Where to download 6.0.7 for Linux? @shoeper, @daniel.pan, could you help with it?

Btw, here are the links with useful info:

https://web.archive.org/web/20190423150103/https://manual.seafile.com/deploy_windows/migrate_from_win_to_linux.html

https://web.archive.org/web/20190423150053/https://manual.seafile.com/deploy/using_sqlite.html

Hi,

regarding 2: Just one thing: Why not use the latest 9.0.2 directly? Apart from that, I don’t see anything that would speak against that way. Except the next step:

regarding 3: Yes, it is definitely a downside that no (public?) version archive is being kept for the seafile project. That’s why I started keeping the old versions (at least the ones that I used) in my personal archive at some point… What I could offer you (yes, I know, that’s no officially trusted download source) are the following versions:

  • Win 32Bit 6.0.7 CE
  • Linux 64Bit 6.3.4 CE
  • Linux 64Bit 7.0.3 CE
  • Linux 64Bit 7.0.4 CE
  • Linux 64Bit 7.0.5 CE
  • Linux 64Bit 7.1.3 CE
  • Linux 64Bit 7.1.4 CE
  • Linux 64Bit 7.1.5 CE
  • Linux 64Bit 8.0.1 CE
  • Linux 64Bit 8.0.2 CE
  • Linux 64Bit 8.0.3 CE
  • Linux 64Bit 8.0.4 CE
  • Linux 64Bit 8.0.5 CE
  • Linux 64Bit 8.0.6 CE
  • Linux 64Bit 8.0.7 CE
    So if you would like to use that offer, PM me and I can provide you some of those versions (changing your migration way to 6.0.3 Win => 6.3.4 Linux => etc.)

Regarding 1: I have no personal comparison regarding SQLite (used MySQL on Win from the beginning and MariaDB on Linux since the migration), so I cannot give you any advice there.

Just one general hint: You need to know the downsides and limitations of the provided docker image. If you are fine with the included https proxy and being limited to have seafile served on the according webroot (/) location, than this is ok.
From my personal opinion, it would have been better to separate server and https proxy image (as this would also have allowed using a general proxy that also targets other services, or serving seafile from non-root location (e.g. /seafile/), etc.

Thank you for your help!

I thought there is only 8.x available on Docker, but now I see there is 9.x version, so it’s a good idea to upgrader to 9.x.

The reason why I want first to migrate to 6.0.7 and then upgrade is trivial: it’s better to split the large task to a smaller ones which you can verify independently.

Btw, I completely agree about the separate container for proxy.

The reason why I want first to migrate to 6.0.7 and then upgrade is trivial: it’s better to split the large task to a smaller ones which you can verify independently.

Understandable. At some point during my migration planning, I got aware of the fact that I would possibly never get my hands on the old server versions in any way and that I had to go with the versions which I had available.

So that’s why I chose to include the minor update 6.0.7-to-6.3.4 with the Win-to-Lin migration in one step. The difference wasn’t really that much (chose a different package during Linux installation, plus the execution of a few sql scripts) - the biggest part of work were different things that needed to be done anyway. Plus: I was migrating from one system to another, so if something would have failed (anything that really could have was on the new Linux system) I still had my original Win system available in an operational state.