Does Upgrading/Downgrading Affect Backup Files?


#1

Hi, I am on 2.0.3.3 and am thinking of moving up to today’s 2.0.4.5 as I want/need the new multithread engine. I need 14 days (and still counting) to backup 3.6 TB worth of data even though I am using a 1Gb up/down connection and a Xeon E3-1245; I want to see if the new engine will help make this faster and will be able to test this as I will be uploading more data on top of this after the upgrade

Just to confirm things before the upgrade, will doing so affect the backup files in any manner? Or will upgrading just affect the database (which can be rebuilt with the correct configuaration files if need be)?

I will be doing the upgrade only after the uploading of this initial set of data is done. The next dataset(s) are actually updated versions of this one.

Thanks!


#2

From that version it will be database only, meaning a downgrade isn’t really viable without a database rebuild, as you said.

Note that database recreates can be quite slow (some have reported days to a week) so it’s not a great path either if it can be avoided. Hopefully you won’t need it. :slight_smile:


#3

Thanks! I certainly hope the upgrade will be a smooth one!

I will update the NAS first since there appears to be updates for other components, then do this via GUI, hopefully it will be a much needed update


#4

My unRAID NAS uses the official Docker container - are you using Docker or something like bintray? If it’s via Docker, I’d update the container as there were some container changes between 2.0.3.3 and 2.0.4.5.

I’m not an OMV user so this could be wrong advice, but if you think you might want to downgrade, using the GUI might be an easier option as you can downgrade simply by removing the newer version from the updates folder (then dealing with the database version issues).

Other than that it shouldn’t matter which method you use.

Oh, and I didn’t mention it before but the slow initial backup you’re seeing will likely speed up a lot after that initial run is complete. So you may want to let the initial backup finish as planned, but then do at least 1 subsequent run on 2.0.3.3 just to get an idea of pre-upgrade performance on a backup with at least 1 version completed.


#5

Good idea, seems to me that I can go ahead and upgrade via the GUI. OMV is more about plugins rather than Docker containers and the Duplicati plugin just lets me set the listen port and IP address and giving me a link to go to Duplicati GUI, so I think the plugin won’t be affected by the update.

I will actually do another backup before the upgrade which consists of 1 TB of changed data according to a FreeFileSync comparision between both datasets, but I can foresee it being much quicker this time given that actually I shifted some content around in the new dataset. We’ll see how this goes; I was just surprised that the initial backup will be this slow


#6

I think my slow initial backup is also due to my OS disk (a thumbdrive actually!) running out of space; I didn’t expect the database to take up this much space

I suppose I can try pausing the backup, shifting it to a HDD and then continuing (as described below) but with about just a bit left (approx 200 GB), it seems a bit hasty to do it now


#7

I have just finished the second round of backups under 2.0.3.3. Here’s the rough stats:
Initial Backup of 3.7 TB: 15 days 11 hours
Scan of this dataset (no data change): 50 mins
2nd Round of additional 900 GB (on top of the 3.7 TB): 4 days 20 hours
Scan of this dataset (no data change): 52 mins

I’ll continue this over at the other thread (Duplicati 2.0.4.5_beta much slower than 2.0.3.3_beta)