Moving existing OMV install to existing storage volume

1. offizieller Beitrag

    Hello all,


    This is my first post, I'll try to be as clear and concise as possible. I'll start with the current configuration and the fix I've gotten myself into:


    System: Acer eeeBox B202 (Intel Atom N270, 2GB RAM, 200GB laptop SATA drive)
    Boot Drive: Sandisk 2GB SD card (already realized my mistake there, hold your boos and hisses until the end please)
    Additional Storage: LaCie USB 2.0 External HDD enclosure containing a 500GB WD SATA drive.
    Filesystem: The two HDD's are part of one Logical Volume (named Vault).
    OMV Verstion: 0.4_i386


    Situation: Got OMV up and running on the SD card about a week ago, in complete disregard of all the excellent advice to the contrary. Was planning on it being temporary while I played with OMV. True to expectations, the SD card seems to be causing problems. It's tossing up "drive is full errors" when starting LVM and other services (such as samba). Not sure if the drive is actually full or if it's a filesystem corruption issue caused by the SD card. Either way, the time has come to get this install onto a proper drive.
    My goal is to get the install onto the physical drive that is installed in the eeeBox (shows as <b>sda</b> in the OS). I've been reading through the How To section on this, and I believe my best bet is to use a live-cd boot of gparted to resize sda into an OS partition, a swapfile, and leave the rest for the LVM. Now for the question:


    Question: Can I resize this partition in gparted without losing the data that I've moved into the logical volume? I can't really tell if there's anything on this specific physical drive, <i>vgdisplay</i> isn't showing the individual physical drives because the cache.tmp file won't load. I should also note that gparted shows the entire physical drive as being unallocated space.


    I am, as you may have guessed, not terribly experienced with Linux. My troubleshooting thus far consists of reading the forums as well as Google searches regarding LVM and Gparted.


    Thanks for your time (and hopefully for your assistance).


    -Spaxter

    • Offizieller Beitrag

    If I am reading correctly, you want to resize the 200gb drive and install OMV on it without losing data? Not going to work. I think it would be a bad idea to run lvm this way. If one drive fails, you lose all your data. Can you transfer your data somewhere else temporarily? If so, I would do the following:


    - move data to temp location
    - Unplug 500gb drive
    - Install OMV on 200 gb drive
    - Use gparted to resize 200 gb drive (I would leave around 10gb for OMV) and create third partition from remaining space
    - Plug 500gb drive back in and create share for third partition and 500gb drive separately
    - move data back to omv

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    ryecoaaron, thank you for the response!


    I came to basically the same conclusion over the course of the night. My final install process went much as you described, except I left about 20GB for OMV. Probably overkill, but I don't think I'll regret sacrificing the 10GB from data storage.


    Regarding the LVM setup, I'm not sure I understand? You are saying that I would lose all my data if one drive failed, can you elaborate on that? I thought LVM just grouped the physical disks into one pool that you could add and remove from at will, so long as you didn't mind losing data on the drives you pulled. I hadn't set up any parity or mirroring system previously, as I use CrashPlan & Dropbox for offsite backup of important files anyway.


    So I guess my use of LVM amounted to: "I'm lazy and don't want to keep track of which share is on which drive, so I lump all my drives together."


    Thanks again!


    -Spaxter

    • Offizieller Beitrag
    Zitat von "Spaxter"

    You are saying that I would lose all my data if one drive failed, can you elaborate on that? I thought LVM just grouped the physical disks into one pool that you could add and remove from at will, so long as you didn't mind losing data on the drives you pulled.


    I don't use LVM myself but I guess data from the non-failed drive can be recovered sometimes. If you have a good backup and you are lazy :), then I guess LVM will do what you want.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    Regarding LVM and data loss.


    You can manage data with LVM, so that you are able to remove disks, which does not contain any volume data. If a disks fails or gets removed, that contains data of an active volume, the active volume is unrecoverable dead and all data on that volume is lost. This includes all the drives that belong to that volume and that are still available.


    LVM does not protect you on disc failures in any way, and as soon as you loose on drive, you will loose all volumes that have 1 byte on that failed drive.


    Even replacing the drive with a new drive will not give the "still available" data on the remaining drives back. Your volume is still corrupted and cannot be rebuild.


    If you want protection, you need redundancy. That is either Raid (which is supported in OMV) or ZFS (which is not supported from OMV, but is working).


    For redundancy, put in at least a Raid5 and create an LVM on top of the Raid-Array. Therefor you have the flexibility of LVM and the protection (against hardware errors) of RAID

    Everything is possible, sometimes it requires Google to find out how.

    Zitat von "SerErris"


    If you want protection, you need redundancy. That is either Raid (which is supported in OMV) or ZFS (which is not supported from OMV, but is working).


    For redundancy, put in at least a Raid5 and create an LVM on top of the Raid-Array. Therefor you have the flexibility of LVM and the protection (against hardware errors) of RAID


    Thank you for that explanation. That helps alot, now I understand the issues I'm having trying to recover data from the untouched half of the logical volume. I had thought I could reduce the volume with vgreduce <volume name> --removemissing --force and just drop the missing PV, but it would appear not. I can't find a way to mount the LV, even though it shows up in vgscan. Time to wipe the drive I guess.

    Yes, volume is dead, filesystem is dead, data lost. You could only recover the data with recovery tools, that identify the data in the data blocks. that will take a lot of time and may or may not be successfull. It only works with some file types and requires, that the files are not fragmented.

    Everything is possible, sometimes it requires Google to find out how.

    Yeah, totally not worth the time and effort. Clicking "restore" from cloud and "copy" from the 1TB NTFS external is much easier. Part of this project is to get the essential data migrated from the 1TB so it can be reformatted as XFS and attached to the NAS as well. Already attached it while formatted as NTFS and went through the whole duplicate UUID issue.


    Why cheat myself out of the full newb experience by reading the FAQs? Those are like spoilers.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden