How to upgrade my main data drive with minimal downtime

  • Apologies if this is a question that's been addressed before. It's likely a common one, but I didn't find anything that quite covered the base I'm looking for here.


    My OMV setup is pretty simple:


    1x 240GB SSD with two partitions (one for the OS, one for virtual machines and Docker config data)
    1x 4TB HDD for data (it does have Docker config data for one container--NextCloud)
    1x 4TB HDD for periodic backups of the data drive


    The data drive is running low on space, so I'm upgrading to a bigger one. An ideal approach would be one where I can just drop the new drive in and have OMV see it as if it's just the same old disk (but bigger), without having to recreate all the shares, etc. Would something as simple as the following approach do that for me?


    1) Boot into Clonezilla and image the old data drive onto the new one
    2) Shutdown
    3) Remove the old (4TB) data drive
    4) Boot into OMV


    I imagine one key to all this is confirming that cloning this way would also give the new drive the old UUID. Is that the case? If not, I'm guessing I'll need to fix that before the first boot into OMV with the new drive, in order to keep the OS from ringing alarm bells that the drive it expects to see is no longer there. But I'm not sure how to do that.


    Any confirmations, advice, or feedback on the best way to handle this would be much appreciated! Thanks in advance!

  • Good point!


    Would an even simpler approach of just doing a basic rsync of everything from the old data drive to the new one, then manually assigning the old UUID to the new drive achieve the drop-in replacement I'm looking for?

  • Thanks! This is all helpful feedback.


    Rebuilding the shares would be a minor, very manageable, hassle. The biggest issue is the NextcloudPi container that's on the drive. I've had to recreate it at least 7 or 8 times, and am tired of dealing with it. (It's a long story, with lots of random issues getting it up and running.) I'm worried that if I boot up without all the shares in place, it could break that container, and have me redoing it yet again.

  • Doing a df -h, it looks like they're referenced by label:



    Code
    /dev/sdc1       3.6T  3.2T  477G  87% /sharedfolders/mirrorRoot
    /dev/sdb1       3.6T  3.2T  480G  87% /export/nasRoot

    I don't have any network shares (SAMBA, NFS, etc.) on the backup drive (sdc1), and I do have NFS (and SAMBA) shares on sdb1, which I assume explains the different look of the reference paths.


    This is teaching me a lot. I'd just assumed that since UUID was referenced by OMV's config.xml file, that must be the way it's managed.

  • For anybody who may come across this thread in the future...


    I ended up taking the safe route, and cloned the drive with CloneZilla. It took about 23 hours, but after it finished, I just shut down the server, disconnected the old hard drive, and booted into OMV. So far it looks to have succeeded as a drop-in replacement.

  • Thanks, @tkaiser!


    Hmm... I'm not sure if this is a red flag and/or something to be concerned about, but the only entry that has a /srv entry is the data partition of the OS disk. For full context, here's the entire df -h output:


    For what it's worth, this is exactly what it looked like before upgrading the hard drive.


    One additional note: There aremtent entries in the config.xml file that show /srv paths for both the nas and mirror disks:

    Code
    <fsname>/dev/disk/by-label/nas</fsname>
    <dir>/srv/dev-disk-by-label-nas</dir>
    Code
    <fsname>/dev/disk/by-label/mirror</fsname>
    <dir>/srv/dev-disk-by-label-mirror</dir>

    I'm not sure if that's helpful detail, though.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!