Upgrade to TOS 5.1.x - The final guide (collaborative guide)

[TheClue]

Good morning,

I would like to setup the most complete and referenced thread about updating to later versions of TOS. I see the informations are fragmented and before duing this (complex) upgrade, I want to be sure to have all the reference material on the same place, so my idea is to update this thread with all the answers and the references I'm going to find.

Current status

• An almost working F5-221 installation with with 5.1.24
• 2 HDD in RAID1 setup for my important stuff + 1HDD for repleacable data
• 1 SDD for caching - not working
• 2gb system partition

Yeah, I've 2gb partition. When I upgraded from TOS4 to TOS5.1 the requisite of having 8gb system partition was not so clear (staff updated the thread later on), so I did the upgrade and everything went ok anyway. I was lucky I guess. Ofc, I didn't upgrade anymore since.

Why I have decided to upgrade

• I've connected an SSD disk for caching, but if I try to create the cache i get "SSD not created" error, whitout details (side note, a log or feedback popup would be better) - Having 2gb boot partition could be the cause (specific TOS version could be too, theoretically)
• I don't wont to be locked out from TOS releases. I'm not saying i need the new features, but I want a stable system and having "please upgrade to latest TOS release first" as an answer from support when getting something wrong is a no-no to me.
• Sooner or later, the 2gb boot partition problem must be solved, so it's better to do that while your system is working taking a slow pace than doing that during a disaster recovery situation

TO-DO list

1. Backup all the data, including applications data and configuration files
2. Upgrade the hardware setup for better performances (optional)
3. Wipe out all the partitions on all the drives
4. Fresh install of the operating system
5. Restore all the data
6. Reinstall all the application

I'm going to replace the open questions in the following paragraphs as soon we discuss the given topics, for better reference.

0. Prerequisites

• Being able to SSH into the system
• ...

1. Initial Data Backup (and enable future syncing)

Idea: Using Google Cloud Storage

Having USB as a temporary HDD IMHO is a very expensive and risky solution.

First of all i don't like the idea of buing a external storage for that. Not only it should be huge to fit my needs, but it will be very risky. During the entire upgrade process, I'll have only one copy of my data. Making my entire redundancy RAID scheme useless.

Additionally, my main desktop has not so much storage available, so making a local backup is a dead end too.

I was wondering of using a cloning app for uploading all the data on, for ex,, Google Cloud Storage. It will be cheapier and safer.

rClonePlexDrive seems suitable for that.

Ofc the initial backup will take time, but it's ok to me to wait.

Additionally, this won't be a one-shot setup for just this upgrade, but it would remain in place as a running backup solution

I would say that having the application being executed on TOS is mandatory, as having it executing on the local PC would take ages I guess.

Open Points:

• Are those kinds of app designed to be able to upload the entire storage content or just a volume specifically made for being cloned?
• How to restore the data after the upgrade process is done? Copypaste files and folders from the remote location doesn't seem very smart
• Some sort of checksum test should be (manually) put in place for ensure transfer safety?
• Are there better apps for doing that?
• Which is the better procedure for doing so?

2. Upgrade the hardware (optional)

I think this is the best time for upgrading the storage scheme. I was wondering of this scheme:

• BAY 1: Volume 1/RAID1 Sensitive Data (4Tb+ HDD)
• BAY 2: Volume 1/RAID1 Sensitive Data (4Tb+ HDD)
• BAY 3: SDD for both Hyper Cache and boot partition (500Gb - Balanced)
• BAY 4: Volume 2 Replaceable Data (1Tb+)
• BAY 5: Empty (for future upgrade and/or binding BAY4 in RAID scheme in the future)

The open questions here:

• Is it possible to use a SSD disk for both caching and booting the OS at first place?
• Which is the best place to put the boot partition? I think this would beneficial on putting on SSD rather than on a magnetical hard disk in RAID, am i wrong?
• Which is the best size of the boot partition nowdays? Is 8gb future proof?
• Putting the boot partition on a different disk (yet internal) will make future upgrade easier?. The idea here is to find a way to not being forced to wipe the data partitions every time
• How to avoid the boot partition being a single point of fail?

3. Partition Setup

TBD

4. Upgrading TOS

TBD

5. Restore the Data

TBD

3. Restore the applications and configurations

TBD

[Gremlin]

Except, it's not really that complicated and sensible users will, of course, always have at least one other copy of their data. This might be the original data, or backup copies. My issue with cloud storage is that is not universally (affordably) available for everyone. My case in point: despite a 300Mbps internet FFTP link I regularly see upload speeds of only 5Mbps.

[Gremlin]

Looking at your bullet points:

Is it possible to use a SSD disk for both caching and booting the OS at first place?
Which is the best place to put the boot partition? I think this would beneficial on putting on SSD rather than on a magnetical hard disk in RAID, am i wrong?
Which is the best size of the boot partition nowdays? Is 8gb future proof?
Putting the boot partition on a different disk (yet internal) will make future upgrade easier?. The idea here is to find a way to not being forced to wipe the data partitions every time
How to avoid the boot partition being a single point of fail?

I suspect you don't have a clear understanding of the concept of the TOS.

There is no need to wipe the data partitions every time. On this forum you will see a (very) small percentage of users who have, or continue to have, issues. That is the nature of internet forums.

You cannot choose the size of the OS partition. (Not to be confused with the boot partition which is something completely different.)

With the possible exception of SSD specifically set up for caching*, every disk (HDD/SSHD/SSD) in the TNAS SHOULD have on it a set of partitions. "boot/init" (for want of a better term), OS and Swap. These are raid partitions mirrored on every drive. Hence, NOT a single point of failure. They are a prime example of redundancy. Put one drive in the TNAS and it should boot the OS. [And for those that are still unclear, the USB flash drive inside the TNAS does not contain the OS. Often confused with other (free) NAS systems.]

Of course, 8Gb OS partition is not "future proof". Nothing is! It's the same for every consumer NAS out there. Just look at issues Synology had going from 6 > 7 > 7.1 versions.

Someday, someone in the "lab" may decide that the TNAS requires a bigger swap partition to run more efficiently [conjecture only!!!]. Then at the next upgrade we would all have to PLAN AHEAD. Now, where are those backups?

Just a very simplified 2 cents.

What might be nice would be a simplified method of re-sizing and moving data partitions to accommodate changes in system partitions. Given we are dealing with a variety of different data set-ups depending on the users choices, I see that as very unlikely. Raid has always has this type of issue.

*I don't use cache facility so cannot check directly.

[Gremlin]

A quick google search tells me that cache drives do not have a copy of the OS installed. (That also implies, to me, that cache drives should not also be used for data storage.)

[TheClue]

Except, it's not really that complicated and sensible users will, of course, always have at least one other copy of their data. This might be the original data, or backup copies. My issue with cloud storage is that is not universally (affordably) available for everyone. My case in point: despite a 300Mbps internet FFTP link I regularly see upload speeds of only 5Mbps.

Yeah, I got the point. In facts, that's why I want to mirror the data in the cloud at this stage: to fix up this anomaly

Cloning on the cloud replaceable data seems a waste of time an money, though. Since, an SSD cannot be used for both caching and booting at the same time this could be a good alternative scheme:

• BAY 1: Volume 1/RAID1 Sensitive Data (4Tb+ HDD)
• BAY 2: Volume 1/RAID1 Sensitive Data (4Tb+ HDD)
• BAY 3: SDD for both Hyper Cache (500Gb - Balanced)
• BAY 4: Volume 2 for Replaceable Data (4Tb+ - no redundancy)
• BAY 5: SDD for booting, applications, mobile sync and so on (32Gb or something)

The only side effect here is that I won't have a free bay in case I need cache redundancy in case I need better R+W cache performances (having the boot partition on BAY 4 will save a slot, but TOS will spin from a magnetic disk

[TheClue]

With the possible exception of SSD specifically set up for caching*, every disk (HDD/SSHD/SSD) in the TNAS SHOULD have on it a set of partitions. "boot/init" (for want of a better term), OS and Swap. These are raid partitions mirrored on every drive. Hence, NOT a single point of failure. They are a prime example of redundancy. Put one drive in the TNAS and it should boot the OS. [And for those that are still unclear, the USB flash drive inside the TNAS does not contain the OS. Often confused with other (free) NAS systems.]

(U definitively right, I'm quite ok with Unix stuff, but TOS uniqueness is new to me. This thread will teach me a lot of things for sure!)

I admit I had no idea of that, and in those terms it makes totally sense. Obviously, a NAS that won't boot if you plug off the wrong this is just a linux box. But this opens to a new set of questions:

- Let's assume I plug my RAID disks off, then plug a brand-new SSD disk with 8gb boot partition on it. What's supposed to happen when I plug in the HDDs again (with 2gb partitions on it)? This seems the prelude of disaster to me (that's why on the upgrade threads here the staff says that all the partitions in all the disks must be cleared before upgrading to 8gb-based TOS versions?)
- Is it safe to assume that plugging a faster disk into the unit (where the OS will be mirrored automatically) is enough for having the OS been spun from that unit (in normal circumstances)?

[Gremlin]

I can't be absolutely sure about this, but BAY1 is, I believe, the default boot drive. Hence it would be logical to put your ssd in BAY1 if you want to boot off that. You could set up a Volume on the SSD for applications, but I think I would want to maintain redundancy for applications and their settings. Also, since the concept of a nas, in general, is "always on", I don't really see a need for faster boots and/or application start-up. Once they are running, leave them alone.

[Gremlin]

- Let's assume I plug my RAID disks off, then plug a brand-new SSD disk with 8gb boot partition on it.

Just Don't!

You CANNOT mix OS partition sizes. You can find examples on this forum where people have "thought it a good idea" and been left with a mess to clean up.

[TheClue]

I can't be absolutely sure about this, but BAY1 is, I believe, the default boot drive. Hence it would be logical to put your ssd in BAY1 if you want to boot off that. You could set up a Volume on the SSD for applications, but I think I would want to maintain redundancy for applications and their settings. Also, since the concept of a nas, in general, is "always on", I don't really see a need for faster boots and/or application start-up. Once they are running, leave them alone.

Perfect, so this could be the final scheme eventually

• BAY 1: 4Tb+ HDD for booting and replaceable data (ie media files). I would use a faster HDD here, aiming to get for ex. better streaming rather than faster booting. But no need for an expensive SSD.
• BAY 2 & 3: My current RAID1 scheme - 4Tb storage
• BAY 4: SSD for caching
• BAY 5: available for more replaceable data or cache redundancy

Side Effect: applications configuration without redundancy (but this could easily be cloud synced i guess)