Forums

Resolved
0 votes
Installed ClearOS 7 on new 16TB drive. I have my old 3TB drive from my previous pre-7 clearos installation.

I have tried disk -l, the mount -t ext. /dev/sda /dev/sda steps I found googling, no luck.

End game, I am wanting to mount the 3TB drive on new ClearOS 7 as a second drive, mainly want to keep it in the system long enough to move all the data off that filled 3TB drive to the new 16TB drive.

I am unable to google and steps that will help me navigate this. i've been struggling with this for a long time. this is for my home personal server.

There are two steps I need to accomplish:
1. Get data from old drive to new drive
2. Recreate shares that I had created on old installation on new installation pointing to my data.

Any advice would be helpful and appreciated
Saturday, May 16 2020, 10:28 PM
Share this post:
Responses (5)
  • Accepted Answer

    Thursday, May 21 2020, 09:23 PM - #Permalink
    Resolved
    0 votes
    No, LVM isn't old school, it is me who is. I just wanted to remove one layer of complexity at the expense of flexibility when I installed my system a few years ago. I do have a test system thith RAID and LVM, but I've never fiddled with that bit of the file system. I have to pull a couple of horrible tricks to back up a live e-mail system, whereas, with the LVM all I'd need to do is snapshot the filesystem and then back up the snapshotted bit of the e-mails. The problem is that the e-mail system can change during the backup (which I do with rsync) and this can create issues.

    If you can get your old system back up and running, rsync is the way to go, especially if you have a gigabit LAN. Have a look at this doc for a general idea of how to do it.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 21 2020, 08:40 PM - #Permalink
    Resolved
    0 votes
    Is LVM old school? Should I have not been using that for the new 16GB installation?

    I have TWO physical boxes, so I can put the old drive back in the old system and do a rsync (New to me as well).

    I'm questioning the new install of the 16GB ClearOS 7.x. I have done nothing with the new system so if it is better for me to go back and redo the 16GB install I can easily do that right now and wouldn't loose anything.

    I think I will rerun the install and examine my options a little better and if possible skip the LVM.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 21 2020, 08:03 PM - #Permalink
    Resolved
    0 votes
    You can restore a 6.x config into 7.x but you can't restore 5.x into anything.

    From fdisk -l, your 3TB drive is /dev/sda and two partitions and it uses the LVM. That is where your data will be. Your 16TB drive is /dev/sdb and it has a number or partitions on it and it also uses the LVM. I don't really now the LVM well, and your best resource will be Google (perhaps here or here). You will have to work out how to mount the LVM partition from /dev/sda2 as that is where your old data will be. Whatever you do, don't format the partition!

    To be honest, the easiest way of sorting this would be if you could put your old drive back into your old system then rsync the data across.

    It won't help now as it cannot manage the LVM, but the Storage Manager is found at Webconfig > System > Storage.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 21 2020, 07:22 PM - #Permalink
    Resolved
    0 votes
    Nick -

    Thank you for responding to my posting!

    I couldn’t locate the Storage Manager app through the web portal interface.

    https://10.30.1.146:81 (My internal server IP address).

    I didn’t do a config retort. I went from an older ClearOS to the current version, wasn’t sure if there was any chance of taking anything from the old to the new.

    here is what I got:

    [root@gigawatt ~]# blkid

    /dev/sda1: UUID="51161b34-8b1c-4f8b-8353-8f2a42bce5c5" TYPE="ext4" PARTUUID="bc382167-b1c5-44fa-8c22-e914153925de"

    /dev/sda2: UUID="z9wDYZ-RzA9-dKg8-p459-HFhV-q9tW-gIOMl1" TYPE="LVM2_member" PARTUUID="58ecbf59-9aa9-4e0d-b013-7b8db6ac7b0f"

    /dev/sdb1: PARTUUID="bd22cb74-24de-4a2a-8d7d-693dffaf2eda"

    /dev/sdb2: UUID="0eca2d89-6e03-472c-8a6e-cdc8dc0d8d0e" TYPE="xfs" PARTUUID="62721e2d-b7f6-4b2a-ae8b-2abb980146f9"

    /dev/sdb3: UUID="IgKRM2-zpTM-SrOF-OIkt-TJ8f-D341-gLuuOJ" TYPE="LVM2_member" PARTUUID="a4d323b3-b0d1-4879-8fbd-56da6366a89b"

    /dev/mapper/clearos-root: UUID="2d5c2894-6622-4f59-bc33-015e9a14f341" TYPE="xfs"

    /dev/mapper/clearos-swap: UUID="46add929-f148-4fbb-b047-f0019b385947" TYPE="swap"

    /dev/mapper/vg_megawatt-lv_root: UUID="16d1d0e3-1f73-4155-af7e-ee3a6f28e292" TYPE="ext4"

    /dev/mapper/vg_megawatt-lv_swap: UUID="ce0c0af1-ad6f-428a-b182-f541f122bc32" TYPE=“swap"



    ————

    [root@gigawatt ~]# fdisk -l
    WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.

    Disk /dev/sda: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk label type: gpt
    Disk identifier: FEE99DD5-F847-430C-83A3-5C214CCE761E


    # Start End Size Type Name
    1 2048 1026047 500M EFI System
    2 1026048 5860532223 2.7T Linux LVM
    WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.

    Disk /dev/sdb: 16000.9 GB, 16000900661248 bytes, 31251759104 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes
    Disk label type: gpt
    Disk identifier: F57D7010-164C-485A-9F40-62922DB52CB2


    # Start End Size Type Name
    1 2048 4095 1M BIOS boot
    2 4096 2101247 1G Microsoft basic
    3 2101248 31251757055 14.6T Linux LVM

    Disk /dev/mapper/clearos-root: 15991.5 GB, 15991497031680 bytes, 31233392640 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes


    Disk /dev/mapper/clearos-swap: 8321 MB, 8321499136 bytes, 16252928 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes


    Disk /dev/mapper/vg_megawatt-lv_root: 2991.8 GB, 2991776071680 bytes, 5843312640 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes


    Disk /dev/mapper/vg_megawatt-lv_swap: 8287 MB, 8287944704 bytes, 16187392 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes

    -Confused.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, May 17 2020, 07:08 AM - #Permalink
    Resolved
    0 votes
    From a disk, you have to mount each partition individually. If it was a ClearOS installation it s probably the third partition, /dev/sdX3, but we need to identify the X. To mount the old drive you need to decide where to mount it and create the folder for it. The classic place is a folder under /mnt e.g /mnt/olddisk but you could make a location under /store or anywhere. Then you have to look for the drive. Try the command "blkid" or "fdisk -l". You will probably find your current disk is /dev/sda and your old disk /dev/sdb. Then you can mount it:
    mount /dev/sdb3 /mnt/olddisk
    . This will only survive to the next reboot. To make it permanent you need to add it to /etc/fstab. You can see the format there, but it mainly uses the UUID from the blkid command. You can also mount by device name, so instead of UUID=xxxxxxx just use /dev/sdb3, but mounting by UUID is safer. This is because if you add another disk, the sdX designation could change, The UUID won't.

    Alternatively you should be able to accomplish all this through the Storage Manager app, and I think it creates the folder to mount it in to if it does not already exist.

    Did you do a Config Restore to move your configuration across? If you did you flexshares will have been created in the webconfig and all user and groups will exist but Windows Networking fail because the flexshare folders don't exist. You can now move or copy or rsync all the folders under /mnt/olddisk/var/flexshare/shares to /var/flexshare/shares and start Windows Networking. If you did not do a Config Restore to load your new users, you'll need to fix all the file and folder permissions under /var/flexhsare/shares.

    It is not too late to do a Config Restore as your old Config Backups will be under /mnt/olddisk/var/clearos/configuration_backup. It will reinstall all previously installed apps and bring all Users and Groups across.
    The reply is currently minimized Show
Your Reply