[linux-lvm] VG wiederfinden

[linux-lvm] VG wiederfinden

[Tim-Christian.Hanschen]

Hallo Heinz,

ich habe ein Problem mit LVM unter Linux/390.

Ich hatte ein LVM (Version 0.8?) unter einen 2.2.16 Kernel laufen. Alles
lief soweit ganz gut. Gestern habe ich eine neue Linux Version installiert,
Kernel 2.4.5. dort ist die Version 0.9.1_beta7-14 mitgeliefert.

Mein Problem ist nun, dass ich keine LVM-Platten mehr finde. Die PV und VG
sind verschwunden. Gibt es eine Möglichkeit die Gruppen suchen zu lassen?

Danke & Tschau,
  - Tim Hanschen -

Re: [linux-lvm] VG wiederfinden

[Heinz J . Mauelshagen]

Tim-Christian,

vgscan ist das Kommando, welches nach VGs sucht und /etc/lvmtab* Dateien
erstellt, die von "vgchange -ay" genutzt werden, um die Volume Groups
zu aktivieren.

Ich empfehle ein Update auf LVM 1.0, da 0.9.1 Beta einige Fehler hatte.

Gruß,
Heinz    -- The LVM Guy --

On Wed, May 08, 2002 at 07:04:51AM +0200, Tim-Christian.Hanschen@GAD.de wrote:
> Hallo Heinz,
> 
> ich habe ein Problem mit LVM unter Linux/390.
> 
> Ich hatte ein LVM (Version 0.8?) unter einen 2.2.16 Kernel laufen. Alles
> lief soweit ganz gut. Gestern habe ich eine neue Linux Version installiert,
> Kernel 2.4.5. dort ist die Version 0.9.1_beta7-14 mitgeliefert.
> 
> Mein Problem ist nun, dass ich keine LVM-Platten mehr finde. Die PV und VG
> sind verschwunden. Gibt es eine Möglichkeit die Gruppen suchen zu lassen?
> 
> Danke & Tschau,
>   - Tim Hanschen -
> 
> 
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html


*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

[linux-lvm] offtopic but ...

[Oliver Jovic]

Hello,

after searching the web for a while i now bother you with my wish. ;-)

Well i use LVM now already for nearly 2 years and had in this time 2 big
problems (some harddisks gave up) where i lost nearly everything. I tried
to restore the LVM and filesystem but well if you lose 1/4 of your
LVM its really hopeless (or maybe I just didnt know how ;-P coz the
howto's to this question where well not very helpfull).

What i would like  is a solution which is between LVM and a RAIDx. LVM
has in my eyes the disadvantage that you create a filesystem over different
drives/partitions. If you lose one you nearly lose everything.
With a RAID you lose a harddrive/partition (diskspace) to build it (more
costs for harddrives and maybe a controller).

The solution between would be that all drives still have their own
'filesystem'. The logical unit would just need to spread the
directories/files over the allocated drives/partitions and keep on at
least 2 drives something like a index (maybe just one file like
ext3 is using it) file where the dirs have to go logicaly if you browse
through the logical unit. If one drive would fail you would have still the
rest. Some directories would be maybe missed but well at least the rest would
still be accessable. If there would be a chronical component in combination
with a smaller raid all newer files could first pass on the raid and then
went onto a unsecure part of the logial volume (not LVM). A scheduler
could relocate all dirs at some times so that all drives have the same level
of usage (diskspace).

Well, because i am not a programmer i am passing this idea to you readers.
Maybe somebody has already programmed something like that, then please let
me know. If not maybe somebody wants to. I guess it shouldnt be sooo
difficult. Anyways, let me know if possible. Maybe i can give some more
ideas or explain it better.

Thanks for reading. :-)

OJ

Re: [linux-lvm] offtopic but ...

[Tim]

Quoth Oliver Jovic:
> Hello,
> 
> after searching the web for a while i now bother you with my wish. ;-)
> 
> Well i use LVM now already for nearly 2 years and had in this time 2 big
> problems (some harddisks gave up) where i lost nearly everything. I tried
> to restore the LVM and filesystem but well if you lose 1/4 of your
> LVM its really hopeless (or maybe I just didnt know how ;-P coz the
> howto's to this question where well not very helpfull).

This is a solved problem.  Use RAID.

You lose a drive to parity information; that's the price of admission.

It's not like a Promise RAID card is that expensive.

-- 
    We should take care not to make the intellect our god; 
    it has powerful muscles, but no personality. 

                                        --Albert Einstein 

Re: [linux-lvm] offtopic but ...

[Oliver Jovic]

On Wed, 8 May 2002, Tim wrote:

> Quoth Oliver Jovic:
> > Hello,
> >
> > after searching the web for a while i now bother you with my wish. ;-)
> >
> > Well i use LVM now already for nearly 2 years and had in this time 2 big
> > problems (some harddisks gave up) where i lost nearly everything. I tried
> > to restore the LVM and filesystem but well if you lose 1/4 of your
> > LVM its really hopeless (or maybe I just didnt know how ;-P coz the
> > howto's to this question where well not very helpfull).
>
> This is a solved problem.  Use RAID.
>
> You lose a drive to parity information; that's the price of admission.
>
> It's not like a Promise RAID card is that expensive.
>
>

Hehe Tim,

that was fast, but as i told little bit lower in the email I dont want to
put everything in a RAID. The RAID controller isnt the problem if you buy
me a further 160GB Maxtor i will buy the RAID contoller or do
software-RAID. ;-)
The goal is simply to combine more diskspace+more security then just a
LVM+one logical unit (mountpoint/device where you dont have to care all
the time
how the data gets stored and where)+better usage of the diskspace (you
dont have on the one everything free and the other is halffull.

Or just imagine you would like to have 500gb and have only 4x3,5 slots to
build the harddrives in and the maximum size is at the moment 160GB. How
would you do it and you would give up some security for the advantage to
have more space but not to lose everything if one drive fails.
And the idea i described in the email below is somehow between a RAID0/LVM
and a RAID5.

OJ

Re: [linux-lvm] offtopic but ...

[Tim]

> Hehe Tim,
> 
> that was fast, but as i told little bit lower in the email I dont want to
> put everything in a RAID. The RAID controller isnt the problem if you buy
> me a further 160GB Maxtor i will buy the RAID contoller or do
> software-RAID. ;-)

Fair enough.  Personally (having to do this at work) I feel like an IDE
enclosure or a hardware RAID card is a relatively small investment in
data security, but then again, the 500GB I have live right now is not
content that I can tolerate data loss on.  We probably should not use
IDE drives for it at all, except that it is replicated onto a whole
steaming mess of SCSI drives, also RAIDed up... 

I think your requirements are different than the ones I am used to.


> The goal is simply to combine more diskspace+more security then just a
> LVM+one logical unit (mountpoint/device where you dont have to care all
> the time
> how the data gets stored and where)+better usage of the diskspace (you
> dont have on the one everything free and the other is halffull.

Makes sense, but I'm not sure how one would dynamically reallocate
parity information while everything is in-flight (eg. live).


> Or just imagine you would like to have 500gb and have only 4x3,5 slots to
> build the harddrives in and the maximum size is at the moment 160GB. How
> would you do it and you would give up some security for the advantage to
> have more space but not to lose everything if one drive fails.
> And the idea i described in the email below is somehow between a RAID0/LVM
> and a RAID5.

Again, the difference between my requirements and the ones you're
outlining is that I simply call a vendor and order another enclosure
when I need another 500GB.

I think I am beginning to see what your idea is, but the logistics of
having LVM take care of the metadata seem rather daunting.


-- 
    We should take care not to make the intellect our god; 
    it has powerful muscles, but no personality. 

                                        --Albert Einstein 

Re: [linux-lvm] offtopic but ...

[Christian Limpach]

Hi!

> What i would like  is a solution which is between LVM and a RAIDx. LVM
> has in my eyes the disadvantage that you create a filesystem over
different
> drives/partitions. If you lose one you nearly lose everything.
> With a RAID you lose a harddrive/partition (diskspace) to build it (more
> costs for harddrives and maybe a controller).

here's what you/one could do:
- you create a RAID5 occupying about 10% of your total disk space
- you create a a PV on this RAID5 and disable allocation on it (-x n)
- you create PVs in the remaining space on all the disks
- you put all the PVs in a VG
- you create your partitions
- you have faith in pvmove ;-)

Finally you'll need a script which runs regularly and uses the statistics
from lvdisplay to find out which PEs are most read from and written to and
moves those PEs to the PV which is on the RAID5.  This is very likely to
keep at least all the metadata of your filesystems on the RAID5 part of your
disks since metadata should have the most accesses.  Additionally one could
add some magic to the filesystems which allows finding out where the
metadata is and lock those PEs onto the RAID5-PV.

I'm too chicken to have faith in pvmove ;-)

     christian

Re: [linux-lvm] offtopic but ...

[Oliver Jovic]

On Wed, 8 May 2002, Tim wrote:

> > Hehe Tim,
> >
> > that was fast, but as i told little bit lower in the email I dont want to
> > put everything in a RAID. The RAID controller isnt the problem if you buy
> > me a further 160GB Maxtor i will buy the RAID contoller or do
> > software-RAID. ;-)
>
> Fair enough.  Personally (having to do this at work) I feel like an IDE
> enclosure or a hardware RAID card is a relatively small investment in
> data security, but then again, the 500GB I have live right now is not
> content that I can tolerate data loss on.  We probably should not use
> IDE drives for it at all, except that it is replicated onto a whole
> steaming mess of SCSI drives, also RAIDed up...

I would also use RAID if i had important data to store. No doubt about
that. But the data i have isnt so important. If I lose it i can live with
it but well if i would lost only the data which was on the harddrive which
gave up would be better. ;)

>
> I think your requirements are different than the ones I am used to.
>

I think also. We have a couple of machines here with RAID5 for important
data.

>
> > The goal is simply to combine more diskspace+more security then just a
> > LVM+one logical unit (mountpoint/device where you dont have to care all
> > the time
> > how the data gets stored and where)+better usage of the diskspace (you
> > dont have on the one everything free and the other is halffull.
>
> Makes sense, but I'm not sure how one would dynamically reallocate
> parity information while everything is in-flight (eg. live).
>

I think its easy. Maybe i just didnt described it good enough.

>
> > Or just imagine you would like to have 500gb and have only 4x3,5 slots to
> > build the harddrives in and the maximum size is at the moment 160GB. How
> > would you do it and you would give up some security for the advantage to
> > have more space but not to lose everything if one drive fails.
> > And the idea i described in the email below is somehow between a RAID0/LVM
> > and a RAID5.
>
> Again, the difference between my requirements and the ones you're
> outlining is that I simply call a vendor and order another enclosure
> when I need another 500GB.

Hehe wait i am searching for my postal address where you can also send me
some 500GB. ;-)

>
> I think I am beginning to see what your idea is, but the logistics of
> having LVM take care of the metadata seem rather daunting.
>

Well the idea had nothing to do with LVM. Its something 'totaly'
different. I wouldnt need to use LVM at all if there would be such a
solution i described.

Take a look at this:


			   application
				|
+----------------------------------------------------------------------
|
|			virtual device
|
+----------------------------------------------------------------------
    |             |            |            |
+----------+ +----------+ +----------+ +----------+
|          | |          | |          | |          |
| /dev/hda | | /dev/hdb | | /dev/hdc | | /dev/hdd |
|   ext3   | | reiserfs | |   xfs    | |  ext2    |
+----------- +----------+ +----------+ +----------+
 index file == index file


The index file contain the dirstructure/dirtree. Its stored/updated on
/dev/hda and /dev/hdb simultaneous so have always the index. Should be
configurable where to put the index file. Maybe also on more then 2
drives, simply how and where the user wants it.

Lets imagine the virutal device would be totally empty (this would mean
all drives are also empty, but already with a filesystem which could
differ as you see) and already defined with the drives /dev/hd[a-b].

If you know would create now there lets say a dir called "pub" he would
create it on /dev/hda.
We would put/cp now some files in that "pub" dir. He should still put it
on /dev/hda:/pub (strange syntax but describes it ;)).
When i know would create on my virtual device (lets call it VD) in VD:/pub
a dir called "linux" he should put this dir "linux" on /dev/hdb:/linux.

If i would now ls VD:/ i would see just the dir "pub" like it should als
be. If i change into pub my VG would know through the index file that
"linux" is a subdir form "pub" and that "linux" is physicaly stored on
/dev/hdb:linux.

It would simply doenst matter on which harddisk and with which fs the
harddrive is formated with. The VD doesnt cares about this. It would make
ti to me totaly transparent like LVM also doenst shows me where it stores
what.

If now lets say /dev/hdb would fail i would still have the directorytree
because i have these data in the index file on /dev/hda. The dirtree would
be complete but all files which where on /dev/hdb would be lost but i
would still have all data on /dev/hda and it would still run. Maybe i had
to reboot coz the harddrive would stop the machine .. but well after i
removed the failed harddrive from the VG i would have the rest still
accessable. The VG could then remove the dirs out of the tree which where
on /dev/hdb or i could simply mount /dev/hda and see whats on it but a
little bit unsorted ;) so its maybe better to do it then over the VG.

Well thats my idea. I hope this time a little bit clearer.

OJ :)

Re: [linux-lvm] offtopic but ...

[Steven Lembark]

>> What i would like  is a solution which is between LVM and a RAIDx. LVM
>> has in my eyes the disadvantage that you create a filesystem over
> different
>> drives/partitions. If you lose one you nearly lose everything.

You don't create LV's on a "drive". You create them on a Physical
Volume ("PV"). This matters, becuse LVM has no real idea what the
underlying PV is, only that it's there. If the PV is RAID5 then
you can loose a disk drive without loosing the PV or any data on it.

>> With a RAID you lose a harddrive/partition (diskspace) to build it (more
>> costs for harddrives and maybe a controller).

You are not going to get reliability on multi-drive sytems without
SOME sort of redundancy. Either back the data up offline (e.g., to
tape, another disk or CD) or use RAID. If you really find the cost
of a single disk drive that prohibitive then feel free to pay for
it in time: make tape backups every time there is sufficient data
to be worth not re-entering.

Now you know why most people are willing to pay RAID5 -- many
companies I work for prefer RAID1+0 (i.e., mirroring individual
disks at the hardware level then appending their space into a
single large PV).

A 4-disk RAID5 doesn't eat that much of your total space and
should give reaonable performance. If you're desparate for
space, use an 8-drive stripe w/ 1b chunks.


> I'm too chicken to have faith in pvmove ;-)

Prbably a wise choice, especially since your method requires
accessing the most-used data.

Another approach is to cpio -p the items to a new location
and soft-link the old directory.

Main problem is that as the data use changes over time you
will likely have the least-used data filling the RAID5 system
and no more room for the hot stuff.


--
Steven Lembark                               2930 W. Palmer
Workhorse Computing                       Chicago, IL 60647
                                            +1 800 762 1582

Re: [linux-lvm] offtopic but ...

[Ragnar Kjørstad]

On Wed, May 08, 2002 at 04:12:48PM +0200, Oliver Jovic wrote:
> 			   application
> 				|
> +----------------------------------------------------------------------
> |
> |			virtual device
> |
> +----------------------------------------------------------------------
>     |             |            |            |
> +----------+ +----------+ +----------+ +----------+
> |          | |          | |          | |          |
> | /dev/hda | | /dev/hdb | | /dev/hdc | | /dev/hdd |
> |   ext3   | | reiserfs | |   xfs    | |  ext2    |
> +----------- +----------+ +----------+ +----------+
>  index file == index file

There are many functions you loose if multiple seperate filesystems are
used. e.g:
what do you do when a file grow to no longer fit on it's original
disk? You can not easily move it (atomicly), and you can not
easily split it into multiple chunks.


If you don't need this functionality, the closest approximation to what
you want is a symlink-three.

Basicly you can create a very small filesystem with symlinks for each
and every file on your "virtual filesystem" (don't call it a virtual
device, because that's something different :) ). You can use raid to get
redundancy for the link-three, and as it is very small you don't loose a
lot of space.

You could extend this scheeme to implement a small kernel-module that
did :
* open("/mnt/hdX/file", O_CREATE)
* symlink("/mnt/hdX/file", "/mnt/virtual/file")
when your application does
* open("/mnt/virtual/file", O_CREATE)
to make it more seemless.


However, it's once you want it to be totally transparrent, and files to
migrate to the disk with more space that it gets complicated.



-- 
Ragnar Kjørstad
Big Storage

Re: [linux-lvm] offtopic but ...

[Heinz J . Mauelshagen]

On Wed, May 08, 2002 at 04:12:48PM +0200, Oliver Jovic wrote:
> On Wed, 8 May 2002, Tim wrote:
> 
> > > Hehe Tim,
> > >
> > > that was fast, but as i told little bit lower in the email I dont want to
> > > put everything in a RAID. The RAID controller isnt the problem if you buy
> > > me a further 160GB Maxtor i will buy the RAID contoller or do
> > > software-RAID. ;-)
> >
> > Fair enough.  Personally (having to do this at work) I feel like an IDE
> > enclosure or a hardware RAID card is a relatively small investment in
> > data security, but then again, the 500GB I have live right now is not
> > content that I can tolerate data loss on.  We probably should not use
> > IDE drives for it at all, except that it is replicated onto a whole
> > steaming mess of SCSI drives, also RAIDed up...
> 
> I would also use RAID if i had important data to store. No doubt about
> that. But the data i have isnt so important. If I lose it i can live with
> it but well if i would lost only the data which was on the harddrive which
> gave up would be better. ;)

With recent LVM1 versions, you need to put the LVM metadata stored on the lost
disk onto an accessable on (which can be a loop device) using vgcfgrestore.
The you can rectivate your Volume Group and access all data but that
on the gone disk.

With 1.1-rcX, you can activate a Volume Group which lost quorum (that means
that not all of its Physical Volumes are accessable) anyway (vgchange -qn).

Both ways, you should be able to get the still accessable data. What your
filesystem makes out of this, is for suse very much depending on the particular
filesystems metadata and data layout.

Regards,
Heinz    -- The LVM Guy --


> 
> >
> > I think your requirements are different than the ones I am used to.
> >
> 
> I think also. We have a couple of machines here with RAID5 for important
> data.
> 
> >
> > > The goal is simply to combine more diskspace+more security then just a
> > > LVM+one logical unit (mountpoint/device where you dont have to care all
> > > the time
> > > how the data gets stored and where)+better usage of the diskspace (you
> > > dont have on the one everything free and the other is halffull.
> >
> > Makes sense, but I'm not sure how one would dynamically reallocate
> > parity information while everything is in-flight (eg. live).
> >
> 
> I think its easy. Maybe i just didnt described it good enough.
> 
> >
> > > Or just imagine you would like to have 500gb and have only 4x3,5 slots to
> > > build the harddrives in and the maximum size is at the moment 160GB. How
> > > would you do it and you would give up some security for the advantage to
> > > have more space but not to lose everything if one drive fails.
> > > And the idea i described in the email below is somehow between a RAID0/LVM
> > > and a RAID5.
> >
> > Again, the difference between my requirements and the ones you're
> > outlining is that I simply call a vendor and order another enclosure
> > when I need another 500GB.
> 
> Hehe wait i am searching for my postal address where you can also send me
> some 500GB. ;-)
> 
> >
> > I think I am beginning to see what your idea is, but the logistics of
> > having LVM take care of the metadata seem rather daunting.
> >
> 
> Well the idea had nothing to do with LVM. Its something 'totaly'
> different. I wouldnt need to use LVM at all if there would be such a
> solution i described.
> 
> Take a look at this:
> 
> 
> 			   application
> 				|
> +----------------------------------------------------------------------
> |
> |			virtual device
> |
> +----------------------------------------------------------------------
>     |             |            |            |
> +----------+ +----------+ +----------+ +----------+
> |          | |          | |          | |          |
> | /dev/hda | | /dev/hdb | | /dev/hdc | | /dev/hdd |
> |   ext3   | | reiserfs | |   xfs    | |  ext2    |
> +----------- +----------+ +----------+ +----------+
>  index file == index file
> 
> 
> The index file contain the dirstructure/dirtree. Its stored/updated on
> /dev/hda and /dev/hdb simultaneous so have always the index. Should be
> configurable where to put the index file. Maybe also on more then 2
> drives, simply how and where the user wants it.
> 
> Lets imagine the virutal device would be totally empty (this would mean
> all drives are also empty, but already with a filesystem which could
> differ as you see) and already defined with the drives /dev/hd[a-b].
> 
> If you know would create now there lets say a dir called "pub" he would
> create it on /dev/hda.
> We would put/cp now some files in that "pub" dir. He should still put it
> on /dev/hda:/pub (strange syntax but describes it ;)).
> When i know would create on my virtual device (lets call it VD) in VD:/pub
> a dir called "linux" he should put this dir "linux" on /dev/hdb:/linux.
> 
> If i would now ls VD:/ i would see just the dir "pub" like it should als
> be. If i change into pub my VG would know through the index file that
> "linux" is a subdir form "pub" and that "linux" is physicaly stored on
> /dev/hdb:linux.
> 
> It would simply doenst matter on which harddisk and with which fs the
> harddrive is formated with. The VD doesnt cares about this. It would make
> ti to me totaly transparent like LVM also doenst shows me where it stores
> what.
> 
> If now lets say /dev/hdb would fail i would still have the directorytree
> because i have these data in the index file on /dev/hda. The dirtree would
> be complete but all files which where on /dev/hdb would be lost but i
> would still have all data on /dev/hda and it would still run. Maybe i had
> to reboot coz the harddrive would stop the machine .. but well after i
> removed the failed harddrive from the VG i would have the rest still
> accessable. The VG could then remove the dirs out of the tree which where
> on /dev/hdb or i could simply mount /dev/hda and see whats on it but a
> little bit unsorted ;) so its maybe better to do it then over the VG.
> 
> Well thats my idea. I hope this time a little bit clearer.
> 
> OJ :)
> 
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] offtopic but ...

[Harri Haataja]

On Wed, May 08, 2002 at 09:27:14AM -0500, Steven Lembark wrote:
> You are not going to get reliability on multi-drive sytems without
> SOME sort of redundancy. Either back the data up offline (e.g., to
> tape, another disk or CD) or use RAID. If you really find the cost
                            ^^

For the nth time, RAID is no substitute for backups :)

Re: [linux-lvm] offtopic but ...

[Patrick Caulfield]

On Mon, May 13, 2002 at 12:39:01PM +0300, Harri Haataja wrote:
> On Wed, May 08, 2002 at 09:27:14AM -0500, Steven Lembark wrote:
> > You are not going to get reliability on multi-drive sytems without
> > SOME sort of redundancy. Either back the data up offline (e.g., to
> > tape, another disk or CD) or use RAID. If you really find the cost
>                             ^^
> 
> For the nth time, RAID is no substitute for backups :)
 
Maybe we should add it to the mailing list trailer:
 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
> and remember: RAID is no substitute for backups
> 

-- 

patrick

Re: [linux-lvm] offtopic but ...

[Tim]

> > read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
> > and remember: RAID is no substitute for backups

Sounds good to me... when I contacted Sistina about commercial support
for LVM, Mr. Heinz seemed genuinely surprised that I took proper
backups.  "But that's my job!"  Perhaps that's why I have such a job...

My father had his laptop stolen recently and the hard drive that was
supposed to have been ordered for its docking station, was line-item
vetoed by a member of the IT staff at his hospital.  Needless to say,
said IT guy is now looking for work, and I would not hire him :-)

Incremental backups are orthogonal to true high availability, but you're
guaranteed to have low availability if you have no disaster recovery
plans.  I wish there were a more succinct way to express that!


-- 
    "The most valuable piece of equipment in the darkroom
     is the trash can."
                                  --Ansel Adams

Re: [linux-lvm] offtopic but ...

[Steven Lembark]

-- Harri Haataja <harri.haataja@smilehouse.com>

> On Wed, May 08, 2002 at 09:27:14AM -0500, Steven Lembark wrote:
>> You are not going to get reliability on multi-drive sytems without
>> SOME sort of redundancy. Either back the data up offline (e.g., to
>> tape, another disk or CD) or use RAID. If you really find the cost
>                             ^^
>
> For the nth time, RAID is no substitute for backups :)

Depends on the size of a system. If you have too much
(e.g.,NASA has roughly a PetaByte on line at any time) of
data there is no effective way to back it up and restore
it. The only way to keep it on line is RAID1+0 or RAID5+1
and hope to hell you can fix any hardware problems before
they kill you. Even if you kept all the info on line there
simply wouldn't be time to restore any of it before people
needed the stuff.

Banks are a good example of this: they have huge amounts
of data and simply cannot afford downtime. Every minute
their boxes are offline they loose millions. Net result
is that they use multiple centers with multiple computers
with multiple EMC systems with multiple volumes RAID-ed
across multiple sets of duplicated drives connected by
multiple controllers across multiple lans and heartbeat
systems monitoring each of them.

For a few tens of millions you can avoid tapes too :-)

In this case I should have been clearer about backups vs.
archival storage. Archiving data to tape is a wonderful
thing but won't help you if hardware fails and you need
quick access to the system. If the high-speed stuff fails
you may be able to get by with CD Jukes or
older, slower disk systems that have the most-used data
or data marts on them. The daily update cycle burns a set
of CD's that contain the most recent storage units that
are used if the high-speed storage fries.

This is a bit different from having to archive the data
for recovery purposes in that backup online storage is
in an immediately restorable format.

--
Steven Lembark                               2930 W. Palmer
Workhorse Computing                       Chicago, IL 60647
                                            +1 800 762 1582

Re: [linux-lvm] offtopic but ...

[Steven Lembark]

-- Tim <tim@connectlive.com>

> Incremental backups are orthogonal to true high availability, but you're
> guaranteed to have low availability if you have no disaster recovery
> plans.  I wish there were a more succinct way to express that!

How about:

    "Don't tempt Murphy."

    "Lack of planning is a disaster in itself."

    "0 to the 10th equals nothing at all"

(the last from Jethro Tull if you handn't seen it before).


But this depends on the environment. In a number of the
data warehouses I've worked on there simply would not be
time to restore the data from archival media. The best
they can do is make the "high" approach 100% and live with
it. There will be a relatively small set of archival storage
that can be brought on line, but there is no way that
restoring data from archival media is an acceptable recovery
plan in these cases ("Sorry, General, we can't respond to
that nuclear bomb comming in: it'll take us at least 3 more
hours to recover from these tapes." Think banker, heavy
industrial plant and you have the same situation).

The good news is that today's near-term storage hardware
(from fiber scsi cards down to the disks) will handle
anything short of a nuclear blast without failing miserably.
This leaves "full availability" systems as a viable alternative
in many cases.



--
Steven Lembark                               2930 W. Palmer
Workhorse Computing                       Chicago, IL 60647
                                            +1 800 762 1582

Re: [linux-lvm] offtopic but ...

[Benjamin Scott]

On Mon, 13 May 2002, at 9:28am, Steven Lembark wrote:
> Depends on the size of a system.  If you have too much ... of data there
> is no effective way to back it up and restore it.

  In my experience, large systems are even more likely to require multiple
levels of data redundancy.  When you get into that space, though, you're not
talking about running "tar" on the filesystem at 2 AM.  :)  Instead, you're
talking application-level backups, storage-level snapshots, that sort of
thing.  Maybe the snapshots are dumped to tape, and the tapes kept offsite.  
Maybe they ship the whole storage array offsite.  I've heard of or seen
both.  There are plenty of even more sophisticated solutions.

> For a few tens of millions you can avoid tapes too :-)

  "Backup" does not have to mean "magnetic tape".  The essential element is
that the backup is offline, so that if the "live" system gets destroyed
somehow, all is not lost.  Yes, the downtime from such a disaster is
extremely painful -- but not having the data at all is orders of magnitude
more painful.

> Banks ... use multiple centers with multiple computers with multiple EMC
> systems with multiple volumes RAID-ed across multiple sets of duplicated
> drives connected by multiple controllers across multiple lans and
> heartbeat systems monitoring each of them.

  And offline backups kept in physically hardened offsite facilities on top
of that.  Banks sincerely believe they cannot have too many copies of their
data.  I've seen pictures of the offline and near-line facilities they use
for this sort of thing -- warehouses full of shelves and shelves of data
cartridges.

> Archiving data to tape is a wonderful thing but won't help you if hardware
> fails and you need quick access to the system.

  Offline backups are for disaster recovery, not availability.  I think
you're trying to say that, but the point is getting confused.  The
difference between a small office's and a large bank's disaster recovery
plans is the difference between their definitions of "disaster".  A small
office probably considers a hard drive failure or OS corruption a
"disaster".  A bank thinks more along the lines of "multiple terrorist
attacks".

-- 
Ben Scott <bscott@ntisys.com>
| The opinions expressed in this message are those of the author and do not |
| necessarily represent the views or policy of any other person, entity or  |
| organization.  All information is provided without warranty of any kind.  |

Re: [linux-lvm] offtopic but ...

[Benjamin Scott]

On Mon, 13 May 2002, at 9:39am, Steven Lembark wrote:
> The good news is that today's near-term storage hardware (from fiber scsi
> cards down to the disks) will handle anything short of a nuclear blast
> without failing miserably. This leaves "full availability" systems as a
> viable alternative in many cases.

  Hardware failure is not the leading cause of data loss.  User error is.

  All the RAID in the world will not help you if an operator deletes the
wrong file.

-- 
Ben Scott <bscott@ntisys.com>
| The opinions expressed in this message are those of the author and do not |
| necessarily represent the views or policy of any other person, entity or  |
| organization.  All information is provided without warranty of any kind.  |

Re: [linux-lvm] offtopic but ...

[Steven Lembark]

-- Benjamin Scott <bscott@ntisys.com>

>   Offline backups are for disaster recovery, not availability.  I think
> you're trying to say that, but the point is getting confused.  The
> difference between a small office's and a large bank's disaster recovery
> plans is the difference between their definitions of "disaster".  A small
> office probably considers a hard drive failure or OS corruption a
> "disaster".  A bank thinks more along the lines of "multiple terrorist
> attacks".

Actually they are more concerned about data corruption
and audits. The hardend offline facilities are about
being able to compare known data to what's online or
meet gov't requirements for audit background. Their rule
for designing systems is that any one box can get nuked
without bringing the whole thing down.

This is why I've gotten into the habit of differentiating
archival storage from backup systems. In most warehousing
systems people mean "redundant" when they say "backup" (e.g.,
"a backup power system") and "archival" or "offline" for
slow storage used to recover from data failures.

Aside: most places have plenty of ways to deal with hardware
failure. Unless they hire consultants, most never even think
about how they'll handle data corruption. Hmmm... how about
"You're not paranoid, the boxes ARE out to get you" as a
slogan?

--
Steven Lembark                               2930 W. Palmer
Workhorse Computing                       Chicago, IL 60647
                                            +1 800 762 1582

Re: [linux-lvm] offtopic but ...

[Goetz Bock]

On Mon, May 13 '02 at 11:24, Benjamin Scott wrote:
>   Hardware failure is not the leading cause of data loss.  User error is.
> 
>   All the RAID in the world will not help you if an operator deletes the
> wrong file.
Well, that's excatly what a REAL journaling filesystem is good for.
Unfortunately we don't have any of this, but than LVM comes in realy
handy.

"we're at 90% of disc space used on /dev/vg/home"

while "delete fome files" won't work
# lvextend +100G /dev/vg/home 
works. (but we'd need to be able to grow RAIDs than)

Just MHO,
    Goetz :-)

Re: [linux-lvm] offtopic but ...

[Benjamin Scott]

On Mon, 13 May 2002, at 10:30pm, Goetz Bock wrote:
>> Hardware failure is not the leading cause of data loss.  User error is.
>
> Well, that's excatly what a REAL journaling filesystem is good for.

  Sure.  But what happens when the operator erases the wrong filesystem?

  ;-)

-- 
Ben Scott <bscott@ntisys.com>
| The opinions expressed in this message are those of the author and do not |
| necessarily represent the views or policy of any other person, entity or  |
| organization.  All information is provided without warranty of any kind.  |

Re: [linux-lvm] offtopic but ...

[Goetz Bock]

On Mon, May 13 '02 at 19:55, Benjamin Scott wrote:
> On Mon, 13 May 2002, at 10:30pm, Goetz Bock wrote:
> >> Hardware failure is not the leading cause of data loss.  User error is.
> > Well, that's excatly what a REAL journaling filesystem is good for.
>   Sure.  But what happens when the operator erases the wrong filesystem?
Ooh, well ...

Than again: the unix philosophy allows you to shoot yourself
in your foot, if you realy want to/try.

Cu,
    Goetz.

Re: [linux-lvm] offtopic but ...

[Steven Lembark]

>> > Well, that's excatly what a REAL journaling filesystem is good for.
>>   Sure.  But what happens when the operator erases the wrong filesystem?
> Ooh, well ...

You mount take the read-only mirror of the data or bring
one of the alternate servers on line.


--
Steven Lembark                               2930 W. Palmer
Workhorse Computing                       Chicago, IL 60647
                                            +1 800 762 1582

Re: [linux-lvm] offtopic but ...

[Benjamin Scott]

On Tue, 14 May 2002, at 7:43am, Steven Lembark wrote:
> You mount take the read-only mirror of the data or bring one of the
> alternate servers on line.

  Exactly.  Keeping everything "live" is not acceptable, regardless of how
good your storage is.  The latencies involved in accessing offline systems
is a feature, not a bug: It is much harder to accidentally destroy an
offline copy than it does to destroy an online one.  If multiple offline
copies are stored in different locations inside locked vaults, accidental
destruction becomes very hard indeed.  :-)

-- 
Ben Scott <bscott@ntisys.com>
| The opinions expressed in this message are those of the author and do not |
| necessarily represent the views or policy of any other person, entity or  |
| organization.  All information is provided without warranty of any kind.  |

Re: [linux-lvm] offtopic but ...

[Tim]

>   Exactly.  Keeping everything "live" is not acceptable, regardless of how
> good your storage is.  The latencies involved in accessing offline systems
> is a feature, not a bug: It is much harder to accidentally destroy an
> offline copy than it does to destroy an online one.  If multiple offline
> copies are stored in different locations inside locked vaults, accidental
> destruction becomes very hard indeed.  :-)

More pointedly, so does on-purpose destruction.


-- 
    "The most valuable piece of equipment in the darkroom
     is the trash can."
                                  --Ansel Adams