Hi all,
in my new PC, I have a SDD drive with Tumbleweed on it, and my home-partition.
Within home, I symlink to a HDD for my pictures, music and other big directories.
That directories reside within a volumegroup & logical volume. (hope thats the right description)
Now I’ve planted a second HDD into my machine, for back-up purposes. (make a shadow home, and from there upload to external NAS).
Since a picture is worth a thousand words: here it is: http://thuis.rolfbakker.nl/platform/screenshot.png
I’m in doubt what I will do with the second HDD (/dev/sdc). Suppose I’ll add it to the vg_data, and extend lv_data. Then what happens if one of the physical disks within the VG fails? Will the complete VG be unavailable then? Or will just the partitions that are (fully or partially) on that disk be broken?
Is it better to have a second vg for the second HDD? Then I’ll loose the benefits from LVM, but maybe have a more robust disk-scheme.
Suse used to use lvm by default a long time ago. Unless things have changed data is lost from the disk that fails bit I don’t see how that could be fixed. What wasn’t clear when I used it was if a single file could finish up using both disks. There is a decent wiki page on it here
As mentioned it can be changed whilst a machine is up and running if it supports hot pluging. You can find a command summary via entering man lvm in a console.
You can also mount the 2nd drive in the path of the existing one. That means you would have to write to it separately but could back up both in one go.
I went off LVM as soon as I could because a machine only has so much room for disks in it. However fitting new larger disks to a linux machine can be a bit of a pain at times. An extreme pain with some of my current set up which is unusual. I think it pays to think about how he disks are used when partitioning is settled and there is more than one disk available. I favour a single on for the entire home directory for instance. Given that the data on it can be stored somewhere else for a while that makes enlarging that one and restoring the data fairly easy. If I used flash drive for /home I would do it the same way and have applications and the rest on an other.
thx John for your answer.
I was away for a few days, hence my late reaction.
From other sources I learned that when a disks that’s part of a VG fails, the whole VG will be unavailable.
Since the VG will be used both for parts of my home, as well as the (first line of) backup of that same home, that’s not the way to go.
So, I’ve created a separate VG for the new disk, that is house for the copy of /home.
From there it is rsynced to my (in house) server, from there to my (out of my house) NAS.
I guess I’ll be safe with that set-up…
There will be tools to restore and replace the failed disk otherwise the entire idea would be useless. It’s not something I have ever been into in depth but to me it seems to be an idea most;y aimed at servers so that disk space can be extended as required and failed disks replaced. Data is always lost when a disk fails so back ups or redundancy is needed. Raids can provide the redundancy. Big advantage as the system can carry on working when one of the disks fails. In fact there needn’t be a rush to replace the failed drive.
I suspect Suse had it as the default early on because it does offer an advantage over a windows desktop system. If a user wants more space they could just add another disk. It was an advantage at the time. However if I had been more aware of what the installer could do I wouldn’t have set the 2 drives I had at the time up like that.
:(On the other hand I have only recently become fully aware of how troublesome replacing some drives on a linux system can be. I do use a flash drive but things are organised so that it’s only written to due to software updates.
At some point I may switch entirely to flash but would use 2 so that only one gets a lot of writes and then make use of cloud storage. Given that I have recently found that ext4 is very probably wearing my disks out ahead of times I may just do that. In that case I would consider using ext2 for them.