Re: Is My Data DESTROYED?!

Re: Is My Data DESTROYED?!

[adfas asd]

--- On Tue, 10/27/09, Christian Pernegger <pernegger@gmail.com> wrote:
> Overkill much? Stick with something simple, it will serve
> you better
> in the end, especially when something fails. K.I.S.S.,
> remember?
> 
> Just rsync the two boxes already, with or without ssh.

So you're saying that rsync/rsnapshot can operate without the remote disk being shared?  I hadn't understood it that way.


      

Re: Is My Data DESTROYED?!

[John Robinson]

On 27/10/2009 21:08, adfas asd wrote:
> --- On Tue, 10/27/09, Christian Pernegger <pernegger@gmail.com> wrote:
>> Overkill much? Stick with something simple, it will serve
>> you better
>> in the end, especially when something fails. K.I.S.S.,
>> remember?
>>
>> Just rsync the two boxes already, with or without ssh.
> 
> So you're saying that rsync/rsnapshot can operate without the remote disk being shared?  I hadn't understood it that way.

Yes, the r in rsync stands for remote...

Perhaps if you'd try reading the f*cking manuals, and indeed listening 
here, instead of trying to tell all the genuine experts here that you 
know better?

Cheers,

John.

Re: Is My Data DESTROYED?!

[adfas asd]

--- On Tue, 10/27/09, John Robinson <john.robinson@anonymous.org.uk> wrote:
> Yes, the r in rsync stands for remote...

Ah yes I remember now, Remote was not the issue...  Security is.

 
> Perhaps if you'd try reading the f*cking manuals, and
> indeed listening here, instead of trying to tell all the
> genuine experts here that you know better?

So you prefer the Old Ways, ey grandpa.

Look, I recognize  true knowledge when I see it, and there's been alot of good advice here.  Why do you think I'm still here?  But rigor and excellence require a certain amount of pushing back.  This is something you have to understand.  

Substance;  over Style or the status quo.  And we drag guys like you along with us kicking and screaming, to benefit.




      

Re: Is My Data DESTROYED?!

[Christian Pernegger]

> > Yes, the r in rsync stands for remote...
>
> Ah yes I remember now, Remote was not the issue...  Security is.

Which is why rsync can use ssh as a transport ...

(Beats me why you'd need "security" for video data on your own LAN,
though. Well, maybe it's the principle of the thing.)

> But rigor and excellence require a certain amount of pushing back.  This is something you have to understand.

Ok, so you *are* just trolling.

Cheers,

C.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is My Data DESTROYED?!

[adfas asd]

--- On Tue, 10/27/09, Christian Pernegger <pernegger@gmail.com> wrote:
> > Ah yes I remember now, Remote was not the issue...
>  Security is.
> 
> Which is why rsync can use ssh as a transport ...
> 
> (Beats me why you'd need "security" for video data on your
> own LAN,
> though. Well, maybe it's the principle of the thing.)

You can't understand why I'd want LAN security for my /home directory?  Why not?


> > But rigor and excellence require a certain amount of
> pushing back.  This is something you have to
> understand.
> 
> Ok, so you *are* just trolling.

You apparently don't know what that means.

I guess this conversation's over.  We're not making any more progress, and only petulance is emerging.  I've offered some novel concepts, but many here are apparently too proud to admit we have advanced this concept.  I won't fight you.  Everybody's loss.  IOW fsck it, I have enough to do a great system now, without insults.




      

RE: Is My Data DESTROYED?!

[Guy Watkins]

} -----Original Message-----
} From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
} owner@vger.kernel.org] On Behalf Of Christian Pernegger
} Sent: Tuesday, October 27, 2009 5:31 PM
} To: adfas asd
} Cc: linux-raid@vger.kernel.org
} Subject: Re: Is My Data DESTROYED?!
} 
} > > Yes, the r in rsync stands for remote...
} >
} > Ah yes I remember now, Remote was not the issue...  Security is.
} 
} Which is why rsync can use ssh as a transport ...

lol he does not want anyone to steal his bootleg movies!

} 
} (Beats me why you'd need "security" for video data on your own LAN,
} though. Well, maybe it's the principle of the thing.)
} 
} > But rigor and excellence require a certain amount of pushing back.  This
} is something you have to understand.
} 
} Ok, so you *are* just trolling.

I figured he was a troll about 2 days ago.  NFS outdated!  Lol  Just tunnel
it with ssh.  Oh, ssh is not allowed.  If you want real security, you must
use an encrypted path.  If you don't care about encryption, just limit the
NFS mount to 1 IP address.

But I think rsync would be the smart way to go.  Using ssh if you care
enough about security.  I don't secure data over my network, but I do secure
access to my servers.  Don't care if my wife and kids figure out how to
sniff the network.  Would be really happy if they knew what I was talking
about!  :)

} 
} Cheers,
} 
} C.

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is My Data DESTROYED?!

[adfas asd]

--- On Tue, 10/27/09, Rudy Zijlstra <rudy@grumpydevil.homelinux.org> wrote:
> NFS/Samba are "bloated" as you call it, because

In my opinion they are bloated because they are outmoded and ancient.  FUSE instantly rendered them obsolete.

So sine iSCSI is out my next avenue of investigation is clustering filesystems.  They should have the file-locking problem solved, and should perform better than sshfs, much less NFS or SAMBA.


--- On Tue, 10/27/09, Ryan Wagoner <rswagoner@gmail.com> wrote:
> No NFS and Samba are not ancient bloatware. What other
> protocol would
> you use for a company file server? Rsync and SSH are not
> replacements for group file sharing.

As I say, sshfs.  Be officially turned on to FUSE and sshfs.  If you continue to decline, feel free to remain in the old-timey days grandpa.  (PS, I'm 55)


--- On Tue, 10/27/09, Bill Davidsen <davidsen@tmr.com> wrote:
> What's the problem? You generate a list of file
> checksums AND SIZES and
> do some percentage of it daily, or all of it weekly, or
> whatever
> pleases you. And every time you change or add a file you
> update the
> checksum file on the master, and send it off to the backup
> machine. Of
> course you verify on the master as well as the backup, just
> in case a
> file is damaged on the master. The nice thing about this is
> that it can
> all be automated and can send you email saying that some
> number of
> files were checked and were okay, or were not okay.
> 
> If it were my problem I would invest in two Gbit cards per
> machine, two
> *good* cables, and configure for jumbo frames. That gives
> you over
> 200MB/s transfer rate using rsync, runs over ssh by default
> for
> security, does checksums by default for reliability, should
> give you a
> nice safe copy which you can verify using the checksum
> file.

Very nice Bill, but I don't know the best way to go about these things.  This is why I keep asking for specifics.  Maybe if you pretend that I'm a dumb real estate developer...




      

Re: Is My Data DESTROYED?!

[Ryan Wagoner]

On Tue, Oct 27, 2009 at 4:31 PM, adfas asd <chimera_god@yahoo.com> wrote:
> --- On Tue, 10/27/09, Rudy Zijlstra <rudy@grumpydevil.homelinux.org> wrote:
>> NFS/Samba are "bloated" as you call it, because
>
> In my opinion they are bloated because they are outmoded and ancient.  FUSE instantly rendered them obsolete.
>
> So sine iSCSI is out my next avenue of investigation is clustering filesystems.  They should have the file-locking problem solved, and should perform better than sshfs, much less NFS or SAMBA.

You need iSCSI to export the clustered file system. The only
difference is a clustered file system lets more than one computer
mount it. This should work in your situation, but you'll have to setup
fencing correctly.

Still in the end-user file sharing scenario SMB and NFS still are the
best methods. I'm not going to deal with a clustered file system for
hundreds of users. Fuse hasn't been widely adopted in the end-user
world especially with Windows clients, etc.

>
>
> --- On Tue, 10/27/09, Ryan Wagoner <rswagoner@gmail.com> wrote:
>> No NFS and Samba are not ancient bloatware. What other
>> protocol would
>> you use for a company file server? Rsync and SSH are not
>> replacements for group file sharing.
>
> As I say, sshfs.  Be officially turned on to FUSE and sshfs.  If you continue to decline, feel free to remain in the old-timey days grandpa.  (PS, I'm 55)
>
>
> --- On Tue, 10/27/09, Bill Davidsen <davidsen@tmr.com> wrote:
>> What's the problem? You generate a list of file
>> checksums AND SIZES and
>> do some percentage of it daily, or all of it weekly, or
>> whatever
>> pleases you. And every time you change or add a file you
>> update the
>> checksum file on the master, and send it off to the backup
>> machine. Of
>> course you verify on the master as well as the backup, just
>> in case a
>> file is damaged on the master. The nice thing about this is
>> that it can
>> all be automated and can send you email saying that some
>> number of
>> files were checked and were okay, or were not okay.
>>
>> If it were my problem I would invest in two Gbit cards per
>> machine, two
>> *good* cables, and configure for jumbo frames. That gives
>> you over
>> 200MB/s transfer rate using rsync, runs over ssh by default
>> for
>> security, does checksums by default for reliability, should
>> give you a
>> nice safe copy which you can verify using the checksum
>> file.
>
> Very nice Bill, but I don't know the best way to go about these things.  This is why I keep asking for specifics.  Maybe if you pretend that I'm a dumb real estate developer...
>
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is My Data DESTROYED?!

[Christian Pernegger]

>So sine iSCSI is out my next avenue of investigation is clustering filesystems.

Overkill much? Stick with something simple, it will serve you better
in the end, especially when something fails. K.I.S.S., remember?

Just rsync the two boxes already, with or without ssh. That's assuming
the data is mostly static (videos). If you have other data as well you
might want to use rdiff-backup for that, as it can keep multiple
versions.

Get some kind of backplane for the disks so you can swap them out
without powering down the box. (Not because you can't live with 10min
downtime when a disk fails but because you don't want to spin down the
*other* disks.)

Bonus: If the primary server fails but its disks are fine you can just
stick all of them in the backup server temporarily, boot and be up and
running almost immediately.

Cheers,

C.

RE: Is My Data DESTROYED?!

[Leslie Rhorer]

> Just rsync the two boxes already, with or without ssh. That's assuming
> the data is mostly static (videos). If you have other data as well you
> might want to use rdiff-backup for that, as it can keep multiple
> versions.
> 
> Get some kind of backplane for the disks so you can swap them out
> without powering down the box. (Not because you can't live with 10min
> downtime when a disk fails but because you don't want to spin down the
> *other* disks.)
> 
> Bonus: If the primary server fails but its disks are fine you can just
> stick all of them in the backup server temporarily, boot and be up and
> running almost immediately.

	Well, depending on the system and exactly what dies, it may be
simpler just to fix or replace the server.  The big bonus comes when the
primary array fails, though.  If the OS files and directories (/boot, /etc,
/var, /home, etc.) are all on a separate drive system and the primary array
contains only application data, then upon total failure of the primary
array, one may simply umount the main array and use NFS to temporarily mount
the remote file system wherever the primary array used to be.  The entire
production system is then up and running as usual, while the sysadmin
figures out what the heck went wrong with the primary array.  When the array
is fixed, an rsync (hopefully a brief one) can copy all the new / changed
files to the main array.  Then umount the NFS share and mount the main array
again.

RE: Is My Data DESTROYED?!

[Rudy Zijlstra]

Op dinsdag 27-10-2009 om 19:39 uur [tijdzone -0500], schreef Leslie
Rhorer:
> > Just rsync the two boxes already, with or without ssh. That's assuming
> > the data is mostly static (videos). If you have other data as well you
> > might want to use rdiff-backup for that, as it can keep multiple
> > versions.
> > 
> > Get some kind of backplane for the disks so you can swap them out
> > without powering down the box. (Not because you can't live with 10min
> > downtime when a disk fails but because you don't want to spin down the
> > *other* disks.)
> > 
> > Bonus: If the primary server fails but its disks are fine you can just
> > stick all of them in the backup server temporarily, boot and be up and
> > running almost immediately.
> 
> 	Well, depending on the system and exactly what dies, it may be
> simpler just to fix or replace the server.  The big bonus comes when the
> primary array fails, though.  If the OS files and directories (/boot, /etc,
> /var, /home, etc.) are all on a separate drive system and the primary array
> contains only application data, then upon total failure of the primary
> array, one may simply umount the main array and use NFS to temporarily mount
> the remote file system wherever the primary array used to be.  The entire
> production system is then up and running as usual, while the sysadmin
> figures out what the heck went wrong with the primary array.  When the array
> is fixed, an rsync (hopefully a brief one) can copy all the new / changed
> files to the main array.  Then umount the NFS share and mount the main array
> again.
> 

Agreed. Just a pity the OP thinks NFS is useless old bloadware.... 

Rudy

Re: Is My Data DESTROYED?!

[adfas asd]

You know, I was worried that my main HTPC would be overloaded, with Myth commercial flagging, transcoding, and storage server operations like ssh encryption and checksumming.  

But clearly storage server operations should be carried out by the storage server.  This'll be a little qbox-f mini-ITX system in the garage in case of fire or theft.  So I could iSCSI the HTPC's RAID0 volume to the storage server, hopefully through an SSH tunnel, and the storage server could merrily do the rsync, checksumming, and whatever operations, while the HTPC does its proper jobs.  When not in use the storage server would sleep.  Sure, the storage server will be just an Atom or Geode, but as long as its operations don't take more than 24 hours it's OK.


--- On Mon, 10/26/09, adfas asd <chimera_god@yahoo.com> wrote:
> Thanks Doug, this was very
> helpful.  I had seen the checksum option, but sometimes
> something doesn't register as useful unless there is
> independent confirmation. 
> 
> And understand that I am not 'shooting down' anything to be
> obstinate;  I am testing and probing for the -best-
> solution and systems, and hoping something good pops
> out.  Some of the sensitive will take offense, but I
> suggest that all benefit when we get substantive responses
> such as yours.
> 
> I had tried afio and cpio in the past, but frankly could
> not figure it out to use.  Seems like a good
> concept.  Maybe it's been made more accessible by now,
> or maybe I'm not as dumb.  BTW, I am a real estate
> developer, not a coder.



      

Re: Is My Data DESTROYED?!

[Thomas Fjellstrom]

On Mon October 26 2009, adfas asd wrote:
> You know, I was worried that my main HTPC would be overloaded, with Myth
>  commercial flagging, transcoding, and storage server operations like ssh
>  encryption and checksumming.
> 
> But clearly storage server operations should be carried out by the storage
>  server.  This'll be a little qbox-f mini-ITX system in the garage in case
>  of fire or theft.  So I could iSCSI the HTPC's RAID0 volume to the storage
>  server, hopefully through an SSH tunnel, and the storage server could
>  merrily do the rsync, checksumming, and whatever operations, while the
>  HTPC does its proper jobs.  When not in use the storage server would
>  sleep.  Sure, the storage server will be just an Atom or Geode, but as
>  long as its operations don't take more than 24 hours it's OK.

Issue there, you can not mount a regular filesystem twice. Which is what this 
plan would entail. It'd be better if you just used rsync's native ssh support 
to log in and copy entire directory trees of data.

The initial copy will take a while, but rsync will only copy files that are 
new, or have changed by default, so subsequent rsync runs won't take very long 
over GbE at all.

on your backup box, you can just run:
rsync -a user@mythtvbox:/mnt/raid0 /mnt/backup

which tells rsync to copy all files under 'mythtvbox's /mnt/raid0 dir 
recursively to /mnt/backup keeping all metadata including access times and 
what not. (-a means archive, this way it will know when files have changed on 
the remote mythtv box)

hth.

> --- On Mon, 10/26/09, adfas asd <chimera_god@yahoo.com> wrote:
> > Thanks Doug, this was very
> > helpful.  I had seen the checksum option, but sometimes
> > something doesn't register as useful unless there is
> > independent confirmation.
> >
> > And understand that I am not 'shooting down' anything to be
> > obstinate;  I am testing and probing for the -best-
> > solution and systems, and hoping something good pops
> > out.  Some of the sensitive will take offense, but I
> > suggest that all benefit when we get substantive responses
> > such as yours.
> >
> > I had tried afio and cpio in the past, but frankly could
> > not figure it out to use.  Seems like a good
> > concept.  Maybe it's been made more accessible by now,
> > or maybe I'm not as dumb.  BTW, I am a real estate
> > developer, not a coder.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Thomas Fjellstrom
tfjellstrom@shaw.ca

Re: Is My Data DESTROYED?!

[adfas asd]

Thanks.  But what I have in mind is serving the HTPC's array (with videos)to the storage server via iSCSI.  Hopefully the array can be mounted on the HTPS and still be served to the remote storage server by iSCSI?

--- On Mon, 10/26/09, Thomas Fjellstrom <tfjellstrom@shaw.ca> wrote:
> On Mon October 26 2009, adfas asd
> wrote:
> > You know, I was worried that my main HTPC would be
> overloaded, with Myth
> >  commercial flagging, transcoding, and storage
> server operations like ssh
> >  encryption and checksumming.
> > 
> > But clearly storage server operations should be
> carried out by the storage
> >  server.  This'll be a little qbox-f
> mini-ITX system in the garage in case
> >  of fire or theft.  So I could iSCSI the
> HTPC's RAID0 volume to the storage
> >  server, hopefully through an SSH tunnel, and the
> storage server could
> >  merrily do the rsync, checksumming, and whatever
> operations, while the
> >  HTPC does its proper jobs.  When not in use
> the storage server would
> >  sleep.  Sure, the storage server will be
> just an Atom or Geode, but as
> >  long as its operations don't take more than 24
> hours it's OK.
> 
> Issue there, you can not mount a regular filesystem twice.
> Which is what this 
> plan would entail. It'd be better if you just used rsync's
> native ssh support 
> to log in and copy entire directory trees of data.
> 
> The initial copy will take a while, but rsync will only
> copy files that are 
> new, or have changed by default, so subsequent rsync runs
> won't take very long 
> over GbE at all.
> 
> on your backup box, you can just run:
> rsync -a user@mythtvbox:/mnt/raid0 /mnt/backup
> 
> which tells rsync to copy all files under 'mythtvbox's
> /mnt/raid0 dir 
> recursively to /mnt/backup keeping all metadata including
> access times and 
> what not. (-a means archive, this way it will know when
> files have changed on 
> the remote mythtv box)



      

Re: Is My Data DESTROYED?!

[Gabor Gombas]

On Tue, Oct 27, 2009 at 07:32:52AM -0700, adfas asd wrote:

> Thanks.  But what I have in mind is serving the HTPC's array (with
> videos)to the storage server via iSCSI.  Hopefully the array can be
> mounted on the HTPS and still be served to the remote storage server
> by iSCSI?

No. You either mount the fs locally _or_ export it via iSCSI. You can't
do both simultaneously. If you want to access the files from both
locations, you have to use NFS or Samba (or a distributed file system,
but that's IMHO way too complicated for your setup).

Gabor

-- 
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------

Re: Is My Data DESTROYED?!

[adfas asd]

--- On Tue, 10/27/09, Gabor Gombas <gombasg@sztaki.hu> wrote:
> > Thanks.  But what I have in mind is serving the
> HTPC's array (with
> > videos)to the storage server via iSCSI. 
> Hopefully the array can be
> > mounted on the HTPS and still be served to the remote
> storage server
> > by iSCSI?
> 
> No. You either mount the fs locally _or_ export it via
> iSCSI. You can't
> do both simultaneously. If you want to access the files
> from both
> locations, you have to use NFS or Samba (or a distributed
> file system,
> but that's IMHO way too complicated for your setup).

Oh no.  Well I don't see the point of iSCSI then.

I wouldn't even consider NFS or Samba because they are ancient bloatware.  I gather from a prior post that rsync has a remote ssh function.  If that's not the case then I guess it has to be sshfs.



      

Re: Is My Data DESTROYED?!

[Ryan Wagoner]

On Tue, Oct 27, 2009 at 10:40 AM, adfas asd <chimera_god@yahoo.com> wrote:
> --- On Tue, 10/27/09, Gabor Gombas <gombasg@sztaki.hu> wrote:
>> > Thanks.  But what I have in mind is serving the
>> HTPC's array (with
>> > videos)to the storage server via iSCSI.
>> Hopefully the array can be
>> > mounted on the HTPS and still be served to the remote
>> storage server
>> > by iSCSI?
>>
>> No. You either mount the fs locally _or_ export it via
>> iSCSI. You can't
>> do both simultaneously. If you want to access the files
>> from both
>> locations, you have to use NFS or Samba (or a distributed
>> file system,
>> but that's IMHO way too complicated for your setup).
>
> Oh no.  Well I don't see the point of iSCSI then.

iSCSI is a block level protocol while NFS and Samba work at the file
level. They all have their specific uses and advantages /
disadvantages.

>
> I wouldn't even consider NFS or Samba because they are ancient bloatware.  I gather from a prior post that rsync has a remote ssh function.  If that's not the case then I guess it has to be sshfs.

No NFS and Samba are not ancient bloatware. What other protocol would
you use for a company file server? Rsync and SSH are not replacements
for group file sharing.

Just use rsync over SSH. Simple and reliable.

>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is My Data DESTROYED?!

[Lars Schimmer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ryan Wagoner wrote:

> iSCSI is a block level protocol while NFS and Samba work at the file
> level. They all have their specific uses and advantages /
> disadvantages.
> 
>> I wouldn't even consider NFS or Samba because they are ancient bloatware.  I gather from a prior post that rsync has a remote ssh function.  If that's not the case then I guess it has to be sshfs.
> 
> No NFS and Samba are not ancient bloatware. What other protocol would
> you use for a company file server? Rsync and SSH are not replacements
> for group file sharing.
> 
> Just use rsync over SSH. Simple and reliable.

Openafs - http://www.openafs.org


MfG,
Lars Schimmer
- --
- -------------------------------------------------------------
TU Graz, Institut für ComputerGraphik & WissensVisualisierung
Tel: +43 316 873-5405       E-Mail: l.schimmer@cgv.tugraz.at
Fax: +43 316 873-5402       PGP-Key-ID: 0x4A9B1723
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkroE/UACgkQmWhuE0qbFyMUrQCdHe0IWxN48CRSsaYtdHppuj2y
gTkAoImQEOR10Cl20aQMPulrPCD4Yexp
=cs7w
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is My Data DESTROYED?!

[Bill Davidsen]

adfas asd wrote:
> Thanks.  But what I have in mind is serving the HTPC's array (with videos)to the storage server via iSCSI.  Hopefully the array can be mounted on the HTPS and still be served to the remote storage server by iSCSI?
>   

One more time, if you mount the backup copy on the main server it will 
then be subject to the same failure issues as a mirror. You want to use 
something like rsync to backup over network, and the function of the 
backup server isn't going to be to serve other than in case of 
emergency. You don't want to serve, to mount, to do anything which will 
let filesystem, OS, or user errors propagate to the backup copy.

Other than the reliability issue if you mount, there's no reason to 
avoid things like NFS, they are well tested but not stagnant, getting 
significant upgrades a few years ago and regular minor glitch fixes for 
corner cases. In general cutting edge and reliable is not the most 
probable combination. While NFS is widely used and maintained, protocols 
like AFS, iSCSI and sshfs are used by fewer sites, and perhaps more 
experienced administrators, so perhaps they are less tested, 
particularly in the area of less than optimal setup.

Boring and uneventful is what you want in a backup system.

-- 
Bill Davidsen <davidsen@tmr.com>
  Unintended results are the well-earned reward for incompetence.

Re: Is My Data DESTROYED?!

[adfas asd]

You're not understanding.

I plan for the **storage server** to mount the RAID0 volume on the HTPC (shared), so the **storage server** can do all backup and checking operations.  This should be a job for the storage server, not the HTPC.  The HTPC should/will perform all video duties.

And NFS/Samba are out.  O-U-T, OUT.  Old-and-busted.  Useful like a washboard.  Many years ago I vowed that I would never learn two things:  automatic transmissions, and NFS.  I did learn and use Samba for some years, but now it is old-and-busted.  sshfs has served me well over the past year and a half, under rigorous conditions.  It is limited though by CPU consumption for encryption.  This is why I will investigate clustering filesystems and FUSE options.


--- On Tue, 10/27/09, Bill Davidsen <davidsen@tmr.com> wrote:
> One more time, if you mount the backup copy on the main
> server it will then be subject to the same failure issues as
> a mirror. You want to use something like rsync to backup
> over network, and the function of the backup server isn't
> going to be to serve other than in case of emergency. You
> don't want to serve, to mount, to do anything which will let
> filesystem, OS, or user errors propagate to the backup
> copy.
> 
> Other than the reliability issue if you mount, there's no
> reason to avoid things like NFS, they are well tested but
> not stagnant, getting significant upgrades a few years ago
> and regular minor glitch fixes for corner cases. In general
> cutting edge and reliable is not the most probable
> combination. While NFS is widely used and maintained,
> protocols like AFS, iSCSI and sshfs are used by fewer sites,
> and perhaps more experienced administrators, so perhaps they
> are less tested, particularly in the area of less than
> optimal setup.
> 
> Boring and uneventful is what you want in a backup system.
> 
> -- Bill Davidsen <davidsen@tmr.com>
>  Unintended results are the well-earned reward for
> incompetence.
> 
> 


      

Re: Is My Data DESTROYED?!

[Ryan Wagoner]

On Tue, Oct 27, 2009 at 4:53 PM, adfas asd <chimera_god@yahoo.com> wrote:
> You're not understanding.
>
> I plan for the **storage server** to mount the RAID0 volume on the HTPC (shared), so the **storage server** can do all backup and checking operations.  This should be a job for the storage server, not the HTPC.  The HTPC should/will perform all video duties.

I think you are way over complicating this. NFS would do this with a single line

On the HTPC you add to /etc/exports the following line (replace things
appropriately) and start nfs
/data 192.168.1.10 (rw,async,no_root_squash)

Then on the storage server mount the nfs export
mount htpc:/data /local/path

>
> And NFS/Samba are out.  O-U-T, OUT.  Old-and-busted.  Useful like a washboard.  Many years ago I vowed that I would never learn two things:  automatic transmissions, and NFS.  I did learn and use Samba for some years, but now it is old-and-busted.  sshfs has served me well over the past year and a half, under rigorous conditions.  It is limited though by CPU consumption for encryption.  This is why I will investigate clustering filesystems and FUSE options.
>
>
> --- On Tue, 10/27/09, Bill Davidsen <davidsen@tmr.com> wrote:
>> One more time, if you mount the backup copy on the main
>> server it will then be subject to the same failure issues as
>> a mirror. You want to use something like rsync to backup
>> over network, and the function of the backup server isn't
>> going to be to serve other than in case of emergency. You
>> don't want to serve, to mount, to do anything which will let
>> filesystem, OS, or user errors propagate to the backup
>> copy.
>>
>> Other than the reliability issue if you mount, there's no
>> reason to avoid things like NFS, they are well tested but
>> not stagnant, getting significant upgrades a few years ago
>> and regular minor glitch fixes for corner cases. In general
>> cutting edge and reliable is not the most probable
>> combination. While NFS is widely used and maintained,
>> protocols like AFS, iSCSI and sshfs are used by fewer sites,
>> and perhaps more experienced administrators, so perhaps they
>> are less tested, particularly in the area of less than
>> optimal setup.
>>
>> Boring and uneventful is what you want in a backup system.
>>
>> -- Bill Davidsen <davidsen@tmr.com>
>>  Unintended results are the well-earned reward for
>> incompetence.
>>
>>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is My Data DESTROYED?!

[adfas asd]

--- On Tue, 10/27/09, Ryan Wagoner <rswagoner@gmail.com> wrote:
> I think you are way over complicating this. NFS would do
> this with a single line

Well, with sshfs no lines/thinking allowed, assuming SSH is set up properly.  Just in fstab:
sshfs#bill@hex:/	/media/hex	fuse	user,auto,gid=6,umask=007,cache=no,ServerAliveInterval=15,reconnect,allow_other,comment=sshfs 0 0
... and any remote disk is mounted automatically on boot, served through a military-grade encrypted tunnel.  I have no time to learn all the security implications of NFS and pals.

I'm just trying to help the heathens...


      

Re: Is My Data DESTROYED?!

[adfas asd]

I don't understand exactly what it is to be done.  If I can mount using a different superblock, do I then remove one of the drives from the array so I can put that drive away with my data until I can buy another drive to back up the data to?  If so, how?

How is it that the superblock on -both- drives got destroyed?  Isn't RAID10 supposed to be mirrored?

--- On Thu, 10/22/09, Majed B. <majedb@gmail.com> wrote:

> From: Majed B. <majedb@gmail.com>
> Subject: Re: Is My Data DESTROYED?!
> To: "adfas asd" <chimera_god@yahoo.com>
> Cc: linux-raid@vger.kernel.org
> Date: Thursday, October 22, 2009, 7:12 PM
> If you have bad sectors here
> & there, and you didn't read the areas where the bad
> sectors are, you won't get read errors.
> 
> That's why you should always have smartd running along
> with periodic sync_action -> check to force mdadm to
> check the array.
> 
> 
> 
> There's still hope in recovering your data. Don't
> despair.
> 
> On Fri, Oct 23, 2009 at 5:04 AM,
> adfas asd <chimera_god@yahoo.com>
> wrote:
> 
> 
> How could this possibly have
> happened?  The whole idea of RAID is so something like this
> won't happen.
> 
> 
> 
> 
> 
> I was using JFS.
> 
> 
> 
> I've lost confidence now in mdadm.  I have too much
> data to back up practically, and am now at a loss.
> 
> 
> 
> 
> 
> --- On Thu, 10/22/09, Majed B. <majedb@gmail.com>
> wrote:
> 
> 
> 
> > From: Majed B. <majedb@gmail.com>
> 
> > Subject: Re: Is My Data
> DESTROYED?!
> 
> > To: "adfas asd" <chimera_god@yahoo.com>
> 
> > Cc: linux-raid@vger.kernel.org
> 
> > Date: Thursday, October 22, 2009, 6:40 PM
> 
> > Seems like your
> filesystem is
> 
> > corrupted. Some filesystems have alternative
> superblocks.
> 
> >
> 
> > you can mount your filesystem using an alternative
> 
> > superblock using: mount -o sb=<offset>
> 
> > You find the offset value by running a dry-run (test)
> of
> 
> > mkfs on your drives. It will print multiple offsets
> for
> 
> > superblocks.
> 
> >
> 
> >
> 
> >
> 
> > On Fri, Oct 23, 2009 at 4:36 AM,
> 
> > adfas asd <chimera_god@yahoo.com>
> 
> > wrote:
> 
> >
> 
> >
> 
> > Today I went in to my HTPC, to find it was hung and
> the
> 
> > drive light was stuck on.  After all attempts to
> revive it
> 
> > or switch to terminal 2 or 3 had failed I reset the
> system.
> 
> >
> 
> >
> 
> >
> 
> > It rebooted to tell me that it cannot mount /home,
> the
> 
> > RAID10offset2 device.
> 
> >
> 
> >
> 
> >
> 
> > When I reboot in recovery mode and try to mount
> /dev/md0
> 
> > manually it informs me there is an invalid superblock!
>  I
> 
> > shut down and unplugged each drive in turn, and
> /proc/mdstat
> 
> > shows the appropriate volume gone, but still can't
> mount
> 
> > the array.
> 
> >
> 
> >
> 
> >
> 
> >
> 
> >
> 
> > What has happened here?  Is all my data destroyed?
> 
> >
> 
> >
> 
> >
> 
> >
> 
> >
> 
> >
> 
> >
> 
> > --
> 
> >
> 
> > To unsubscribe from this list: send the line
> 
> > "unsubscribe linux-raid" in
> 
> >
> 
> > the body of a message to majordomo@vger.kernel.org
> 
> >
> 
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> >
> 
> >
> 
> >
> 
> >
> 
> > --
> 
> >        Majed B.
> 
> >
> 
> >
> 
> >
> 
> 
> 
> 
> 
> 
> 
> --
> 
> To unsubscribe from this list: send the line
> "unsubscribe linux-raid" in
> 
> the body of a message to majordomo@vger.kernel.org
> 
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 
> 
> -- 
>        Majed B.
> 
> 
> 


      

Re: Is My Data DESTROYED?!

[Majed B.]

I don't know exactly what went wrong with your setup, so I can't tell
why it's not mounting.

Did you check the output of dmesg | tail after a failed mount?

I'd suggest that you don't touch the disks, cables, nor the array.

Try running sudo fsck /dev/md0

On Fri, Oct 23, 2009 at 5:18 AM, adfas asd <chimera_god@yahoo.com> wrote:
>
> I don't understand exactly what it is to be done.  If I can mount using a different superblock, do I then remove one of the drives from the array so I can put that drive away with my data until I can buy another drive to back up the data to?  If so, how?
>
> How is it that the superblock on -both- drives got destroyed?  Isn't RAID10 supposed to be mirrored?
>
> --- On Thu, 10/22/09, Majed B. <majedb@gmail.com> wrote:
>
> > From: Majed B. <majedb@gmail.com>
> > Subject: Re: Is My Data DESTROYED?!
> > To: "adfas asd" <chimera_god@yahoo.com>
> > Cc: linux-raid@vger.kernel.org
> > Date: Thursday, October 22, 2009, 7:12 PM
> > If you have bad sectors here
> > & there, and you didn't read the areas where the bad
> > sectors are, you won't get read errors.
> >
> > That's why you should always have smartd running along
> > with periodic sync_action -> check to force mdadm to
> > check the array.
> >
> >
> >
> > There's still hope in recovering your data. Don't
> > despair.
> >
> > On Fri, Oct 23, 2009 at 5:04 AM,
> > adfas asd <chimera_god@yahoo.com>
> > wrote:
> >
> >
> > How could this possibly have
> > happened?  The whole idea of RAID is so something like this
> > won't happen.
> >
> >
> >
> >
> >
> > I was using JFS.
> >
> >
> >
> > I've lost confidence now in mdadm.  I have too much
> > data to back up practically, and am now at a loss.
> >
> >
> >
> >
> >
> > --- On Thu, 10/22/09, Majed B. <majedb@gmail.com>
> > wrote:
> >
> >
> >
> > > From: Majed B. <majedb@gmail.com>
> >
> > > Subject: Re: Is My Data
> > DESTROYED?!
> >
> > > To: "adfas asd" <chimera_god@yahoo.com>
> >
> > > Cc: linux-raid@vger.kernel.org
> >
> > > Date: Thursday, October 22, 2009, 6:40 PM
> >
> > > Seems like your
> > filesystem is
> >
> > > corrupted. Some filesystems have alternative
> > superblocks.
> >
> > >
> >
> > > you can mount your filesystem using an alternative
> >
> > > superblock using: mount -o sb=<offset>
> >
> > > You find the offset value by running a dry-run (test)
> > of
> >
> > > mkfs on your drives. It will print multiple offsets
> > for
> >
> > > superblocks.
> >
> > >
> >
> > >
> >
> > >
> >
> > > On Fri, Oct 23, 2009 at 4:36 AM,
> >
> > > adfas asd <chimera_god@yahoo.com>
> >
> > > wrote:
> >
> > >
> >
> > >
> >
> > > Today I went in to my HTPC, to find it was hung and
> > the
> >
> > > drive light was stuck on.  After all attempts to
> > revive it
> >
> > > or switch to terminal 2 or 3 had failed I reset the
> > system.
> >
> > >
> >
> > >
> >
> > >
> >
> > > It rebooted to tell me that it cannot mount /home,
> > the
> >
> > > RAID10offset2 device.
> >
> > >
> >
> > >
> >
> > >
> >
> > > When I reboot in recovery mode and try to mount
> > /dev/md0
> >
> > > manually it informs me there is an invalid superblock!
> >  I
> >
> > > shut down and unplugged each drive in turn, and
> > /proc/mdstat
> >
> > > shows the appropriate volume gone, but still can't
> > mount
> >
> > > the array.
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > > What has happened here?  Is all my data destroyed?
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > > --
> >
> > >
> >
> > > To unsubscribe from this list: send the line
> >
> > > "unsubscribe linux-raid" in
> >
> > >
> >
> > > the body of a message to majordomo@vger.kernel.org
> >
> > >
> >
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > > --
> >
> > >        Majed B.
> >
> > >
> >
> > >
> >
> > >
> >
> >
> >
> >
> >
> >
> >
> > --
> >
> > To unsubscribe from this list: send the line
> > "unsubscribe linux-raid" in
> >
> > the body of a message to majordomo@vger.kernel.org
> >
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> >
> >
> >
> > --
> >        Majed B.
> >
> >
> >
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
      Majed B.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is My Data DESTROYED?!

[adfas asd]

When I was trying to find man for mkfs.jfs I discovered that jfsutils was suddenly not installed.  I installed it and then could man mkfs.jfs .

I rebooted so I could plug in the second drive, and then md0 was getting mounted on /home as it should.  Indeed I have all my data again.  I don't understand what happened.


--- On Thu, 10/22/09, Majed B. <majedb@gmail.com> wrote:

> From: Majed B. <majedb@gmail.com>
> Subject: Re: Is My Data DESTROYED?!
> To: "adfas asd" <chimera_god@yahoo.com>
> Cc: linux-raid@vger.kernel.org
> Date: Thursday, October 22, 2009, 7:43 PM
> I don't know exactly what went wrong
> with your setup, so I can't tell
> why it's not mounting.
> 
> Did you check the output of dmesg | tail after a failed
> mount?
> 
> I'd suggest that you don't touch the disks, cables, nor the
> array.
> 
> Try running sudo fsck /dev/md0
> 
> On Fri, Oct 23, 2009 at 5:18 AM, adfas asd <chimera_god@yahoo.com>
> wrote:
> >
> > I don't understand exactly what it is to be done.  If
> I can mount using a different superblock, do I then remove
> one of the drives from the array so I can put that drive
> away with my data until I can buy another drive to back up
> the data to?  If so, how?
> >
> > How is it that the superblock on -both- drives got
> destroyed?  Isn't RAID10 supposed to be mirrored?
> >
> > --- On Thu, 10/22/09, Majed B. <majedb@gmail.com>
> wrote:
> >
> > > From: Majed B. <majedb@gmail.com>
> > > Subject: Re: Is My Data DESTROYED?!
> > > To: "adfas asd" <chimera_god@yahoo.com>
> > > Cc: linux-raid@vger.kernel.org
> > > Date: Thursday, October 22, 2009, 7:12 PM
> > > If you have bad sectors here
> > > & there, and you didn't read the areas where
> the bad
> > > sectors are, you won't get read errors.
> > >
> > > That's why you should always have smartd running
> along
> > > with periodic sync_action -> check to force
> mdadm to
> > > check the array.
> > >
> > >
> > >
> > > There's still hope in recovering your data.
> Don't
> > > despair.
> > >
> > > On Fri, Oct 23, 2009 at 5:04 AM,
> > > adfas asd <chimera_god@yahoo.com>
> > > wrote:
> > >
> > >
> > > How could this possibly have
> > > happened?  The whole idea of RAID is so
> something like this
> > > won't happen.
> > >
> > >
> > >
> > >
> > >
> > > I was using JFS.
> > >
> > >
> > >
> > > I've lost confidence now in mdadm.  I have too
> much
> > > data to back up practically, and am now at a
> loss.
> > >
> > >
> > >
> > >
> > >
> > > --- On Thu, 10/22/09, Majed B. <majedb@gmail.com>
> > > wrote:
> > >
> > >
> > >
> > > > From: Majed B. <majedb@gmail.com>
> > >
> > > > Subject: Re: Is My Data
> > > DESTROYED?!
> > >
> > > > To: "adfas asd" <chimera_god@yahoo.com>
> > >
> > > > Cc: linux-raid@vger.kernel.org
> > >
> > > > Date: Thursday, October 22, 2009, 6:40 PM
> > >
> > > > Seems like your
> > > filesystem is
> > >
> > > > corrupted. Some filesystems have
> alternative
> > > superblocks.
> > >
> > > >
> > >
> > > > you can mount your filesystem using an
> alternative
> > >
> > > > superblock using: mount -o
> sb=<offset>
> > >
> > > > You find the offset value by running a
> dry-run (test)
> > > of
> > >
> > > > mkfs on your drives. It will print multiple
> offsets
> > > for
> > >
> > > > superblocks.
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > On Fri, Oct 23, 2009 at 4:36 AM,
> > >
> > > > adfas asd <chimera_god@yahoo.com>
> > >
> > > > wrote:
> > >
> > > >
> > >
> > > >
> > >
> > > > Today I went in to my HTPC, to find it was
> hung and
> > > the
> > >
> > > > drive light was stuck on.  After all
> attempts to
> > > revive it
> > >
> > > > or switch to terminal 2 or 3 had failed I
> reset the
> > > system.
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > It rebooted to tell me that it cannot mount
> /home,
> > > the
> > >
> > > > RAID10offset2 device.
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > When I reboot in recovery mode and try to
> mount
> > > /dev/md0
> > >
> > > > manually it informs me there is an invalid
> superblock!
> > >  I
> > >
> > > > shut down and unplugged each drive in turn,
> and
> > > /proc/mdstat
> > >
> > > > shows the appropriate volume gone, but still
> can't
> > > mount
> > >
> > > > the array.
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > What has happened here?  Is all my data
> destroyed?
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > --
> > >
> > > >
> > >
> > > > To unsubscribe from this list: send the
> line
> > >
> > > > "unsubscribe linux-raid" in
> > >
> > > >
> > >
> > > > the body of a message to majordomo@vger.kernel.org
> > >
> > > >
> > >
> > > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > --
> > >
> > > >        Majed B.
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > >
> > > To unsubscribe from this list: send the line
> > > "unsubscribe linux-raid" in
> > >
> > > the body of a message to majordomo@vger.kernel.org
> > >
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > >
> > >
> > >
> > >
> > > --
> > >        Majed B.
> > >
> > >
> > >
> >
> >
> >
> > --
> > To unsubscribe from this list: send the line
> "unsubscribe linux-raid" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 
> --
>       Majed B.
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


      

Re: Is My Data DESTROYED?!

[Majed B.]

Since you noticed that the utils were gone, seems like JFS libs &
programs were uninstalled/deleted.

Now that you have them back, you're able to mount the filesystem normally.

On Fri, Oct 23, 2009 at 5:59 AM, adfas asd <chimera_god@yahoo.com> wrote:
> When I was trying to find man for mkfs.jfs I discovered that jfsutils was suddenly not installed.  I installed it and then could man mkfs.jfs .
>
> I rebooted so I could plug in the second drive, and then md0 was getting mounted on /home as it should.  Indeed I have all my data again.  I don't understand what happened.
>
>
> --- On Thu, 10/22/09, Majed B. <majedb@gmail.com> wrote:
>
>> From: Majed B. <majedb@gmail.com>
>> Subject: Re: Is My Data DESTROYED?!
>> To: "adfas asd" <chimera_god@yahoo.com>
>> Cc: linux-raid@vger.kernel.org
>> Date: Thursday, October 22, 2009, 7:43 PM
>> I don't know exactly what went wrong
>> with your setup, so I can't tell
>> why it's not mounting.
>>
>> Did you check the output of dmesg | tail after a failed
>> mount?
>>
>> I'd suggest that you don't touch the disks, cables, nor the
>> array.
>>
>> Try running sudo fsck /dev/md0
>>
>> On Fri, Oct 23, 2009 at 5:18 AM, adfas asd <chimera_god@yahoo.com>
>> wrote:
>> >
>> > I don't understand exactly what it is to be done.  If
>> I can mount using a different superblock, do I then remove
>> one of the drives from the array so I can put that drive
>> away with my data until I can buy another drive to back up
>> the data to?  If so, how?
>> >
>> > How is it that the superblock on -both- drives got
>> destroyed?  Isn't RAID10 supposed to be mirrored?
>> >
>> > --- On Thu, 10/22/09, Majed B. <majedb@gmail.com>
>> wrote:
>> >
>> > > From: Majed B. <majedb@gmail.com>
>> > > Subject: Re: Is My Data DESTROYED?!
>> > > To: "adfas asd" <chimera_god@yahoo.com>
>> > > Cc: linux-raid@vger.kernel.org
>> > > Date: Thursday, October 22, 2009, 7:12 PM
>> > > If you have bad sectors here
>> > > & there, and you didn't read the areas where
>> the bad
>> > > sectors are, you won't get read errors.
>> > >
>> > > That's why you should always have smartd running
>> along
>> > > with periodic sync_action -> check to force
>> mdadm to
>> > > check the array.
>> > >
>> > >
>> > >
>> > > There's still hope in recovering your data.
>> Don't
>> > > despair.
>> > >
>> > > On Fri, Oct 23, 2009 at 5:04 AM,
>> > > adfas asd <chimera_god@yahoo.com>
>> > > wrote:
>> > >
>> > >
>> > > How could this possibly have
>> > > happened?  The whole idea of RAID is so
>> something like this
>> > > won't happen.
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > I was using JFS.
>> > >
>> > >
>> > >
>> > > I've lost confidence now in mdadm.  I have too
>> much
>> > > data to back up practically, and am now at a
>> loss.
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > --- On Thu, 10/22/09, Majed B. <majedb@gmail.com>
>> > > wrote:
>> > >
>> > >
>> > >
>> > > > From: Majed B. <majedb@gmail.com>
>> > >
>> > > > Subject: Re: Is My Data
>> > > DESTROYED?!
>> > >
>> > > > To: "adfas asd" <chimera_god@yahoo.com>
>> > >
>> > > > Cc: linux-raid@vger.kernel.org
>> > >
>> > > > Date: Thursday, October 22, 2009, 6:40 PM
>> > >
>> > > > Seems like your
>> > > filesystem is
>> > >
>> > > > corrupted. Some filesystems have
>> alternative
>> > > superblocks.
>> > >
>> > > >
>> > >
>> > > > you can mount your filesystem using an
>> alternative
>> > >
>> > > > superblock using: mount -o
>> sb=<offset>
>> > >
>> > > > You find the offset value by running a
>> dry-run (test)
>> > > of
>> > >
>> > > > mkfs on your drives. It will print multiple
>> offsets
>> > > for
>> > >
>> > > > superblocks.
>> > >
>> > > >
>> > >
>> > > >
>> > >
>> > > >
>> > >
>> > > > On Fri, Oct 23, 2009 at 4:36 AM,
>> > >
>> > > > adfas asd <chimera_god@yahoo.com>
>> > >
>> > > > wrote:
>> > >
>> > > >
>> > >
>> > > >
>> > >
>> > > > Today I went in to my HTPC, to find it was
>> hung and
>> > > the
>> > >
>> > > > drive light was stuck on.  After all
>> attempts to
>> > > revive it
>> > >
>> > > > or switch to terminal 2 or 3 had failed I
>> reset the
>> > > system.
>> > >
>> > > >
>> > >
>> > > >
>> > >
>> > > >
>> > >
>> > > > It rebooted to tell me that it cannot mount
>> /home,
>> > > the
>> > >
>> > > > RAID10offset2 device.
>> > >
>> > > >
>> > >
>> > > >
>> > >
>> > > >
>> > >
>> > > > When I reboot in recovery mode and try to
>> mount
>> > > /dev/md0
>> > >
>> > > > manually it informs me there is an invalid
>> superblock!
>> > >  I
>> > >
>> > > > shut down and unplugged each drive in turn,
>> and
>> > > /proc/mdstat
>> > >
>> > > > shows the appropriate volume gone, but still
>> can't
>> > > mount
>> > >
>> > > > the array.
>> > >
>> > > >
>> > >
>> > > >
>> > >
>> > > >
>> > >
>> > > >
>> > >
>> > > >
>> > >
>> > > > What has happened here?  Is all my data
>> destroyed?
>> > >
>> > > >
>> > >
>> > > >
>> > >
>> > > >
>> > >
>> > > >
>> > >
>> > > >
>> > >
>> > > >
>> > >
>> > > >
>> > >
>> > > > --
>> > >
>> > > >
>> > >
>> > > > To unsubscribe from this list: send the
>> line
>> > >
>> > > > "unsubscribe linux-raid" in
>> > >
>> > > >
>> > >
>> > > > the body of a message to majordomo@vger.kernel.org
>> > >
>> > > >
>> > >
>> > > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> > >
>> > > >
>> > >
>> > > >
>> > >
>> > > >
>> > >
>> > > >
>> > >
>> > > > --
>> > >
>> > > >        Majed B.
>> > >
>> > > >
>> > >
>> > > >
>> > >
>> > > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > --
>> > >
>> > > To unsubscribe from this list: send the line
>> > > "unsubscribe linux-raid" in
>> > >
>> > > the body of a message to majordomo@vger.kernel.org
>> > >
>> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> > >
>> > >
>> > >
>> > >
>> > > --
>> > >        Majed B.
>> > >
>> > >
>> > >
>> >
>> >
>> >
>> > --
>> > To unsubscribe from this list: send the line
>> "unsubscribe linux-raid" in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>> --
>>       Majed B.
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-raid" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
       Majed B.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is My Data DESTROYED?!

[adfas asd]

Now I'm repeatedly getting this:

This is an automatically generated mail message from mdadm
running on hex

A DegradedArray event had been detected on md device /dev/md0.

Faithfully yours, etc.

P.S. The /proc/mdstat file currently contains the following:

Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] 
md2 : active raid10 sdb3[0] sdc3[1]
      1868558336 blocks 1024K chunks 2 offset-copies [2/2] [UU]
      bitmap: 6/223 pages [24KB], 4096KB chunk

md1 : active (auto-read-only) raid10 sdb2[0] sdc2[1]
      6297088 blocks 256K chunks 2 offset-copies [2/2] [UU]
      bitmap: 0/193 pages [0KB], 16KB chunk

md0 : active raid1 sdb1[0]
      78654144 blocks [2/1] [U_]
      bitmap: 2/151 pages [8KB], 256KB chunk

unused devices: <none>


      

Re: Is My Data DESTROYED?!

[NeilBrown]

On Sat, October 24, 2009 6:24 am, adfas asd wrote:
> Now I'm repeatedly getting this:
>
> This is an automatically generated mail message from mdadm
> running on hex
>
> A DegradedArray event had been detected on md device /dev/md0.

Clearly md0 is degraded - one device is missing.
You need to find out why.  Then if you trust the missing device to
keep working, add it back in (mdadm --add ...)

dmesg or /var/log/something might have hints as to what the error
was that caused md to reject the device.

NeilBrown


>
> Faithfully yours, etc.
>
> P.S. The /proc/mdstat file currently contains the following:
>
> Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
> [multipath]
> md2 : active raid10 sdb3[0] sdc3[1]
>       1868558336 blocks 1024K chunks 2 offset-copies [2/2] [UU]
>       bitmap: 6/223 pages [24KB], 4096KB chunk
>
> md1 : active (auto-read-only) raid10 sdb2[0] sdc2[1]
>       6297088 blocks 256K chunks 2 offset-copies [2/2] [UU]
>       bitmap: 0/193 pages [0KB], 16KB chunk
>
> md0 : active raid1 sdb1[0]
>       78654144 blocks [2/1] [U_]
>       bitmap: 2/151 pages [8KB], 256KB chunk
>
> unused devices: <none>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Is My Data DESTROYED?!

[adfas asd]

--- On Fri, 10/23/09, NeilBrown <neilb@suse.de> wrote:
> Clearly md0 is degraded - one device is missing.
> You need to find out why.  Then if you trust the
> missing device to
> keep working, add it back in (mdadm --add ...)
> 
> dmesg or /var/log/something might have hints as to what the
> error
> was that caused md to reject the device.

Thanks Neil, this is the first constructive advice all day.

Klipper isn't working for some reason, so I can't post the exact error, but dmesg and /var/log/messages say md0 has an unknown partition table (this time for ext2), just like with the prior problem on md2 (with jfs).




      

Re: Is My Data DESTROYED?!

[Majed B.]

Perhaps the program utils for ext2 were uninstalled as well just like
what happened to the JFS ones?

Double check. Also, paste the errors in Google and look for similar incidents.

On Sat, Oct 24, 2009 at 2:25 AM, adfas asd <chimera_god@yahoo.com> wrote:
> --- On Fri, 10/23/09, NeilBrown <neilb@suse.de> wrote:
>> Clearly md0 is degraded - one device is missing.
>> You need to find out why.  Then if you trust the
>> missing device to
>> keep working, add it back in (mdadm --add ...)
>>
>> dmesg or /var/log/something might have hints as to what the
>> error
>> was that caused md to reject the device.
>
> Thanks Neil, this is the first constructive advice all day.
>
> Klipper isn't working for some reason, so I can't post the exact error, but dmesg and /var/log/messages say md0 has an unknown partition table (this time for ext2), just like with the prior problem on md2 (with jfs).
>
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
       Majed B.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is My Data DESTROYED?!

[NeilBrown]

On Sat, October 24, 2009 10:25 am, adfas asd wrote:
> --- On Fri, 10/23/09, NeilBrown <neilb@suse.de> wrote:
>> Clearly md0 is degraded - one device is missing.
>> You need to find out why.  Then if you trust the
>> missing device to
>> keep working, add it back in (mdadm --add ...)
>>
>> dmesg or /var/log/something might have hints as to what the
>> error
>> was that caused md to reject the device.
>
> Thanks Neil, this is the first constructive advice all day.
>
> Klipper isn't working for some reason, so I can't post the exact error,
> but dmesg and /var/log/messages say md0 has an unknown partition table
> (this time for ext2), just like with the prior problem on md2 (with jfs).

To see the cause of the error you would need to look further back
in the kernel logs for some messsage about md kicking the device from
the array.

Presumably you know which device is meant to be the other half of the
RAID1.  I suggest you try reading that whole device with
   dd if=/dev/whatever of=/dev/null bs=10M

and if that works, just add the device with
   mdadm /dev/md0 --add /dev/whatever

and see how it goes.

NeilBrown

RE: Is My Data DESTROYED?!

[Leslie Rhorer]

> When I was trying to find man for mkfs.jfs I discovered that jfsutils was
> suddenly not installed.  I installed it and then could man mkfs.jfs .
> 
> I rebooted so I could plug in the second drive, and then md0 was getting
> mounted on /home as it should.  Indeed I have all my data again.  I don't
> understand what happened.

	Something erased or overwrote the data.  This is always a
possibility whenever the system files are maintained on a read-write file
system.  High reliability system place all their binaries and configuration
files on read-only mounts.  The Tivo, for example, does this.  Everything
(that is mounted) except /var is mounted read-only.  In order to make
changes to any of the OS or application code, / has to be re-mounted as
read-write.  It's a simple and elegant way of helping to prevent system
corruption.  It does mean ordinary users cannot load software, and it means
the sysadmin must remount the file system before attempting updates, but the
former may be a good thing, and the latter is no big deal.

> --- On Thu, 10/22/09, Majed B. <majedb@gmail.com> wrote:
> 
> > From: Majed B. <majedb@gmail.com>
> > Subject: Re: Is My Data DESTROYED?!
> > To: "adfas asd" <chimera_god@yahoo.com>
> > Cc: linux-raid@vger.kernel.org
> > Date: Thursday, October 22, 2009, 7:43 PM
> > I don't know exactly what went wrong
> > with your setup, so I can't tell
> > why it's not mounting.
> >
> > Did you check the output of dmesg | tail after a failed
> > mount?
> >
> > I'd suggest that you don't touch the disks, cables, nor the
> > array.
> >
> > Try running sudo fsck /dev/md0
> >
> > On Fri, Oct 23, 2009 at 5:18 AM, adfas asd <chimera_god@yahoo.com>
> > wrote:
> > >
> > > I don't understand exactly what it is to be done.  If
> > I can mount using a different superblock, do I then remove
> > one of the drives from the array so I can put that drive
> > away with my data until I can buy another drive to back up
> > the data to?  If so, how?

	You are confusing a failed file system with a failed drive.  One
only replaces a drive if it has failed (or seems about to fail).  A
corrupted file system (or other corrupted data) has nothing to do with RAID,
unless of course a RAID failure causes the data corruption.  In this event,
one must analyze the system very carefully to determine the cause of the
corruption and devise a good means of recovering the array and as much data
as can be recovered, not necessarily in that order.

> > > How is it that the superblock on -both- drives got
> > destroyed?  Isn't RAID10 supposed to be mirrored?

	You need to go back and read my earlier messages on the subject.
Mirroring a drive will *NOT* prevent data corruption, no matter how it is
mirrored.  Any data corruption will automatcialy be written to both drives,
unless the failure is due to a bad sector on one of the drives.

	Of course, as we now know, the file system "corruption" in your case
was due to a loss of the JFS utilities.

> > > > How could this possibly have
> > > > happened?  The whole idea of RAID is so
> > something like this
> > > > won't happen.

	No, it isn't.  The whole idea of RAID is to increase storage
capacity or to limit the impact to the system of a lost drive, or both.

> > > > I've lost confidence now in mdadm.  I have too
> > much
> > > > data to back up practically, and am now at a
> > loss.

	You keep saying that, but it is fundamentally untrue.  If you have
enough drives to implement a mirrored solution, then you also have enough
for a backup solution.  Again and again I have advised you to abandon this
strategy of a remote mirror and instead implement a main system and a backup
system.  If you choose, you can make them a pair of high availability
systems, although in your case (and mine) I think you would be better served
by a simple backup system maintained using rsync.  You could purchase one
extra drive to make the main system a RAID5 array.  That, or you could do
what I did and purchase three extra drives to make the main array RAID6 and
the backup array RAID5.  I'm a belt, suspenders, and both-hands-on-my-pants
kind of guy.

	At the very least, completely independent systems would have saved
you the major coronary you had when you discovered the file system could not
be mounted.

Re: Is My Data DESTROYED?!

[Bill Davidsen]

adfas asd wrote:
> I don't understand exactly what it is to be done.  If I can mount using a different superblock, do I then remove one of the drives from the array so I can put that drive away with my data until I can buy another drive to back up the data to?  If so, how?
>
> How is it that the superblock on -both- drives got destroyed?  Isn't RAID10 supposed to be mirrored?
>   

It is mirrored, do you understand what that means? It means that if your 
filesystem screws up and writes crap to one drive, raid will faithfully 
write crap to the mirror copy, thereby giving you a fully reliable fully 
hosed filesystem. Your problem isn't that your raid array has lost your 
data, but rather that your filesystem has been trashed. And from your 
comments in another post about reinstalling jfs utilities, I suspect 
that a nice clean removal of those utilities has some element of human 
intervention involved.

-- 
Bill Davidsen <davidsen@tmr.com>
  Unintended results are the well-earned reward for incompetence.

Re: Is My Data DESTROYED?!

[adfas asd]

--- On Fri, 10/23/09, Bill Davidsen <davidsen@tmr.com> wrote:
> Your problem isn't that your raid array has lost your data,
> but rather that your filesystem has been trashed. And from
> your comments in another post about reinstalling jfs
> utilities, I suspect that a nice clean removal of those
> utilities has some element of human intervention involved.

Think what you want, man.  I know it's a palliative for you.  

From your last post it's clear that you do not understand the sequence of events, so I hinted you directly in backchannel, but it now seems clear that I should not have protected you.


      

Re: Is My Data DESTROYED?!

[Luca Berra]

On Thu, Oct 22, 2009 at 07:18:29PM -0700, adfas asd wrote:
please dont' feed the trolls

L.

Re: Is My Data DESTROYED?!

[adfas asd]

I can't find anything about a dry-run or test option in the man page for mkfs.jfs .




      

Re: Is My Data DESTROYED?!

[Bill Davidsen]

adfas asd wrote:
> I can't find anything about a dry-run or test option in the man page for mkfs.jfs .
>   

You want fsck (check my filesystem) not mkfs (blow away all I have and 
create a new empty filesystem).

-- 
Bill Davidsen <davidsen@tmr.com>
  Unintended results are the well-earned reward for incompetence.

Re: Is My Data DESTROYED?!

[Darius S. Naqvi]

On Fri, 23 Oct 2009, Bill Davidsen wrote:

> adfas asd wrote:
>> I can't find anything about a dry-run or test option in the man page for 
>> mkfs.jfs .
>> 
>
> You want fsck (check my filesystem) not mkfs (blow away all I have and create 
> a new empty filesystem).

I think he wants to know where the mkfs put the backup superblocks
when the filesystem was made originally.  If you know where the backup
superblocks are, you can tell mount to use one of them.  This is one way to recover from a corrupt superblock.

The way I've done this in the past was to issue mkfs with a flag (-n,
I think) that meant, "don't make the filesystem, just tell me what you
would do".  One of the thing that mkfs (actually, this was newfs on
SunOS 4.1.x, which constructs a mkfs command for you) spits out on
stdout is the list of backup superblocks.

-- 
Darius S. Naqvi
dnaqvi@datagardens.com
http://www.datagardens.com

Re: Is My Data DESTROYED?!

[adfas asd]

How could this possibly have happened?  The whole idea of RAID is so something like this won't happen.

I was using JFS.

I've lost confidence now in mdadm.  I have too much data to back up practically, and am now at a loss.


--- On Thu, 10/22/09, Majed B. <majedb@gmail.com> wrote:

> From: Majed B. <majedb@gmail.com>
> Subject: Re: Is My Data DESTROYED?!
> To: "adfas asd" <chimera_god@yahoo.com>
> Cc: linux-raid@vger.kernel.org
> Date: Thursday, October 22, 2009, 6:40 PM
> Seems like your filesystem is
> corrupted. Some filesystems have alternative superblocks.
> 
> you can mount your filesystem using an alternative
> superblock using: mount -o sb=<offset>
> You find the offset value by running a dry-run (test) of
> mkfs on your drives. It will print multiple offsets for
> superblocks.
> 
> 
> 
> On Fri, Oct 23, 2009 at 4:36 AM,
> adfas asd <chimera_god@yahoo.com>
> wrote:
> 
> 
> Today I went in to my HTPC, to find it was hung and the
> drive light was stuck on.  After all attempts to revive it
> or switch to terminal 2 or 3 had failed I reset the system.
> 
> 
> 
> It rebooted to tell me that it cannot mount /home, the
> RAID10offset2 device.
> 
> 
> 
> When I reboot in recovery mode and try to mount /dev/md0
> manually it informs me there is an invalid superblock!  I
> shut down and unplugged each drive in turn, and /proc/mdstat
> shows the appropriate volume gone, but still can't mount
> the array.
> 
> 
> 
> 
> 
> What has happened here?  Is all my data destroyed?
> 
> 
> 
> 
> 
> 
> 
> --
> 
> To unsubscribe from this list: send the line
> "unsubscribe linux-raid" in
> 
> the body of a message to majordomo@vger.kernel.org
> 
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 
> 
> -- 
>        Majed B.
> 
> 
> 


      

Re: Is My Data DESTROYED?!

[Billy Crook]

On Thu, Oct 22, 2009 at 21:04, adfas asd <chimera_god@yahoo.com> wrote:
> How could this possibly have happened?  The whole idea of RAID is so something like this won't happen.

Actually no.  No it is not at all.  The point of raid it is to provide
larger and faster block devices than otherwise physically exist, and
in some cases allow you to change out failed drives without making the
array unavailable for use.

I believe you are confusing raid with backup.  You won't do that
again.  If your data isn't completely disposable, I'd recommending
breaking that raid10 array into two raid0's, on two separate machines,
and rsyncing between them.  Each individual raid0 array should
actually be even faster this way, and you'll definitely have more read
IO available using two machines.

> I was using JFS.
>
> I've lost confidence now in mdadm.  I have too much data to back up practically, and am now at a loss.

mdadm works fine.  But it is not to be used as bubble gum, or a web
browser, or a text editor, or backup.

Reply with an mdadm -E /dev/sd[abcd].  Once the array assembles, your
problem is with JFS.  The machine was malfunctioning when you pulled
power.  It is entirely possible that its malfunction caused it to
corrupt the filesystem beyond recovery.  mdadm's job (and the job of
any raid solution software or hardware) is to immediately and
irrevocably accept the io from the filesystem driver, and pass it on
to the disks.

The easiest and cleanest solution is to dd the first and last 100mb or
so of the disks with /dev/zero.  Remake the array.  Use something
sensible like ext4 this time, and restore your backups on to it.  If
you don't have any backups to restore, you will next time.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is My Data DESTROYED?!

[Christian Pernegger]

> I believe you are confusing raid with backup.

For lots of people the primary role of RAID is as a protection against
data-loss nowadays. Backups just aren't feasible/cost-effective
anymore for the amounts of data involved. Sticking your head in the
sand and repeating that mantra doesn't change that and it isn't
helping.

> The easiest and cleanest solution is to dd the first and last 100mb or
> so of the disks with /dev/zero.

Great, that'll destroy all hope of getting the data back. You're
really something ...

How about don't panic, post any and all error messages you're getting
(dmesg) and wait?

C.

Re: Is My Data DESTROYED?!

[Mattias Wadenstein]

On Fri, 23 Oct 2009, Christian Pernegger wrote:

>> I believe you are confusing raid with backup.
>
> For lots of people the primary role of RAID is as a protection against
> data-loss nowadays. Backups just aren't feasible/cost-effective
> anymore for the amounts of data involved. Sticking your head in the
> sand and repeating that mantra doesn't change that and it isn't
> helping.

Well, claiming that RAID will protect your data under all circumstances 
isn't helping either. Backups will actually protect against such things as 
rm -rf:ing the wrong directory or mkfs:ing the wrong device, etc. Things 
that RAID will never protect against.

And I don't see how backups aren't feasable, USB/network harddrives keep 
pace with in-box harddrive sizes just fine. Offsite backup might be 
trickier/costlier, so you might constrain those to just the data that you 
would be really sad to see gone if the house burns down (photo album, own 
creations, etc).

/Mattias Wadenstein

Re: Is My Data DESTROYED?!

[Billy Crook]

On Fri, Oct 23, 2009 at 15:46, Christian Pernegger <pernegger@gmail.com> wrote:
> For lots of people the primary role of RAID is as a protection against
> data-loss nowadays.

Yeah.  Lots of people don't understand technology and have delusional
expectations of silver bullet happy pill solutions that make their
tummy feel good.  I am not one of them.  Sysadmins shouldn't have any
part in that either.

> Backups just aren't feasible/cost-effective
> anymore for the amounts of data involved.

Backups have never been more feasable, and it is only going to get
cheaper and easier.  Visit Newegg, microcenter, ebay.  Google "backup
service".

> Sticking your head in the
> sand and repeating that mantra doesn't change that and it isn't
> helping.

That's odd.  I've always thought that those who imagined a raid array
as its own backup to be the ones with their heads in the sand.  The
reason people keep saying raid!=backup is because of those people who
keep thinking raid=backup.  "Mantra" it all you want.  Raid isn't
backup.  Ignoring that fact doesn't change it, and isn't helping.

>> The easiest and cleanest solution is to dd the first and last 100mb or
>> so of the disks with /dev/zero.
>
> Great, that'll destroy all hope of getting the data back. You're
> really something ...

You took that out of context and you know it.  Come back when you've
read the rest of the paragraph.  The filesystem is already gone.  It
was gone when the machine became unresponsive.  Get a greif counselor,
and some backup drives.

> How about don't panic, post any and all error messages you're getting
> (dmesg) and wait?

Time is money.  It would be quicker to recreate the array and restore
from a backup than to wait on a mailing list.  He might also want to
consider badblocks-ing the disks again a few times, and running the
smart tests on them.  I have a little script that makes that somewhat
easier.  See: http://kclug.org/wiki/index.php/Hard_Drive_Hell


On Fri, Oct 23, 2009 at 15:57, Mattias Wadenstein <maswan@acc.umu.se> wrote:
> Well, claiming that RAID will protect your data under all circumstances
> isn't helping either.

Amen.

> Backups will actually protect against such things as
> rm -rf:ing the wrong directory or mkfs:ing the wrong device, etc.

And filesystem corruption, which it sounds like this is.  Even fsck is
not guaranteed to recover files.  It will fix the filesystem, even if
that means truncating the / directory.

Here's a new offsite backup service with unlimited transfer and
unlimited storage, for just $5 a month. That could very realistically
be cheaper than your cost in power, hvac, and failed drives if you use
the service enough. http://www.backblaze.com/

see also: rsync, rsnapshot, rdiff-backup

Re: Is My Data DESTROYED?!

[adfas asd]

--- On Fri, 10/23/09, Billy Crook <billycrook@gmail.com> wrote:
> Google "backup service".
> Here's a new offsite backup service with unlimited transfer
> and
> unlimited storage, for just $5 a month. That could very
> realistically
> be cheaper than your cost in power, hvac, and failed drives
> if you use
> the service enough. http://www.backblaze.com/

You know nothing of the legal and privacy issues, obviously.


> > Great, that'll destroy all hope of getting the data
> back. You're
> > really something ...
> 
> You took that out of context and you know it.  Come
> back when you've
> read the rest of the paragraph.  The filesystem is
> already gone.  It
> was gone when the machine became unresponsive.  Get a
> greif counselor,
> and some backup drives.

NO!  The filesystem was NOT already gone, but your 'advice' would have ensured that it was.





      

Re: Is My Data DESTROYED?!

[Billy Crook]

On Fri, Oct 23, 2009 at 17:00, adfas asd <chimera_god@yahoo.com> wrote:
> --- On Fri, 10/23/09, Billy Crook <billycrook@gmail.com> wrote:
> You know nothing of the legal and privacy issues, obviously.

You failed to ever mention any specific legal or privacy requirements.
 But I doubt they specifically forbid using any service from any other
company.

Use encryption.  Or buy a few 2TB drives.  And "terabytes" is not a
big word anymore.


On Fri, Oct 23, 2009 at 17:41, adfas asd <chimera_god@yahoo.com> wrote:
> From your last post it's clear that you do not understand the sequence of events, so I hinted you directly in backchannel, but it now seems clear that I should not have protected you.

Good luck Mr. 'Chimera'!  Watch out for Bellerophon.  You're on your
own now.  I'm surprised you got what you did given your spamming in
the beginning.

Re: Is My Data DESTROYED?!

[adfas asd]

--- On Fri, 10/23/09, Billy Crook <billycrook@gmail.com> wrote:
> Or buy a few 2TB drives.  And "terabytes" is not a
> big word anymore.

As I've said from the beginning...  ALL my drives are 2TB .




      

Re: Is My Data DESTROYED?!

[berk walker]

adfas asd wrote:
> --- On Fri, 10/23/09, Billy Crook <billycrook@gmail.com> wrote:
>> Google "backup service".
>> Here's a new offsite backup service with unlimited transfer
>> and
>> unlimited storage, for just $5 a month. That could very
>> realistically
>> be cheaper than your cost in power, hvac, and failed drives
>> if you use
>> the service enough. http://www.backblaze.com/
> 
> You know nothing of the legal and privacy issues, obviously.
> 
> 
>>> Great, that'll destroy all hope of getting the data
>> back. You're
>>> really something ...
>> You took that out of context and you know it.  Come
>> back when you've
>> read the rest of the paragraph.  The filesystem is
>> already gone.  It
>> was gone when the machine became unresponsive.  Get a
>> greif counselor,
>> and some backup drives.
> 
> NO!  The filesystem was NOT already gone, but your 'advice' would have ensured that it was.
> 
> 
> 
> 
> 
>       
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
I am SO tired of this - stupid thread.  I am waiting for someone to say 
what A S D REALLY means.
b-

Re: Is My Data DESTROYED?!

[berk walker]

Somehow some dickhead managed to put everything wrongly quoted.  I vote 
he be drowned.


berk walker wrote:
> adfas asd wrote:
>> --- On Fri, 10/23/09, Billy Crook <billycrook@gmail.com> wrote:
>>> Google "backup service".
>>> Here's a new offsite backup service with unlimited transfer
>>> and
>>> unlimited storage, for just $5 a month. That could very
>>> realistically
>>> be cheaper than your cost in power, hvac, and failed drives
>>> if you use
>>> the service enough. http://www.backblaze.com/
>>
>> You know nothing of the legal and privacy issues, obviously.
>>
>>
>>>> Great, that'll destroy all hope of getting the data
>>> back. You're
>>>> really something ...
>>> You took that out of context and you know it.  Come
>>> back when you've
>>> read the rest of the paragraph.  The filesystem is
>>> already gone.  It
>>> was gone when the machine became unresponsive.  Get a
>>> greif counselor,
>>> and some backup drives.
>>
>> NO!  The filesystem was NOT already gone, but your 'advice' would have 
>> ensured that it was.
>>
>>
>>
>>
>>
>>       --
>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> I am SO tired of this - stupid thread.  I am waiting for someone to say 
> what A S D REALLY means.
> b-
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

RE: Is My Data DESTROYED?!

[Leslie Rhorer]

> On Fri, Oct 23, 2009 at 15:46, Christian Pernegger <pernegger@gmail.com>
> wrote:
> > For lots of people the primary role of RAID is as a protection against
> > data-loss nowadays.
> 
> Yeah.  Lots of people don't understand technology and have delusional
> expectations of silver bullet happy pill solutions that make their
> tummy feel good.  I am not one of them.  Sysadmins shouldn't have any
> part in that either.

	Correct.  As I admonished adfas asd when he first said he was
undertaking this method of storage, RAID is not fault-free.  It is fault
tolerant.

> > Backups just aren't feasible/cost-effective
> > anymore for the amounts of data involved.
> 
> Backups have never been more feasable, and it is only going to get
> cheaper and easier.  Visit Newegg, microcenter, ebay.  Google "backup
> service".

	The silliest part of this argument is that if one has enough drives
for a mirrored solution, then one has enough drives - or nearly so - for a
separate backup system.  The incremental cost for creating a second system
vs. piling more drives in a single system for a mirrored solution is small.
This is especially true for adfas asd, who is already going to be putting
his mirror drives in a remote system in his garage.

> > Sticking your head in the
> > sand and repeating that mantra doesn't change that and it isn't
> > helping.
> 
> That's odd.  I've always thought that those who imagined a raid array
> as its own backup to be the ones with their heads in the sand.  The
> reason people keep saying raid!=backup is because of those people who
> keep thinking raid=backup.  "Mantra" it all you want.  Raid isn't
> backup.  Ignoring that fact doesn't change it, and isn't helping.

	Absolutely.  A backup helps to eliminate almost all forms of data
loss to one extent or another.  A RAID solution fails completely to
eliminate the most common vector for data loss: human error.  No matter how
robust the RAID solution, however, and even discounting human error, there
will still always be failure modes which can result in data loss.  Of
course, the most obvious is a catastrophic event such as fire or flood.  The
OP is looking to limit those effects by putting his mirrored drives in a
separate system in his garage.

> >> The easiest and cleanest solution is to dd the first and last 100mb or
> >> so of the disks with /dev/zero.
> >
> > Great, that'll destroy all hope of getting the data back. You're
> > really something ...
> 
> You took that out of context and you know it.  Come back when you've
> read the rest of the paragraph.  The filesystem is already gone.  It
> was gone when the machine became unresponsive.  Get a greif counselor,
> and some backup drives.

	Woah, now you are going too far in the other direction.  A lost
filesystem does not necessarily mean an unrecoverable one.

> > How about don't panic, post any and all error messages you're getting
> > (dmesg) and wait?
> 
> Time is money.  It would be quicker to recreate the array and restore
> from a backup than to wait on a mailing list.  He might also want to

	Now that is completely untrue in many cases.  Restoring my system
from backup can easily take 3 or 4 days.  Indeed, the last time I had to do
it, the backup system also had an issue (my own fault), which caused the
restore to take over 2 weeks.  Multi-terrabyte arrays take a long time to
restore.  I expect my Video server and its backup to reach 30T each within
the next two years.  The OP's is 4T, I think, and even that takes a while to
restore.

> And filesystem corruption, which it sounds like this is.  Even fsck is
> not guaranteed to recover files.  It will fix the filesystem, even if
> that means truncating the / directory.
> 
> Here's a new offsite backup service with unlimited transfer and
> unlimited storage, for just $5 a month. That could very realistically
> be cheaper than your cost in power, hvac, and failed drives if you use
> the service enough. http://www.backblaze.com/

	Restoring over 10T of files on a less than 10 Mbps link?  I don't
think so, especially not with ISPs starting to put caps of far less than 1G
per month of data transfer.

Re: Is My Data DESTROYED?!

[adfas asd]

For those of you who don't follow the list closely, we have gone over this same old ground several times already.

- Of course I know that RAID is not quite as good as backup. 
- Of course I wish that backing up could save many terabytes of data for less than $10,000.  But that is not practical today.

Fact:  I have terabytes of data that I want to keep from losing.
Fact:  Disk drives have never been cheaper.
Fact:  It is most cost-effective to save terabytes of data on disk drives, if the proper regimen can be determined for safety.
Fact:  After one month's use mdadm RAID has resulted in a failure which could have been catastrophic had I not determined that somehow JFS functionality was destroyed.
Fact:  Now one of my  arrays has gone into degraded mode for mysterious reasons, and we are so busy arguing about backups that no one can advise on what to do about this.


--- On Fri, 10/23/09, Mattias Wadenstein <maswan@acc.umu.se> wrote:

> From: Mattias Wadenstein <maswan@acc.umu.se>
> Subject: Re: Is My Data DESTROYED?!
> To: "Christian Pernegger" <pernegger@gmail.com>
> Cc: linux-raid@vger.kernel.org, "adfas asd" <chimera_god@yahoo.com>
> Date: Friday, October 23, 2009, 1:57 PM
> On Fri, 23 Oct 2009, Christian
> Pernegger wrote:
> 
> >> I believe you are confusing raid with backup.
> > 
> > For lots of people the primary role of RAID is as a
> protection against
> > data-loss nowadays. Backups just aren't
> feasible/cost-effective
> > anymore for the amounts of data involved. Sticking
> your head in the
> > sand and repeating that mantra doesn't change that and
> it isn't
> > helping.
> 
> Well, claiming that RAID will protect your data under all
> circumstances isn't helping either. Backups will actually
> protect against such things as rm -rf:ing the wrong
> directory or mkfs:ing the wrong device, etc. Things that
> RAID will never protect against.
> 
> And I don't see how backups aren't feasable, USB/network
> harddrives keep pace with in-box harddrive sizes just fine.
> Offsite backup might be trickier/costlier, so you might
> constrain those to just the data that you would be really
> sad to see gone if the house burns down (photo album, own
> creations, etc).
> 
> /Mattias Wadenstein
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


      

RE: Is My Data DESTROYED?!

[Guy Watkins]

You can buy a 1TB disk for less than $100.  A 10TB backup would cost less
than $1000.

I backup to an external USB disk.  If I required more than 1 I would create
a RAID5 with USB disks.  If I was really careful, I would have 2 or more
disks and rotate them off site.  Maybe my Mom's house.  No, my car would do
just fine.

Fact:  I don't think you read the archives.  If you did, you would remove
the failed drive from the array and add it back.  And you would have
included some debugging info in 1 of your first 5 posts.  But you just
spammed the list with noise.

} -----Original Message-----
} From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
} owner@vger.kernel.org] On Behalf Of adfas asd
} Sent: Friday, October 23, 2009 5:56 PM
} To: linux-raid@vger.kernel.org
} Subject: Re: Is My Data DESTROYED?!
} 
} For those of you who don't follow the list closely, we have gone over this
} same old ground several times already.
} 
} - Of course I know that RAID is not quite as good as backup.
} - Of course I wish that backing up could save many terabytes of data for
} less than $10,000.  But that is not practical today.
} 
} Fact:  I have terabytes of data that I want to keep from losing.
} Fact:  Disk drives have never been cheaper.
} Fact:  It is most cost-effective to save terabytes of data on disk drives,
} if the proper regimen can be determined for safety.
} Fact:  After one month's use mdadm RAID has resulted in a failure which
} could have been catastrophic had I not determined that somehow JFS
} functionality was destroyed.
} Fact:  Now one of my  arrays has gone into degraded mode for mysterious
} reasons, and we are so busy arguing about backups that no one can advise
} on what to do about this.
} 
} 
} --- On Fri, 10/23/09, Mattias Wadenstein <maswan@acc.umu.se> wrote:
} 
} > From: Mattias Wadenstein <maswan@acc.umu.se>
} > Subject: Re: Is My Data DESTROYED?!
} > To: "Christian Pernegger" <pernegger@gmail.com>
} > Cc: linux-raid@vger.kernel.org, "adfas asd" <chimera_god@yahoo.com>
} > Date: Friday, October 23, 2009, 1:57 PM
} > On Fri, 23 Oct 2009, Christian
} > Pernegger wrote:
} >
} > >> I believe you are confusing raid with backup.
} > >
} > > For lots of people the primary role of RAID is as a
} > protection against
} > > data-loss nowadays. Backups just aren't
} > feasible/cost-effective
} > > anymore for the amounts of data involved. Sticking
} > your head in the
} > > sand and repeating that mantra doesn't change that and
} > it isn't
} > > helping.
} >
} > Well, claiming that RAID will protect your data under all
} > circumstances isn't helping either. Backups will actually
} > protect against such things as rm -rf:ing the wrong
} > directory or mkfs:ing the wrong device, etc. Things that
} > RAID will never protect against.
} >
} > And I don't see how backups aren't feasable, USB/network
} > harddrives keep pace with in-box harddrive sizes just fine.
} > Offsite backup might be trickier/costlier, so you might
} > constrain those to just the data that you would be really
} > sad to see gone if the house burns down (photo album, own
} > creations, etc).
} >
} > /Mattias Wadenstein
} > --
} > To unsubscribe from this list: send the line "unsubscribe
} > linux-raid" in
} > the body of a message to majordomo@vger.kernel.org
} > More majordomo info at  http://vger.kernel.org/majordomo-info.html
} >
} 
} 
} 
} --
} To unsubscribe from this list: send the line "unsubscribe linux-raid" in
} the body of a message to majordomo@vger.kernel.org
} More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is My Data DESTROYED?!

[Bill Davidsen]

Warning: I can only be polite and diplomatic to a limited number of 
technically incompetent people each day. Today isn't your day.

adfas asd wrote:
> For those of you who don't follow the list closely, we have gone over this same old ground several times already.
>
> - Of course I know that RAID is not quite as good as backup. 
>   

That's like saying a bicycle is not as good as a frying pan. They are 
totally different things, used for different reasons. A raid array is a 
technique used to improve the performance or reliability of a single 
dynamic copy of data. A backup is an independent copy of the data at 
some point in time, and will continue to exist if the original is 
damaged or destroyed.

Note: a good backup will be off-site to prevent physical destruction. 
One of the few things I liked about running servers for at&t was that 
they actually had a "smoking hole recovery plan" requiring steps to 
recover if the data center was physically destroyed. The only other 
organization I have worked with who had that level of concern was a bank 
in Ireland during "the troubles." My general data will survive loss of 
my office and a two mile radius around it, my critical data will survive 
lose off the continental US. Okay, I may take this too seriously. ;-)
> - Of course I wish that backing up could save many terabytes of data for less than $10,000.  But that is not practical today.
>
>   
Hogwash! You can get an eSATA array tower with four bays from Newegg for 
<$200, 1TB drives for $85/ea on sale (mine are WD 'green' which run 
about 10C cooler than Seagate or Hitachi), and have 3TB RAID-5 for 
~$600, capable of being daisy chained. Choice of built-in or software 
raid. 2TB drives will add about $400, and with an independent copy of 
the filesystem on a box you have backup. For another $400 you can have a 
cheap 2nd system connected by Gbit network and be totally independent.

> Fact:  I have terabytes of data that I want to keep from losing.
> Fact:  Disk drives have never been cheaper.
> Fact:  It is most cost-effective to save terabytes of data on disk drives, if the proper regimen can be determined for safety.
>   

That means backup, sorry, stuff happens if you only have one copy.

> Fact:  After one month's use mdadm RAID has resulted in a failure which could have been catastrophic had I not determined that somehow JFS functionality was destroyed.
> Fact:  Now one of my  arrays has gone into degraded mode for mysterious reasons, and we are so busy arguing about backups that no one can advise on what to do about this.
>
>   
I advise you to go to backup. If you can afford to have "terabytes of 
data" you either live with losing it and just wonder when, or you go to 
real backup.
> --- On Fri, 10/23/09, Mattias Wadenstein <maswan@acc.umu.se> wrote:
>   

Not only don't you understand raid, you don't understand top-posting, 
either...

-- 
Bill Davidsen <davidsen@tmr.com>
  Unintended results are the well-earned reward for incompetence.

Re: Is My Data DESTROYED?!

[adfas asd]

--- On Fri, 10/23/09, Bill Davidsen <davidsen@tmr.com> wrote:
> Warning: I can only be polite and
> diplomatic to a limited number of technically incompetent
> people each day. Today isn't your day.

Thanks for the warning.  I won't read the rest, then.

Why would I?




      

Re: Is My Data DESTROYED?!

[NeilBrown]

On Sat, October 24, 2009 10:05 am, Bill Davidsen wrote:
> Warning: I can only be polite and diplomatic to a limited number of
> technically incompetent people each day. Today isn't your day.

May I respectfully suggest that today should therefore not be your
day to post to the list?

Thanks,
NeilBrown

Re: Is My Data DESTROYED?!

[Ben DJ]

On Fri, Oct 23, 2009 at 4:05 PM, Bill Davidsen <davidsen@tmr.com> wrote:
> Warning: I can only be polite and diplomatic to a limited number of
> technically incompetent people each day. Today isn't your day.

Honestly.  Rather than swinging your privates in public, perhaps you
might take your diatribe offlist?

Some, including "adfas asd" I gather, are actually trying to learn
something and get some work done.

Thanks.

Re: Is My Data DESTROYED?!

[Bill Davidsen]

Ben DJ wrote:
> On Fri, Oct 23, 2009 at 4:05 PM, Bill Davidsen <davidsen@tmr.com> wrote:
>   
>> Warning: I can only be polite and diplomatic to a limited number of
>> technically incompetent people each day. Today isn't your day.
>>     
>
> Honestly.  Rather than swinging your privates in public, perhaps you
> might take your diatribe offlist?
>
> Some, including "adfas asd" I gather, are actually trying to learn
> something and get some work done.
>   

I told him where and how to back up his data for about 8-10% of the 
price he said it would cost. I explained (as several other have) why no 
raid level is the same as a backup.

Sorry if that wasn't the thing you wanted to learn, but after it has 
been explained multiple time, it doesn't seem to have been sinking in. 
And clearly didn't this time. I won't waste my time trying to educate 
people here any more.

-- 
Bill Davidsen <davidsen@tmr.com>
  Unintended results are the well-earned reward for incompetence.

Re: Is My Data DESTROYED?!

[adfas asd]

Actually it it your solution which seems best at this point.  But I've been testing to see whether anyone else advocates it or another alternative.  

The division is stark;  some have been nothing but helpful, while others have done nothing but complain.  You are the only one right between.


--- On Fri, 10/23/09, Bill Davidsen <davidsen@tmr.com> wrote:
> I told him where and how to back up his data for about
> 8-10% of the price he said it would cost. I explained (as
> several other have) why no raid level is the same as a
> backup.
> 
> Sorry if that wasn't the thing you wanted to learn, but
> after it has been explained multiple time, it doesn't seem
> to have been sinking in. And clearly didn't this time. I
> won't waste my time trying to educate people here any more.




      

Re: Is My Data DESTROYED?!

[Christopher Chen]

You're the guy with the two disk raid 10, right?

That immediately makes my eyebrows furrow. If you have two disks, you
may as well make a raid 1 and keep it simple. While JFS is not exactly
new, this is foremost a list about mdadm and linux software raid, not
necessarily JFS.

Now, software raid is a funny thing. Some people love it, some people
hate it, and I don't want to be in the same room with either. I've had
great experiences with it, on raid sets of up to 56 disks at a time,
and generally think it's great. However, like everything else, YOU CAN
shoot yourself in the foot. Because it's a layered system, the kernel
won't get in your way if you decide to, say, dd the underlying block
devices and obliterate the superblock, or what have you.

Part of this sounds like you're looking for best practices. I imagine
that's why you made a raid 10, and why you're using JFS. It's probably
why you've been fiddling around with blockdev --setra and all that
too, maybe some elevator tweaks too. Not to get pedantic, but all
these techniques and technologies were designed around specific
workloads and hardware types. RAID 10 doesn't really win until you
have 4 spindles and higher. I have no doubt that JFS is a great file
system, but most people on here use ext3/4 and are happy with that
too--and probably have more demanding workloads than you.

The issue is, you're shooting in the dark unless you really understand
what you want to do and why. You also said HTPC. Is this basically a
large bucket for videos and other media? Some might say that's not as
important to keep online as, say, your email or personal documents.
It's your call. You also have to consider what kind of performance you
need--you probably won't see a performance increase here because you
only have two disks, and for redundancy every write will take place on
two disks, and at best, every read will be interleaved.

I'm going to go on a limb here and say for anyone (with data they want
to preserve), no matter what, backups make sense and are cost
effective. I'm going to be crazy and say that there's no reason that
someone who thinks they can afford a 8TB disk array and dual SLI video
cards, etc, etc, can't also consider some sort of disk or tape backup.
Cumbersome? Can be. But having worked with datasets and filesystems
that run into the hundreds of terabytes, and having backed them up to
tape, it makes sense. If you have something on the order of tens of
disks, sure, go ahead, take that next step and back them up somewhere
else to another set of disks. If you have more disks, seriously
consider tape--in terms of capacity and power consumption (and data
integrity), tape wins.

This is, of course, only really valid if you've got data worth preserving.

And don't even get me started on "silent corruption" and bit rate
errors on 2TB drives. But, heh, at least you didn't ask about raid 5
or 6. :)

This stuff, when starting out, rewards experimentation, and failures
(especially at home--this HTPC is at home, right?) are often great
sources for learning. So, good luck!

Cheers

cc

On Sat, Oct 24, 2009 at 5:01 AM, adfas asd <chimera_god@yahoo.com> wrote:
> Actually it it your solution which seems best at this point.  But I've been testing to see whether anyone else advocates it or another alternative.
>
> The division is stark;  some have been nothing but helpful, while others have done nothing but complain.  You are the only one right between.
>
>
> --- On Fri, 10/23/09, Bill Davidsen <davidsen@tmr.com> wrote:
>> I told him where and how to back up his data for about
>> 8-10% of the price he said it would cost. I explained (as
>> several other have) why no raid level is the same as a
>> backup.
>>
>> Sorry if that wasn't the thing you wanted to learn, but
>> after it has been explained multiple time, it doesn't seem
>> to have been sinking in. And clearly didn't this time. I
>> won't waste my time trying to educate people here any more.
>
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Chris Chen <muffaleta@gmail.com>
"The fact that yours is better than anyone else's
is not a guarantee that it's any good."
-- Seen on a wall
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Is My Data DESTROYED?!

[Leslie Rhorer]

> I'm going to go on a limb here and say for anyone (with data they want
> to preserve), no matter what, backups make sense and are cost
> effective. I'm going to be crazy and say that there's no reason that
> someone who thinks they can afford a 8TB disk array and dual SLI video
> cards, etc, etc, can't also consider some sort of disk or tape backup.

	I agree with the disk backup, but not the tape.

> Cumbersome? Can be. But having worked with datasets and filesystems

	Cumberesome, slow, kludgy, and expensive.

> that run into the hundreds of terabytes, and having backed them up to
> tape, it makes sense. If you have something on the order of tens of
> disks, sure, go ahead, take that next step and back them up somewhere
> else to another set of disks. If you have more disks, seriously
> consider tape--in terms of capacity and power consumption (and data
> integrity), tape wins.

	Power consumption, yes.  Capacity is a somewhat more complex
problem, with a number of variables.  For speed, tapes lose disastrously.
For cost, hard drives win unless the array is very large.  For reliability
and availability, drives win hands down.  I've had quite a bit of data lost
with bad tape sets, and the most persistent problems on my systems which do
use tapes involve the tape drives, even sans data loss.  Once someone wiped
out a directory which someone up in corporate was backing up to tape.  It
took 3 days to recover the directory, no doubt because no one could find the
tape.

Re: Is My Data DESTROYED?!

[Christopher Chen]

On Sat, Oct 24, 2009 at 6:52 PM, Leslie Rhorer <lrhorer@satx.rr.com> wrote:
>> I'm going to go on a limb here and say for anyone (with data they want
>> to preserve), no matter what, backups make sense and are cost
>> effective. I'm going to be crazy and say that there's no reason that
>> someone who thinks they can afford a 8TB disk array and dual SLI video
>> cards, etc, etc, can't also consider some sort of disk or tape backup.
>
>        I agree with the disk backup, but not the tape.
>
>> Cumbersome? Can be. But having worked with datasets and filesystems
>
>        Cumberesome, slow, kludgy, and expensive.

Well, like anything else, having a system helps. And by system I mean
a library, barcodes on all tapes, and a good tape storage system. Yes,
it involves Humans.

>
>> that run into the hundreds of terabytes, and having backed them up to
>> tape, it makes sense. If you have something on the order of tens of
>> disks, sure, go ahead, take that next step and back them up somewhere
>> else to another set of disks. If you have more disks, seriously
>> consider tape--in terms of capacity and power consumption (and data
>> integrity), tape wins.
>
>        Power consumption, yes.  Capacity is a somewhat more complex
> problem, with a number of variables.  For speed, tapes lose disastrously.
> For cost, hard drives win unless the array is very large.  For reliability
> and availability, drives win hands down.  I've had quite a bit of data lost
> with bad tape sets, and the most persistent problems on my systems which do
> use tapes involve the tape drives, even sans data loss.  Once someone wiped
> out a directory which someone up in corporate was backing up to tape.  It
> took 3 days to recover the directory, no doubt because no one could find the
> tape.

I'm not so sure about the speed--you can stream 100MB/sec to a single
tape drive, and if you have multiple in a library, it just scales
horizontally.

But, where I was working, we were also duplicating tape sets for
offsite, which means there was two copies per backup set.

Is this expensive? You betcha! But...you know. The bad old days of DDS
are also gone, so there's some rejoicing there.

:)

cc

-- 
Chris Chen <muffaleta@gmail.com>
"The fact that yours is better than anyone else's
is not a guarantee that it's any good."
-- Seen on a wall
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Is My Data DESTROYED?!

[Leslie Rhorer]

> On Sat, Oct 24, 2009 at 6:52 PM, Leslie Rhorer <lrhorer@satx.rr.com>
> wrote:
> >> I'm going to go on a limb here and say for anyone (with data they want
> >> to preserve), no matter what, backups make sense and are cost
> >> effective. I'm going to be crazy and say that there's no reason that
> >> someone who thinks they can afford a 8TB disk array and dual SLI video
> >> cards, etc, etc, can't also consider some sort of disk or tape backup.
> >
> >        I agree with the disk backup, but not the tape.
> >
> >> Cumbersome? Can be. But having worked with datasets and filesystems
> >
> >        Cumberesome, slow, kludgy, and expensive.
> 
> Well, like anything else, having a system helps. And by system I mean
> a library, barcodes on all tapes, and a good tape storage system. Yes,
> it involves Humans.

	Well, that wasn't quite my point, but it is another aspect of the
issue.

> >> that run into the hundreds of terabytes, and having backed them up to
> >> tape, it makes sense. If you have something on the order of tens of
> >> disks, sure, go ahead, take that next step and back them up somewhere
> >> else to another set of disks. If you have more disks, seriously
> >> consider tape--in terms of capacity and power consumption (and data
> >> integrity), tape wins.
> >
> >        Power consumption, yes.  Capacity is a somewhat more complex
> > problem, with a number of variables.  For speed, tapes lose
> disastrously.
> > For cost, hard drives win unless the array is very large.  For
> reliability
> > and availability, drives win hands down.  I've had quite a bit of data
> lost
> > with bad tape sets, and the most persistent problems on my systems which
> do
> > use tapes involve the tape drives, even sans data loss.  Once someone
> wiped
> > out a directory which someone up in corporate was backing up to tape.
>  It
> > took 3 days to recover the directory, no doubt because no one could find
> the
> > tape.
> 
> I'm not so sure about the speed--you can stream 100MB/sec to a single
> tape drive, and if you have multiple in a library, it just scales
> horizontally.

	First of all, that assumes the tape is loaded and ready.  It can
take hours or even days to retrieve a tape and load it.  Secondly, while the
tape can stream 100MB/sec, it isn't random access.  Finding a 200 byte file
in the middle of a 1T tape backup is going to take a while.  Getting it from
an online backup server takes perhaps 10ms after the admin finishes typing
the copy command.

> But, where I was working, we were also duplicating tape sets for
> offsite, which means there was two copies per backup set.
> 
> Is this expensive? You betcha! But...you know. The bad old days of DDS
> are also gone, so there's some rejoicing there.

	They may be for you.  I have to manage over 300 of the beasts on the
same number of hosts.  What's worse, not only are the backups themselves
often incompatible, the drives often can't even use the same tapes.  I have
to see to it a half dozen different tape types get stocked in 75 different
cities.  Then I have to try to make sure the gopher in every city remembers
to replace the tape.

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is My Data DESTROYED?!

[Thomas Fjellstrom]

On Sat October 24 2009, Leslie Rhorer wrote:
> > On Sat, Oct 24, 2009 at 6:52 PM, Leslie Rhorer <lrhorer@satx.rr.com>
> >
> > wrote:
> > >> I'm going to go on a limb here and say for anyone (with data they want
> > >> to preserve), no matter what, backups make sense and are cost
> > >> effective. I'm going to be crazy and say that there's no reason that
> > >> someone who thinks they can afford a 8TB disk array and dual SLI video
> > >> cards, etc, etc, can't also consider some sort of disk or tape backup.
> > >
> > >        I agree with the disk backup, but not the tape.
> > >
> > >> Cumbersome? Can be. But having worked with datasets and filesystems
> > >
> > >        Cumberesome, slow, kludgy, and expensive.
> >
> > Well, like anything else, having a system helps. And by system I mean
> > a library, barcodes on all tapes, and a good tape storage system. Yes,
> > it involves Humans.
> 
> 	Well, that wasn't quite my point, but it is another aspect of the
> issue.
> 
> > >> that run into the hundreds of terabytes, and having backed them up to
> > >> tape, it makes sense. If you have something on the order of tens of
> > >> disks, sure, go ahead, take that next step and back them up somewhere
> > >> else to another set of disks. If you have more disks, seriously
> > >> consider tape--in terms of capacity and power consumption (and data
> > >> integrity), tape wins.
> > >
> > >        Power consumption, yes.  Capacity is a somewhat more complex
> > > problem, with a number of variables.  For speed, tapes lose
> >
> > disastrously.
> >
> > > For cost, hard drives win unless the array is very large.  For
> >
> > reliability
> >
> > > and availability, drives win hands down.  I've had quite a bit of data
> >
> > lost
> >
> > > with bad tape sets, and the most persistent problems on my systems
> > > which
> >
> > do
> >
> > > use tapes involve the tape drives, even sans data loss.  Once someone
> >
> > wiped
> >
> > > out a directory which someone up in corporate was backing up to tape.
> >
> >  It
> >
> > > took 3 days to recover the directory, no doubt because no one could
> > > find
> >
> > the
> >
> > > tape.
> >
> > I'm not so sure about the speed--you can stream 100MB/sec to a single
> > tape drive, and if you have multiple in a library, it just scales
> > horizontally.
> 
> 	First of all, that assumes the tape is loaded and ready.  It can
> take hours or even days to retrieve a tape and load it.  Secondly, while
>  the tape can stream 100MB/sec, it isn't random access.  Finding a 200 byte
>  file in the middle of a 1T tape backup is going to take a while.  Getting
>  it from an online backup server takes perhaps 10ms after the admin
>  finishes typing the copy command.

Wouldn't you use some 'tar' like format on the tape so there's a file index 
you can search without having to scan the entire tape? Then you can just 
"ffwd" (seek) to the position. _should_ be lots faster than reading all of the 
data from the beginning to the files location trying to find it. Or maybe 
there's something I'm missing about tapes?

> > But, where I was working, we were also duplicating tape sets for
> > offsite, which means there was two copies per backup set.
> >
> > Is this expensive? You betcha! But...you know. The bad old days of DDS
> > are also gone, so there's some rejoicing there.
> 
> 	They may be for you.  I have to manage over 300 of the beasts on the
> same number of hosts.  What's worse, not only are the backups themselves
> often incompatible, the drives often can't even use the same tapes.  I have
> to see to it a half dozen different tape types get stocked in 75 different
> cities.  Then I have to try to make sure the gopher in every city remembers
> to replace the tape.

:(

> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Thomas Fjellstrom
tfjellstrom@shaw.ca

RE: Is My Data DESTROYED?!

[Guy Watkins]

} -----Original Message-----
} From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
} owner@vger.kernel.org] On Behalf Of Thomas Fjellstrom
} Sent: Sunday, October 25, 2009 1:26 AM
} To: linux-raid@vger.kernel.org
} Subject: Re: Is My Data DESTROYED?!
} 
} On Sat October 24 2009, Leslie Rhorer wrote:
} > > On Sat, Oct 24, 2009 at 6:52 PM, Leslie Rhorer <lrhorer@satx.rr.com>
} > >
} > > wrote:
} > > >> I'm going to go on a limb here and say for anyone (with data they
} want
} > > >> to preserve), no matter what, backups make sense and are cost
} > > >> effective. I'm going to be crazy and say that there's no reason
} that
} > > >> someone who thinks they can afford a 8TB disk array and dual SLI
} video
} > > >> cards, etc, etc, can't also consider some sort of disk or tape
} backup.
} > > >
} > > >        I agree with the disk backup, but not the tape.
} > > >
} > > >> Cumbersome? Can be. But having worked with datasets and filesystems
} > > >
} > > >        Cumberesome, slow, kludgy, and expensive.
} > >
} > > Well, like anything else, having a system helps. And by system I mean
} > > a library, barcodes on all tapes, and a good tape storage system. Yes,
} > > it involves Humans.
} >
} > 	Well, that wasn't quite my point, but it is another aspect of the
} > issue.
} >
} > > >> that run into the hundreds of terabytes, and having backed them up
} to
} > > >> tape, it makes sense. If you have something on the order of tens of
} > > >> disks, sure, go ahead, take that next step and back them up
} somewhere
} > > >> else to another set of disks. If you have more disks, seriously
} > > >> consider tape--in terms of capacity and power consumption (and data
} > > >> integrity), tape wins.
} > > >
} > > >        Power consumption, yes.  Capacity is a somewhat more complex
} > > > problem, with a number of variables.  For speed, tapes lose
} > >
} > > disastrously.
} > >
} > > > For cost, hard drives win unless the array is very large.  For
} > >
} > > reliability
} > >
} > > > and availability, drives win hands down.  I've had quite a bit of
} data
} > >
} > > lost
} > >
} > > > with bad tape sets, and the most persistent problems on my systems
} > > > which
} > >
} > > do
} > >
} > > > use tapes involve the tape drives, even sans data loss.  Once
} someone
} > >
} > > wiped
} > >
} > > > out a directory which someone up in corporate was backing up to
} tape.
} > >
} > >  It
} > >
} > > > took 3 days to recover the directory, no doubt because no one could
} > > > find
} > >
} > > the
} > >
} > > > tape.
} > >
} > > I'm not so sure about the speed--you can stream 100MB/sec to a single
} > > tape drive, and if you have multiple in a library, it just scales
} > > horizontally.
} >
} > 	First of all, that assumes the tape is loaded and ready.  It can
} > take hours or even days to retrieve a tape and load it.  Secondly, while
} >  the tape can stream 100MB/sec, it isn't random access.  Finding a 200
} byte
} >  file in the middle of a 1T tape backup is going to take a while.
} Getting
} >  it from an online backup server takes perhaps 10ms after the admin
} >  finishes typing the copy command.
} 
} Wouldn't you use some 'tar' like format on the tape so there's a file
} index
} you can search without having to scan the entire tape? Then you can just
} "ffwd" (seek) to the position. _should_ be lots faster than reading all of
} the
} data from the beginning to the files location trying to find it. Or maybe
} there's something I'm missing about tapes?

tar does not have an index.  The file name comes just before the file.  I
use cpio and gzip.  But I write to a USB disk.  I have restored 1 file, and
it had to scan through the data to find the file.

But back to your point.  I don't know of any open source software that can
restore a file quickly from tape.  And with a disk backup, if you use a file
system you can restore quickly.  But a file system wastes space.  That is
why I use cpio and gzip.  I backup about 500GB to a file about 350GB.  But
it really depends on how well your data compresses.

} 
} > > But, where I was working, we were also duplicating tape sets for
} > > offsite, which means there was two copies per backup set.
} > >
} > > Is this expensive? You betcha! But...you know. The bad old days of DDS
} > > are also gone, so there's some rejoicing there.
} >
} > 	They may be for you.  I have to manage over 300 of the beasts on the
} > same number of hosts.  What's worse, not only are the backups themselves
} > often incompatible, the drives often can't even use the same tapes.  I
} have
} > to see to it a half dozen different tape types get stocked in 75
} different
} > cities.  Then I have to try to make sure the gopher in every city
} remembers
} > to replace the tape.
} 
} :(
} 
} > --
} > To unsubscribe from this list: send the line "unsubscribe linux-raid" in
} > the body of a message to majordomo@vger.kernel.org
} > More majordomo info at  http://vger.kernel.org/majordomo-info.html
} >
} 
} 
} --
} Thomas Fjellstrom
} tfjellstrom@shaw.ca
} --
} To unsubscribe from this list: send the line "unsubscribe linux-raid" in
} the body of a message to majordomo@vger.kernel.org
} More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is My Data DESTROYED?!

[Eyal Lebedinsky]

Guy,

'tar -R' does list the block# where a file starts (effectively an index).
You then forward to the file-mark of your file and therein you seek to
the desired block#. Other archiving tools also do this (e.g. afio which
I prefer).

I used a script that automatically greps the tar listing to extract this
info and extract the desired file from the tape. A few minues is all it
took.

But I use disks for backup these days...

cheers

Guy Watkins wrote:
> } -----Original Message-----
> } From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
> } owner@vger.kernel.org] On Behalf Of Thomas Fjellstrom
> } Sent: Sunday, October 25, 2009 1:26 AM
> } To: linux-raid@vger.kernel.org
> } Subject: Re: Is My Data DESTROYED?!
> } 
> } On Sat October 24 2009, Leslie Rhorer wrote:
  [trim]
> } Wouldn't you use some 'tar' like format on the tape so there's a file
> } index
> } you can search without having to scan the entire tape? Then you can just
> } "ffwd" (seek) to the position. _should_ be lots faster than reading all of
> } the
> } data from the beginning to the files location trying to find it. Or maybe
> } there's something I'm missing about tapes?
> 
> tar does not have an index.  The file name comes just before the file.  I
> use cpio and gzip.  But I write to a USB disk.  I have restored 1 file, and
> it had to scan through the data to find the file.
[trim]

-- 
Eyal Lebedinsky	(eyal@eyal.emu.id.au)

RE: Is My Data DESTROYED?!

[Guy Watkins]

Cool, I learned something.  Thanks.

I use disks too.  Could "seek" using dd, but I also gzip my stuff and use
cpio.  :(  Anyway, I almost never need to restore a file.  :)

} -----Original Message-----
} From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
} owner@vger.kernel.org] On Behalf Of Eyal Lebedinsky
} Sent: Sunday, October 25, 2009 2:22 AM
} To: linux-raid@vger.kernel.org
} Subject: Re: Is My Data DESTROYED?!
} 
} Guy,
} 
} 'tar -R' does list the block# where a file starts (effectively an index).
} You then forward to the file-mark of your file and therein you seek to
} the desired block#. Other archiving tools also do this (e.g. afio which
} I prefer).
} 
} I used a script that automatically greps the tar listing to extract this
} info and extract the desired file from the tape. A few minues is all it
} took.
} 
} But I use disks for backup these days...
} 
} cheers
} 
} Guy Watkins wrote:
} > } -----Original Message-----
} > } From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
} > } owner@vger.kernel.org] On Behalf Of Thomas Fjellstrom
} > } Sent: Sunday, October 25, 2009 1:26 AM
} > } To: linux-raid@vger.kernel.org
} > } Subject: Re: Is My Data DESTROYED?!
} > }
} > } On Sat October 24 2009, Leslie Rhorer wrote:
}   [trim]
} > } Wouldn't you use some 'tar' like format on the tape so there's a file
} > } index
} > } you can search without having to scan the entire tape? Then you can
} just
} > } "ffwd" (seek) to the position. _should_ be lots faster than reading
} all of
} > } the
} > } data from the beginning to the files location trying to find it. Or
} maybe
} > } there's something I'm missing about tapes?
} >
} > tar does not have an index.  The file name comes just before the file.
} I
} > use cpio and gzip.  But I write to a USB disk.  I have restored 1 file,
} and
} > it had to scan through the data to find the file.
} [trim]
} 
} --
} Eyal Lebedinsky	(eyal@eyal.emu.id.au)
} --
} To unsubscribe from this list: send the line "unsubscribe linux-raid" in
} the body of a message to majordomo@vger.kernel.org
} More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Is My Data DESTROYED?!

[Leslie Rhorer]

> Cool, I learned something.  Thanks.
> 
> I use disks too.  Could "seek" using dd, but I also gzip my stuff and use
> cpio.  :(  Anyway, I almost never need to restore a file.  :)

	I rather like fbackup combined with gzip, but I don't know if there
is a Linux port of fbackup.  I use fbackup to create a named index for each
backup set, whether on disk or tape.  This makes it easy to see if a
particular file is on an archive without having to load the archive.

RE: Is My Data DESTROYED?!

[Guy Watkins]

} -----Original Message-----
} From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
} owner@vger.kernel.org] On Behalf Of Leslie Rhorer
} Sent: Sunday, October 25, 2009 9:36 PM
} To: linux-raid@vger.kernel.org
} Subject: RE: Is My Data DESTROYED?!
} 
} > Cool, I learned something.  Thanks.
} >
} > I use disks too.  Could "seek" using dd, but I also gzip my stuff and
} use
} > cpio.  :(  Anyway, I almost never need to restore a file.  :)
} 
} 	I rather like fbackup combined with gzip, but I don't know if there
} is a Linux port of fbackup.  I use fbackup to create a named index for
} each
} backup set, whether on disk or tape.  This makes it easy to see if a
} particular file is on an archive without having to load the archive.
} 

Where do you keep this index?  Hopefully not on the disk that needs to be
restored.  :)

I thought about it, for my needs I don't need an index.  You don't need an
index for a full restore and I only need to restore once every few years.
And so far, never needed a full restore, just a file or so.  I can live with
a few hours to restore 1 file.  But I really need a faster backup.  My 500GB
USB disks gives me about 15 MB/sec.  I don't know why it is so slow.  Should
be able to do 40+.

Oh, I did have a 22 tape library with a DLT-8000.  But it failed a few years
ago.  Was really cool, but took forever to backup 300-400GB.  I guess my USB
disk is about the same speed, and it takes forever too.

Re: Is My Data DESTROYED?!

[Eyal Lebedinsky]

Guy,

I use a hot-swap sata enclosure for my disk backup. Mine is installed in
one 5.25" slot, elsewhere I have used an external esata version of the
same thing. Cheap and gives me the full native speed of the disk.

cheers
	Eyal

Guy Watkins wrote:
> } -----Original Message-----
> } From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
> } owner@vger.kernel.org] On Behalf Of Leslie Rhorer
> } Sent: Sunday, October 25, 2009 9:36 PM
> } To: linux-raid@vger.kernel.org
> } Subject: RE: Is My Data DESTROYED?!
> } 
> } > Cool, I learned something.  Thanks.
> } >
> } > I use disks too.  Could "seek" using dd, but I also gzip my stuff and
> } use
> } > cpio.  :(  Anyway, I almost never need to restore a file.  :)
> } 
> } 	I rather like fbackup combined with gzip, but I don't know if there
> } is a Linux port of fbackup.  I use fbackup to create a named index for
> } each
> } backup set, whether on disk or tape.  This makes it easy to see if a
> } particular file is on an archive without having to load the archive.
> } 
> 
> Where do you keep this index?  Hopefully not on the disk that needs to be
> restored.  :)
> 
> I thought about it, for my needs I don't need an index.  You don't need an
> index for a full restore and I only need to restore once every few years.
> And so far, never needed a full restore, just a file or so.  I can live with
> a few hours to restore 1 file.  But I really need a faster backup.  My 500GB
> USB disks gives me about 15 MB/sec.  I don't know why it is so slow.  Should
> be able to do 40+.
> 
> Oh, I did have a 22 tape library with a DLT-8000.  But it failed a few years
> ago.  Was really cool, but took forever to backup 300-400GB.  I guess my USB
> disk is about the same speed, and it takes forever too.

-- 
Eyal Lebedinsky	(eyal@eyal.emu.id.au)

Re: Is My Data DESTROYED?!

[Thomas Fjellstrom]

On Mon October 26 2009, Eyal Lebedinsky wrote:
> Guy,
> 
> I use a hot-swap sata enclosure for my disk backup. Mine is installed in
> one 5.25" slot, elsewhere I have used an external esata version of the
> same thing. Cheap and gives me the full native speed of the disk.

I have one of those 4-in-3 bay converters, 4 hotswap 3.5" bays, in 3 5.25" 
bays. Really rather nice. Probably get another one later.

> cheers
> 	Eyal
> 
> Guy Watkins wrote:
> > } -----Original Message-----
> > } From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
> > } owner@vger.kernel.org] On Behalf Of Leslie Rhorer
> > } Sent: Sunday, October 25, 2009 9:36 PM
> > } To: linux-raid@vger.kernel.org
> > } Subject: RE: Is My Data DESTROYED?!
> > }
> > } > Cool, I learned something.  Thanks.
> > } >
> > } > I use disks too.  Could "seek" using dd, but I also gzip my stuff and
> > } use
> > } > cpio.  :(  Anyway, I almost never need to restore a file.  :)
> > }
> > } 	I rather like fbackup combined with gzip, but I don't know if there
> > } is a Linux port of fbackup.  I use fbackup to create a named index for
> > } each
> > } backup set, whether on disk or tape.  This makes it easy to see if a
> > } particular file is on an archive without having to load the archive.
> > }
> >
> > Where do you keep this index?  Hopefully not on the disk that needs to be
> > restored.  :)
> >
> > I thought about it, for my needs I don't need an index.  You don't need
> > an index for a full restore and I only need to restore once every few
> > years. And so far, never needed a full restore, just a file or so.  I can
> > live with a few hours to restore 1 file.  But I really need a faster
> > backup.  My 500GB USB disks gives me about 15 MB/sec.  I don't know why
> > it is so slow.  Should be able to do 40+.
> >
> > Oh, I did have a 22 tape library with a DLT-8000.  But it failed a few
> > years ago.  Was really cool, but took forever to backup 300-400GB.  I
> > guess my USB disk is about the same speed, and it takes forever too.
> 


-- 
Thomas Fjellstrom
tfjellstrom@shaw.ca

Re: Is My Data DESTROYED?!

[John Robinson]

On Mon, 26 October, 2009 6:14 pm, Thomas Fjellstrom wrote:
> On Mon October 26 2009, Eyal Lebedinsky wrote:
>> Guy,
>>
>> I use a hot-swap sata enclosure for my disk backup. Mine is installed in
>> one 5.25" slot, elsewhere I have used an external esata version of the
>> same thing. Cheap and gives me the full native speed of the disk.
>
> I have one of those 4-in-3 bay converters, 4 hotswap 3.5" bays, in 3 5.25"
> bays. Really rather nice. Probably get another one later.

I dithered for a while between cheap IcyDock or Jou-Jye 4-in-3 or 5-in-3
vs a SuperMicro 5-in-3, ended up deciding I could stretch the extra few
quid for the SuperMicro, and am pleased with the result. That's not to say
there's anything wrong with the IcyDock or Jou-Jye ones, I've not used
them[1]. But I use this for main data drives, not backups. Still, I too
will probably get another one when 5 drives aren't enough, but that's a
while away (I'll probably need a bigger tape drive for the library first,
the current one's only an LTO-2).

Cheers,

John.


[1] The IcyDock 1-drive SATA caddy I have is very plasticky and doesn't
feel like it'll stand up to many swaps, which is what I bought it for.

RE: Is My Data DESTROYED?!

[Leslie Rhorer]

> > I use a hot-swap sata enclosure for my disk backup. Mine is installed in
> > one 5.25" slot, elsewhere I have used an external esata version of the
> > same thing. Cheap and gives me the full native speed of the disk.
> 
> I have one of those 4-in-3 bay converters, 4 hotswap 3.5" bays, in 3 5.25"
> bays. Really rather nice. Probably get another one later.

	When I first went to SATA disks, I picked up a 12 bay multilane
enclosure from Norcotek coupled with a Highpoint SAS RAID controller.  It
was a disaster.  With a small number of drives in the enclosure, and with
some fiddling, I could get the system to be fairly stable.  Once I went
beyond 6 disks, however, it was an unending nightmare of problems.  I tried
everything, including gutting the Infiniband adapters and putting in port
multipliers, switching to mdadm.  Right about a year ago, I scrapped the
Norcotek enclosure and picked up a 12 bay port multiplier enclosure from PC
PitStop.  I've been thrilled with it.  They have a 20 bay enclosure which I
believe I am going to get to facilitate my next expansion, early next year.

Re: Is My Data DESTROYED?!

[Thomas Fjellstrom]

On Mon October 26 2009, Leslie Rhorer wrote:
> > > I use a hot-swap sata enclosure for my disk backup. Mine is installed
> > > in one 5.25" slot, elsewhere I have used an external esata version of
> > > the same thing. Cheap and gives me the full native speed of the disk.
> >
> > I have one of those 4-in-3 bay converters, 4 hotswap 3.5" bays, in 3
> > 5.25" bays. Really rather nice. Probably get another one later.
> 
> 	When I first went to SATA disks, I picked up a 12 bay multilane
> enclosure from Norcotek coupled with a Highpoint SAS RAID controller.  It
> was a disaster.  With a small number of drives in the enclosure, and with
> some fiddling, I could get the system to be fairly stable.  Once I went
> beyond 6 disks, however, it was an unending nightmare of problems.  I tried
> everything, including gutting the Infiniband adapters and putting in port
> multipliers, switching to mdadm.  Right about a year ago, I scrapped the
> Norcotek enclosure and picked up a 12 bay port multiplier enclosure from PC
> PitStop.  I've been thrilled with it.  They have a 20 bay enclosure which I
> believe I am going to get to facilitate my next expansion, early next year.

A guy I know got a SuperMicro SC846E1-R900B case. 24 hotswap per chassis, with 
the capability to chain in more of them to the same SAS adapter. Rather 
impressive. I can't afford a $1200 case though, not yet.

> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Thomas Fjellstrom
tfjellstrom@shaw.ca

Re: Is My Data DESTROYED?!

[adfas asd]

--- On Mon, 10/26/09, Thomas Fjellstrom <tfjellstrom@shaw.ca> wrote:
> A guy I know got a SuperMicro SC846E1-R900B case. 24
> hotswap per chassis, with 
> the capability to chain in more of them to the same SAS
> adapter. Rather 
> impressive. I can't afford a $1200 case though, not yet.

Yes, it looks like the SuperMicro 3-5 for me.



      

Re: Is My Data DESTROYED?!

[NiftyFedora Mitch]

On Tue, Oct 27, 2009 at 6:37 AM, adfas asd <chimera_god@yahoo.com> wrote:
> --- On Mon, 10/26/09, Thomas Fjellstrom <tfjellstrom@shaw.ca> wrote:
>> A guy I know got a SuperMicro SC846E1-R900B case. 24
>> hotswap per chassis, with
>> the capability to chain in more of them to the same SAS
>> adapter. Rather
>> impressive. I can't afford a $1200 case though, not yet.
>
> Yes, it looks like the SuperMicro 3-5 for me.
>
>

Adfas,

It seems to me reading this long thread that some design and
practice might have helped here.

First Q: did you need a raid.
Next Q: did you rehearse and practice recovery.
Next Q; did you build a set of notes on how you built your RAID
Next Q: did you write down your rehearsed recovery procedures.

For HTPC I would not have build a RAID for a big storage
resource.  I might have built it for speed.

Having made lots of typos in my life I would not have built a
RAID in lieu of  a backup tool and process.

I would have built it as a set of individual disks
and individual file systems.
   a; a-bak
   b; b-bak
   etc.
  OR
   RaidA; RaidA-bak

I would alternate between A and B on the record process
and alternate a scripted rsync or cp based backup of data.
The script is to eliminate typo errors in my environment
and provide a log of what I did "Exactly".

I would consider playback from N or N-bak depending on which
device was not busy and if my software could be that smart.

It seems to me that simplicity from the system admin point
of view would win out in the design process.  Too often
the design process ignores how difficult it is for a system
admin to get it EXACTLY correct when it is something that
is done once a year or less and depends on configuration
and setup notes that are a year old, difficult to update
or exist on the RAID itself.

The number of times I have built some system setup
that works for years and then years later needs an update
or breaks....  boggles my mind and I have done it to myself
and know better.

Knowing RCS and friends helps!





-- 
        NiftyFedora
        T o m   M i t c h e l l

RE: Is My Data DESTROYED?!

[Leslie Rhorer]

> } 	I rather like fbackup combined with gzip, but I don't know if there
> } is a Linux port of fbackup.  I use fbackup to create a named index for
> } each
> } backup set, whether on disk or tape.  This makes it easy to see if a
> } particular file is on an archive without having to load the archive.
> }
> 
> Where do you keep this index?  Hopefully not on the disk that needs to be
> restored.  :)

	That would be rather silly, although it can always be rebuilt from
the backup set itself.  No, the indices are all kept on the hard drive which
holds the most recent backups.  The tapes are taken off-premise.

Re: Is My Data DESTROYED?!

[Christopher Chen]

On Sat, Oct 24, 2009 at 10:26 PM, Thomas Fjellstrom <tfjellstrom@shaw.ca> wrote:
> On Sat October 24 2009, Leslie Rhorer wrote:
>> > On Sat, Oct 24, 2009 at 6:52 PM, Leslie Rhorer <lrhorer@satx.rr.com>
>> > I'm not so sure about the speed--you can stream 100MB/sec to a single
>> > tape drive, and if you have multiple in a library, it just scales
>> > horizontally.
>>
>>       First of all, that assumes the tape is loaded and ready.  It can
>> take hours or even days to retrieve a tape and load it.  Secondly, while
>>  the tape can stream 100MB/sec, it isn't random access.  Finding a 200 byte
>>  file in the middle of a 1T tape backup is going to take a while.  Getting
>>  it from an online backup server takes perhaps 10ms after the admin
>>  finishes typing the copy command.
>
> Wouldn't you use some 'tar' like format on the tape so there's a file index
> you can search without having to scan the entire tape? Then you can just
> "ffwd" (seek) to the position. _should_ be lots faster than reading all of the
> data from the beginning to the files location trying to find it. Or maybe
> there's something I'm missing about tapes?

Yeah, these are all concerns. The last few jobs I've been at have
automatic libraries that hold about a hundred tapes, so, it wasn't
much of an issue. The operator would swap them out on a daily basis,
but there were always tapes ready. And, the library had at least four
drives in it, so, you can imagine the aggregate throughput.

Like I said before, this is a entirely different scale than what most
people deal with.

Thomas, I think Leslie meant the seek time to get to the file. With
most backup systems, file metadata is kept in databases so the catalog
can be queried to find the right tape, etc, etc.

Anyway, yes, not really pertinent to the concerns of a guy with a 1G
ethernet multi-room raid 10.

cc

-- 
Chris Chen <muffaleta@gmail.com>
"The fact that yours is better than anyone else's
is not a guarantee that it's any good."
-- Seen on a wall
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Is My Data DESTROYED?!

[Leslie Rhorer]

> Wouldn't you use some 'tar' like format on the tape so there's a file
> index

	Not "tar like".  Tar.  "Tar" stands for "tape archive".  Without the
-f option, tar will write to the location specified by the TAPE environment
variable (or stdout if the variable is not set).  Of course there are other
utilities which can be used, such as cpio and fbackup, and I am sure some
drives may have their own utilities.

> you can search without having to scan the entire tape? Then you can just
> "ffwd" (seek) to the position. _should_ be lots faster than reading all of
> the
> data from the beginning to the files location trying to find it. Or maybe
> there's something I'm missing about tapes?

	Many tape drives cannot seek any faster than they can read.  After
all, a seek *IS* a read.  Even if a particular drive can seek faster than it
can read, however, it will still take a significant amount of time to seek
to the location and read the data.  How quickly depends on the drive, but
under no circumstances will it be milliseconds, or even single-digit
seconds.  High end tape drives of course are much faster than lower cost
tape drives.  In the realm of what is within the budget of a consumer
system, don't hold your breath waiting for the drive to find the data.

Re: Is My Data DESTROYED?!

[adfas asd]

--- On Sat, 10/24/09, Christopher Chen <muffaleta@gmail.com> wrote:
> Part of this sounds like you're looking for best practices.
> I imagine
> that's why you made a raid 10, and why you're using JFS.
> It's probably
> why you've been fiddling around with blockdev --setra and
> all that
> too

Exactly.

> The issue is, you're shooting in the dark unless you really
> understand
> what you want to do and why. You also said HTPC. Is this
> basically a
> large bucket for videos and other media?

Yes it's my video collection which I've worked long and hard to gather.  Your point is taken that it doesn't have to be hot online, but if it can why not?  I hate tape, and claim that it's obsolete.

I am shocked at all who think that human error is so prevalent, and in fact obviates the case for RAID as backup.  I've run Debian for 12 years on all my personal servers and remember literally only 3 or 4 cases in that time where I muggered something up and had to go to backup.  There must be alot of fsckups out there...

That said, I am now considering making the storage server in the garage a backup rather than a RAID.  This means I'll want it to go to sleep most of the time, and I'll need a mobo that does wake-on-LAN successfully and automatically.

Now a backup by cron is nice and all, but what if it silently fails in some obscure way?  This is one thing I like about RAID or ZFS, it lets you know when anything's wrong.  I can imagine setting up a fancy-pants backup system then going about my life, and some quirk happens on the next update which subtlely hoses my exotic backup system.  It is desirable to have bolt-tight assurance of backed-up data.  (And please don't bore us with 'nothing is for sure')  

Seems like a sync process, and then a checksum process to compare drives and email a result, although minor files are changing all the time and I wouldn't want to be notified if /tmp has changed.

Also I've noticed rsync mentioned several times.  This seems to have facilities for incremental backups, but I've also read that it is non-secure over networks and that we should use scp instead.  But scp doesn't seem to have incremental attributes.  Yes, this is my home LAN, but I have a thing about security in and out.  Isn't there another way of syncing two disks (over a network)?




      

Re: Is My Data DESTROYED?!

[Gabor Gombas]

On Sun, Oct 25, 2009 at 05:46:04AM -0700, adfas asd wrote:

> I am shocked at all who think that human error is so prevalent, and in
> fact obviates the case for RAID as backup.  I've run Debian for 12
> years on all my personal servers and remember literally only 3 or 4
> cases in that time where I muggered something up and had to go to
> backup.  There must be alot of fsckups out there...

Again, RAID is _not_ backup. "Backup" is something that can retrieve a
file if you've deleted it or if you've accidentally overwritten it. RAID
cannot do that.

RAID is only good for increasing your availability, which means that you
have to restore data from backup _less often_, and you can survive _some_
hardware errors without having to shut down the system and restoring
everything from backup.

> Now a backup by cron is nice and all, but what if it silently fails in
> some obscure way?

There are a couple of golden rules about backups. One such rule is that
you should check at regular intervals that your backup is intact, and
you can in fact restore your data from the backup. A good backup
solution is never a "do it once and forget about it" kind of thing.

> This is one thing I like about RAID or ZFS, it lets
> you know when anything's wrong.

No. They let you know when a limited set of errors conditions occur.
Neither RAID nor ZFS will complain if you delete the wrong file or if
you accidentally overwrite the show you've recorded yesterday. A good
backup solution protects you from both.

> Also I've noticed rsync mentioned several times.  This seems to have
> facilities for incremental backups, but I've also read that it is
> non-secure over networks and that we should use scp instead.  But scp
> doesn't seem to have incremental attributes.  Yes, this is my home
> LAN, but I have a thing about security in and out.  Isn't there
> another way of syncing two disks (over a network)?

I don't know what you have read but rsync over ssh is certainly secure
enough.

Gabor

-- 
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------

Re: Is My Data DESTROYED?!

[adfas asd]

--- On Sun, 10/25/09, Gabor Gombas <gombasg@sztaki.hu> wrote:
> > I am shocked at all who think that human error is so
> prevalent, and in
> > fact obviates the case for RAID as backup.  I've
> run Debian for 12
> > years on all my personal servers and remember
> literally only 3 or 4
> > cases in that time where I muggered something up and
> had to go to
> > backup.  There must be alot of fsckups out
> there...
> 
> Again, RAID is _not_ backup. "Backup" is something that can
> retrieve a
> file if you've deleted it or if you've accidentally
> overwritten it. RAID
> cannot do that.

You are not understanding the words what are coming out of my mouf...


> > Now a backup by cron is nice and all, but what if it
> silently fails in
> > some obscure way?
> 
> There are a couple of golden rules about backups. One such
> rule is that
> you should check at regular intervals that your backup is
> intact,

LOL
For terabytes?  Get real.  


> > This is one thing I like about RAID or ZFS, it lets
> > you know when anything's wrong.
> 
> No. They let you know when a limited set of errors
> conditions occur.
> Neither RAID nor ZFS will complain if you delete the wrong
> file or if
> you accidentally overwrite the show you've recorded
> yesterday. A good
> backup solution protects you from both.

Again, you are not understanding.
 





      

Re: Is My Data DESTROYED?!

[Christopher Chen]

On Sun, Oct 25, 2009 at 8:47 AM, adfas asd <chimera_god@yahoo.com> wrote:
> --- On Sun, 10/25/09, Gabor Gombas <gombasg@sztaki.hu> wrote:
>> > I am shocked at all who think that human error is so
>> prevalent, and in
>> > fact obviates the case for RAID as backup.  I've
>> run Debian for 12
>> > years on all my personal servers and remember
>> literally only 3 or 4
>> > cases in that time where I muggered something up and
>> had to go to
>> > backup.  There must be alot of fsckups out
>> there...
>>
>> Again, RAID is _not_ backup. "Backup" is something that can
>> retrieve a
>> file if you've deleted it or if you've accidentally
>> overwritten it. RAID
>> cannot do that.
>
> You are not understanding the words what are coming out of my mouf...

Yes, it's true. You're asking for a magic solution that gives you data
security and performance with a full audit path that alerts you if
anything goes wrong.

There exist technologies that allow for real-time off-machine
replication, but I think what all the other sysadmins on the list
(which, mind you, have worked longer than you, and have experience
with larger installations than you) are trying to tell you something.
People on this list have spent hours responding to this one thread,
and a few of them have written you off.

RAID will only save you from a set of hardware failures. These are a
cause of concern but as Leslie has rightfully said, they will not
protect you against software bugs or user error, which is a primary
cause of concern.

I think you should do both. You should do some sort of fault tolerant
RAID on your primary HTPC, a simple mirror, or a RAID 10 of 4 drives.

You should also back up that data with a system that runs on a regular
basis, but NOT in real-time, because what would happen is you'd
accidentally delete a file, and poof!, the deletion is replicated to
the other machine. Not very useful.

>
>
>> > Now a backup by cron is nice and all, but what if it
>> silently fails in
>> > some obscure way?
>>
>> There are a couple of golden rules about backups. One such
>> rule is that
>> you should check at regular intervals that your backup is
>> intact,
>
> LOL
> For terabytes?  Get real.

Sir, we are real. People are doing this every day on data sets
hundreds of times larger than yours, with real data, and are
professionally responsible for it. If you fail to see that, I don't
know what to say.

>
>
>> > This is one thing I like about RAID or ZFS, it lets
>> > you know when anything's wrong.
>>
>> No. They let you know when a limited set of errors
>> conditions occur.
>> Neither RAID nor ZFS will complain if you delete the wrong
>> file or if
>> you accidentally overwrite the show you've recorded
>> yesterday. A good
>> backup solution protects you from both.
>
> Again, you are not understanding.

Yeah, you're probably right. I'm done.

cc

-- 
Chris Chen <muffaleta@gmail.com>
"The fact that yours is better than anyone else's
is not a guarantee that it's any good."
-- Seen on a wall
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is My Data DESTROYED?!

[Gabor Gombas]

On Sun, Oct 25, 2009 at 08:47:54AM -0700, adfas asd wrote:

> LOL
> For terabytes?  Get real.  

A couple of terabytes of data is not that much, really. But in the end
it all boils down to how much do you care about your data. If you _do_
care, then _you_ must make regular and continuous efforts to keep it
safe. There is no free lunch.

Gabor

-- 
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------

RE: Is My Data DESTROYED?!

[Leslie Rhorer]

> Yes it's my video collection which I've worked long and hard to gather.
> Your point is taken that it doesn't have to be hot online, but if it can
> why not?  I hate tape, and claim that it's obsolete.

	I never suggested tape for you.  In a data center, where hard disk
backup systems can run many tens of thousands or even many hundreds of
thousands of dollars, they are the medium of choice.  As to being obsolete,
tape systems are far better than they used to be, but they are a poor choice
for systems smaller than 50 - 100T.

> I am shocked at all who think that human error is so prevalent, and in
> fact obviates the case for RAID as backup.  I've run Debian for 12 years
> on all my personal servers and remember literally only 3 or 4 cases in
> that time where I muggered something up and had to go to backup.  There
> must be alot of fsckups out there...

	Half the files I have lost on my video system were due to my
personal errors.  Absolutely none were due to drive failures.  By a very
wide margin, the most common cause of data loss is human error.  EVERY
SINGLE FILE THAT HAS EVER BEEN LOST SINCE THE FIRST DIGITAL COMPUTER WAS
BUILT HAS BEEN DUE TO THERE NOT BEING A VALID BACKUP.

> That said, I am now considering making the storage server in the garage a
> backup rather than a RAID.  This means I'll want it to go to sleep most of
> the time, and I'll need a mobo that does wake-on-LAN successfully and
> automatically.

	OK.  It's certainly doable.  You could also just let the drives
sleep, if the motherboard or Ethernet adapter doesn't support WOL.

> Now a backup by cron is nice and all, but what if it silently fails in
> some obscure way?  This is one thing I like about RAID or ZFS, it lets you
> know when anything's wrong.

	Here is the e-mail sent by the daily system backup:

receiving incremental file list
Mail/
Mail/lrhorer
           0   0%    0.00kB/s    0:00:00        88.87M  59%   81.33MB/s
0:00:00       148.87M 100%  100.05MB/s    0:00:01 (xfer#1,
to-check=1391/1469)
Mail_Folders/
Personal_Folders/Leslie/Outlook Files/Outlook Shared File.pst
           0   0%    0.00kB/s    0:00:00        42.68M 100%   74.41MB/s
0:00:00 (xfer#2, to-check=1005/5430)
Recordings/Star Trek The Next Generation/ Recordings/Star Trek The Next
Generation/Star Trek Next Generation - Hero Worship (Recorded Mon Aug 31,
2009, SYFYHD).mpg.txt
           0   0%    0.00kB/s    0:00:00           839 100%  819.34kB/s
0:00:00 (xfer#3, to-check=1090/12581)
Server-Main/Movies/
Server-Main/Movies/Unverified TiVo Movies.csv
           0   0%    0.00kB/s    0:00:00           180 100%  175.78kB/s
0:00:00 (xfer#4, to-check=1029/24920)

Number of files: 31767
Number of files transferred: 4
Total file size: 7043.27G bytes
Total transferred file size: 191.55M bytes Literal data: 682.10K bytes
Matched data: 190.87M bytes File list size: 898.25K File list generation
time: 0.031 seconds File list transfer time: 0.000 seconds Total bytes sent:
133.88K Total bytes received: 1.67M

sent 133.88K bytes  received 1.67M bytes  144.10K bytes/sec total size is
7043.27G  speedup is 3910112.63

	What's obscure about that?  It's also a simple matter to run a
compare between the two systems.  One can compare every single file, or for
brevity one can easily compare only the most recently created files.

> I can imagine setting up a fancy-pants backup
> system then going about my life, and some quirk happens on the next update
> which subtlely hoses my exotic backup system.  It is desirable to have
> bolt-tight assurance of backed-up data.  (And please don't bore us with
> 'nothing is for sure')

	Subtlely?  Such a thing is no more likely (less so, in fact) with
the backup system than with the main system.  And what is with the
characterization "exotic"?  Your backup system should be as plain vanilla as
a system gets.  Load Debian (or whatever) with mail support, load the
packages for NUT, rsync and ssh, configure them, and you're done.  Create
the wakeup / backup script on the main system, and you're on your way.  I
suggest running the rsync on the remote system for best performance, but
it's up to you.  If you don't, you can forego the mail support on the backup
system.  Desktop support is unnecessary, unless you just want to run a
desktop like Gnome or KDE.  Even if you do, its not necessary to have a
mouse, keyboard, or display attached.  Loading ftpd and ntp won't hurt.

> Seems like a sync process, and then a checksum process to compare drives
> and email a result, although minor files are changing all the time and I
> wouldn't want to be notified if /tmp has changed.

	My advice is to run the backup only against the array.  For files
outside the array, I would run a tar job on the external drives and save the
tarball to the array.  You can make them multi-generation backups if you
like.  Either way, the data gets backed up with the array.

> Also I've noticed rsync mentioned several times.  This seems to have
> facilities for incremental backups, but I've also read that it is non-
> secure over networks and that we should use scp instead.

	It's secure if you use ssh with passphraseless keys as its transfer
mechanism.  Why are you worried about it if this is a home LAN, though?  How
is someone gong to sniff your LAN, especially the link between the two
hosts?

> But scp doesn't
> seem to have incremental attributes.  Yes, this is my home LAN, but I have
> a thing about security in and out.

	For video files?  Regardless, exactly how do you suggest that
someone could possibly intercept the data?  Unnecessary security
notwithstanding, however, ssh with passphraseless keys is a great way to
manage the remote system, so I suggest implementing it anyway.

>  Isn't there another way of syncing two disks (over a network)?

	Sure.  Lots of them.  I can't think of any more straightforward than
rsync, though.

RE: Is My Data DESTROYED?!

[adfas asd]

--- On Sun, 10/25/09, Leslie Rhorer <lrhorer@satx.rr.com> wrote:
>     Half the files I have lost on my video
> system were due to my
> personal errors.  Absolutely none were due to drive
> failures.  By a very
> wide margin, the most common cause of data loss is human
> error.  EVERY
> SINGLE FILE THAT HAS EVER BEEN LOST SINCE THE FIRST DIGITAL
> COMPUTER WAS
> BUILT HAS BEEN DUE TO THERE NOT BEING A VALID BACKUP.

Remember:  I, am not you.  I am trying to tell you *my* actual experience.


>     Here is the e-mail sent by the daily
> system backup:
>     What's obscure about that?

Well, it doesn't say for dead-bolt sure that there has been a backup and *full*incontravertible*successful*verify*.  If it does, it's not clear.  And what does it take to set up this emailed report?  And what backup system/script was used?


>  It's also a simple matter to run a
> compare between the two systems.  One can compare
> every single file, or for
> brevity one can easily compare only the most recently
> created files.

Yes yes, but how?


> > I can imagine setting up a fancy-pants backup
> > system then going about my life, and some quirk
> happens on the next update
> > which subtlely hoses my exotic backup system.  It
> is desirable to have
> > bolt-tight assurance of backed-up data.  (And
> please don't bore us with
> > 'nothing is for sure')
> 
>     Subtlely?  Such a thing is no more
> likely (less so, in fact) with
> the backup system than with the main system.  And what
> is with the
> characterization "exotic"?  Your backup system should
> be as plain vanilla as
> a system gets.  Load Debian (or whatever) with mail
> support, load the
> packages for NUT, rsync and ssh, configure them, and you're
> done.

Pfffff....
I don't understand how NUT plays into this.

>  Create
> the wakeup / backup script on the main system, and you're
> on your way.

Wakeup script?  What sort of backup script?  I gather that very few have ever set up a comprehensive remote NAS backup system like this.


> > Also I've noticed rsync mentioned several times. 
> This seems to have
> > facilities for incremental backups, but I've also read
> that it is non-
> > secure over networks and that we should use scp
> instead.
> 
>     It's secure if you use ssh with
> passphraseless keys as its transfer
> mechanism.  Why are you worried about it if this is a
> home LAN, though?  How
> is someone gong to sniff your LAN, especially the link
> between the two
> hosts?

I am told that use of OpenSSH vastly limits the bandwidth of the connection, due to encryption overhead.  Backups could cost more than 24 hours a day, and/or cut into CPU cycles needed for commercial-flagging.  So I'm looking for secure alternatives.

And no I'm not too concerned with someone sniffing my LAN, but if practical security can be had I always use it.  For example I set up reverse SSH tunnels for MythTV, MySQL, and Squid.  No it's not mandatory, and it is difficult, but it is best-practice.


> Unnecessary security
> notwithstanding, however, ssh with passphraseless keys is a
> great way to
> manage the remote system, so I suggest implementing it
> anyway.

Naturally I do, with the built-in security of NX. (nomachine.com)


>     Sure.  Lots of them.  I can't
> think of any more straightforward than
> rsync, though.

Lots?  OK, I am asking for alternatives.





      

Re: Is My Data DESTROYED?!

[Thomas Fjellstrom]

On Sun October 25 2009, you wrote:
> --- On Sun, 10/25/09, Leslie Rhorer <lrhorer@satx.rr.com> wrote:
> >     Half the files I have lost on my video
> > system were due to my
> > personal errors.  Absolutely none were due to drive
> > failures.  By a very
> > wide margin, the most common cause of data loss is human
> > error.  EVERY
> > SINGLE FILE THAT HAS EVER BEEN LOST SINCE THE FIRST DIGITAL
> > COMPUTER WAS
> > BUILT HAS BEEN DUE TO THERE NOT BEING A VALID BACKUP.
> 
> Remember:  I, am not you.  I am trying to tell you *my* actual experience.

Oh believe us, you will learn ;)

> >     Here is the e-mail sent by the daily
> > system backup:
> >     What's obscure about that?
> 
> Well, it doesn't say for dead-bolt sure that there has been a backup and
>  *full*incontravertible*successful*verify*.  If it does, it's not clear. 
>  And what does it take to set up this emailed report?  And what backup
>  system/script was used?
> 
> >  It's also a simple matter to run a
> > compare between the two systems.  One can compare
> > every single file, or for
> > brevity one can easily compare only the most recently
> > created files.
> 
> Yes yes, but how?

diff in binary mode? or maybe difftree, or a tool like it.

> > > I can imagine setting up a fancy-pants backup
> > > system then going about my life, and some quirk
> >
> > happens on the next update
> >
> > > which subtlely hoses my exotic backup system.  It
> >
> > is desirable to have
> >
> > > bolt-tight assurance of backed-up data.  (And
> >
> > please don't bore us with
> >
> > > 'nothing is for sure')
> >
> >     Subtlely?  Such a thing is no more
> > likely (less so, in fact) with
> > the backup system than with the main system.  And what
> > is with the
> > characterization "exotic"?  Your backup system should
> > be as plain vanilla as
> > a system gets.  Load Debian (or whatever) with mail
> > support, load the
> > packages for NUT, rsync and ssh, configure them, and you're
> > done.
> 
> Pfffff....
> I don't understand how NUT plays into this.

Don't tell me you don't have a UPS :o

> >  Create
> > the wakeup / backup script on the main system, and you're
> > on your way.
> 
> Wakeup script?  What sort of backup script?

My cron scripts call a little script I wrote to use wakeonlan to wake up any 
machine that might be asleep before trying to backup.

> I gather that very few have
>  ever set up a comprehensive remote NAS backup system like this.

Its hardly comprehensive, and I'm sure plenty of people have done similar 
things.

Heck, I do weekly full backups to DVDR atm, and will soon add an entire NAS 
backup array. In addition to the daily incremental.

> > > Also I've noticed rsync mentioned several times.
> >
> > This seems to have
> >
> > > facilities for incremental backups, but I've also read
> >
> > that it is non-
> >
> > > secure over networks and that we should use scp
> >
> > instead.
> >
> >     It's secure if you use ssh with
> > passphraseless keys as its transfer
> > mechanism.  Why are you worried about it if this is a
> > home LAN, though?  How
> > is someone gong to sniff your LAN, especially the link
> > between the two
> > hosts?
> 
> I am told that use of OpenSSH vastly limits the bandwidth of the
>  connection, due to encryption overhead.  Backups could cost more than 24
>  hours a day, and/or cut into CPU cycles needed for commercial-flagging. 
>  So I'm looking for secure alternatives.

It's plenty fast.

> And no I'm not too concerned with someone sniffing my LAN, but if practical
>  security can be had I always use it.  For example I set up reverse SSH
>  tunnels for MythTV, MySQL, and Squid.  No it's not mandatory, and it is
>  difficult, but it is best-practice.
> 
> > Unnecessary security
> > notwithstanding, however, ssh with passphraseless keys is a
> > great way to
> > manage the remote system, so I suggest implementing it
> > anyway.
> 
> Naturally I do, with the built-in security of NX. (nomachine.com)
> 
> >     Sure.  Lots of them.  I can't
> > think of any more straightforward than
> > rsync, though.
> 
> Lots?  OK, I am asking for alternatives.
> 

The only one I found I like is rsnapshot. It happens to use rsync under the 
hood. lets me setup hourly, daily, weekly, and monthly incrementals, and every 
week I run a custom script that creates one or more ISOs out of the latest 
daily incremental backup (rsnapshot stores each incremental as a full tree 
using hard links, so it LOOKS like a full backup, but is still just a partial 
backup).

> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Thomas Fjellstrom
tfjellstrom@shaw.ca

Re: Is My Data DESTROYED?!

[Doug Ledford]

[-- Attachment #1: Type: text/plain, Size: 6393 bytes --]

On 10/25/2009 12:06 PM, adfas asd wrote:
> --- On Sun, 10/25/09, Leslie Rhorer <lrhorer@satx.rr.com> wrote:
>>     Half the files I have lost on my video
>> system were due to my
>> personal errors.  Absolutely none were due to drive
>> failures.  By a very
>> wide margin, the most common cause of data loss is human
>> error.  EVERY
>> SINGLE FILE THAT HAS EVER BEEN LOST SINCE THE FIRST DIGITAL
>> COMPUTER WAS
>> BUILT HAS BEEN DUE TO THERE NOT BEING A VALID BACKUP.
> 
> Remember:  I, am not you.  I am trying to tell you *my* actual experience.

Yes, but in your own words you said in the last 12 years you can only
recall 3 or 4 times when you needed to restore from backup.  Well, 3 or
4 times is not 0, hence you need backups.  A raid array doesn't get the
same thing as backup.

> 
>>     Here is the e-mail sent by the daily
>> system backup:
>>     What's obscure about that?
> 
> Well, it doesn't say for dead-bolt sure that there has been a backup and *full*incontravertible*successful*verify*.  If it does, it's not clear.

Neither did your raid solution, nor does ZFS.  Both raid and ZFS write
the same data to multiple blocks on various disks (well, in 1/10 mode
they do anyway), but if something happens later to make those data
blocks disagree, the raid system won't catch that unless you run a check
of the array.  So, just because it *thinks* things are hunky-dory does
not in fact mean they are.  So, you are applying a double standard here
in that you are expecting things out of the backup solution Leslie
listed that you don't have in your preferred solution.

That being said, you can in fact have what you want by simply telling
rsync to use file MD5 sums to determine which files need synced from the
master to the slave instead of file size/date data.  That's right, you
can, by passing a simple flag to rsync, cause it to read each and every
single file, generate an md5sum of the file, and use that to determine
if the file needs backed up or if the file already on the backup machine
is identical.  In other words, this mode of operation is *superior* to
the raid solution your comparing it against.

But, this all raises a very simple point that I'm surprised someone else
hasn't brought up yet.  If you had merely looked at the rsync man page,
or even just the rsync help information on the command line, you would
have seen this for yourself.  So, might I suggest that before you spend
to much time trying to shoot down what is probably a very workable
solution for you, that you actually *LOOK INTO* that solution instead of
letting prejudice and ignorance drive your decision.

> And what does it take to set up this emailed report?

Run rsync in a cron job and *don't* redirect rsync's output to /dev/null
and you will automatically get these emails (assuming that you already
redirect emails to root to your own personal email account).

> And what backup system/script was used?

Rsync is it's own backup system when used as such, nothing else is
needed.  You essentially create a cron job to run rsync, and your entire
script consists of simply getting the rsync command fine tuned to your
particular application.  Here's an example of an rsync cron job I use to
mirror Fedora repos to my local server:

[root@firewall ~]# more /etc/cron.daily/sync_fedora
#!/bin/bash
#
# Only used on rawhide

cd /srv/Fedora/rawhide
[ -f .syncing ] && exit 0 || touch .syncing
for arch in x86_64 i386 ppc; do
	rsync -acq --delete
rsync://fedora.secsup.org/fedora/linux/development/$arch/os/ $arch
	if [ $arch = "x86_64" ]; then
		ln $arch/Packages/*.noarch.rpm i386/Packages >/dev/null 2>&1
		ln $arch/Packages/*.noarch.rpm ppc/Packages >/dev/null 2>&1
		ln $arch/Packages/*.i[356]86.rpm i386/Packages >/dev/null 2>&1
	fi
done
rm .syncing

[root@firewall ~]#

Note that because I use the -q flag to rsync, I don't get nightly emails
unless something goes wrong.

> 
>>  It's also a simple matter to run a
>> compare between the two systems.  One can compare
>> every single file, or for
>> brevity one can easily compare only the most recently
>> created files.
> 
> Yes yes, but how?

RTFM please.

>>> Also I've noticed rsync mentioned several times. 
>> This seems to have
>>> facilities for incremental backups, but I've also read
>> that it is non-
>>> secure over networks and that we should use scp
>> instead.
>>
>>     It's secure if you use ssh with
>> passphraseless keys as its transfer
>> mechanism.  Why are you worried about it if this is a
>> home LAN, though?  How
>> is someone gong to sniff your LAN, especially the link
>> between the two
>> hosts?
> 
> I am told that use of OpenSSH vastly limits the bandwidth of the connection, due to encryption overhead.  Backups could cost more than 24 hours a day, and/or cut into CPU cycles needed for commercial-flagging.  So I'm looking for secure alternatives.
> 
> And no I'm not too concerned with someone sniffing my LAN, but if practical security can be had I always use it.  For example I set up reverse SSH tunnels for MythTV, MySQL, and Squid.  No it's not mandatory, and it is difficult, but it is best-practice.

Might I suggest a little less "so I'm told" and a little more "so I
tried this out and this is what I got...".  In this particular case, if
you are worried about the poor authentication of rsync without ssh, but
concerned with the overhead of encrypting all the data transferred, then
why not just set up ssh so that it does encryptionless data transfer
between these two machines?  Then you get the benefit of the improved
authentication strength of ssh, but not the overhead of the encryption
on the link.  But, in truth, as long as you aren't running an atom CPU
or something like that, you should have more than enough CPU horsepower
to encrypt a gigabit link's worth of data transfer.  And especially if
you choose to use the md5sum comparisons in rsync, your machines will be
far busier just reading the data from disk and doing md5sums of the
entire array, so worrying about the CPU overhead of the encryption is
kinda silly.

-- 
Doug Ledford <dledford@redhat.com>
              GPG KeyID: CFBFF194
	      http://people.redhat.com/dledford

Infiniband specific RPMs available at
	      http://people.redhat.com/dledford/Infiniband


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Is My Data DESTROYED?!

[adfas asd]

Thanks Doug, this was very helpful.  I had seen the checksum option, but sometimes something doesn't register as useful unless there is independent confirmation. 

And understand that I am not 'shooting down' anything to be obstinate;  I am testing and probing for the -best- solution and systems, and hoping something good pops out.  Some of the sensitive will take offense, but I suggest that all benefit when we get substantive responses such as yours.

I had tried afio and cpio in the past, but frankly could not figure it out to use.  Seems like a good concept.  Maybe it's been made more accessible by now, or maybe I'm not as dumb.  BTW, I am a real estate developer, not a coder.


--- On Sun, 10/25/09, Doug Ledford <dledford@redhat.com> wrote:
> That being said, you can in fact have what you want by
> simply telling
> rsync to use file MD5 sums to determine which files need
> synced from the
> master to the slave instead of file size/date data. 
> That's right, you
> can, by passing a simple flag to rsync, cause it to read
> each and every
> single file, generate an md5sum of the file, and use that
> to determine
> if the file needs backed up or if the file already on the
> backup machine
> is identical.  In other words, this mode of operation
> is *superior* to
> the raid solution your comparing it against.
> 
> But, this all raises a very simple point that I'm surprised
> someone else
> hasn't brought up yet.  If you had merely looked at
> the rsync man page,
> or even just the rsync help information on the command
> line, you would
> have seen this for yourself.  So, might I suggest that
> before you spend
> to much time trying to shoot down what is probably a very
> workable
> solution for you, that you actually *LOOK INTO* that
> solution instead of
> letting prejudice and ignorance drive your decision.
> 
> > And what does it take to set up this emailed report?
> 
> Run rsync in a cron job and *don't* redirect rsync's output
> to /dev/null
> and you will automatically get these emails (assuming that
> you already
> redirect emails to root to your own personal email
> account).
> 
> > And what backup system/script was used?
> 
> Rsync is it's own backup system when used as such, nothing
> else is
> needed.  You essentially create a cron job to run
> rsync, and your entire
> script consists of simply getting the rsync command fine
> tuned to your
> particular application.  Here's an example of an rsync
> cron job I use to
> mirror Fedora repos to my local server:
> 
> [root@firewall ~]# more /etc/cron.daily/sync_fedora
> #!/bin/bash
> #
> # Only used on rawhide
> 
> cd /srv/Fedora/rawhide
> [ -f .syncing ] && exit 0 || touch .syncing
> for arch in x86_64 i386 ppc; do
>     rsync -acq --delete
> rsync://fedora.secsup.org/fedora/linux/development/$arch/os/
> $arch
>     if [ $arch = "x86_64" ]; then
>         ln
> $arch/Packages/*.noarch.rpm i386/Packages >/dev/null
> 2>&1
>         ln
> $arch/Packages/*.noarch.rpm ppc/Packages >/dev/null
> 2>&1
>         ln
> $arch/Packages/*.i[356]86.rpm i386/Packages >/dev/null
> 2>&1
>     fi
> done
> rm .syncing
> 
> [root@firewall ~]#
> 
> Note that because I use the -q flag to rsync, I don't get
> nightly emails
> unless something goes wrong.
> 
> > 
> >>  It's also a simple matter to run a
> >> compare between the two systems.  One can
> compare
> >> every single file, or for
> >> brevity one can easily compare only the most
> recently
> >> created files.
> > 
> > Yes yes, but how?
> 
> RTFM please.
> 
> >>> Also I've noticed rsync mentioned several
> times. 
> >> This seems to have
> >>> facilities for incremental backups, but I've
> also read
> >> that it is non-
> >>> secure over networks and that we should use
> scp
> >> instead.
> >>
> >>     It's secure if you use ssh
> with
> >> passphraseless keys as its transfer
> >> mechanism.  Why are you worried about it if
> this is a
> >> home LAN, though?  How
> >> is someone gong to sniff your LAN, especially the
> link
> >> between the two
> >> hosts?
> > 
> > I am told that use of OpenSSH vastly limits the
> bandwidth of the connection, due to encryption
> overhead.  Backups could cost more than 24 hours a day,
> and/or cut into CPU cycles needed for
> commercial-flagging.  So I'm looking for secure
> alternatives.
> > 
> > And no I'm not too concerned with someone sniffing my
> LAN, but if practical security can be had I always use
> it.  For example I set up reverse SSH tunnels for
> MythTV, MySQL, and Squid.  No it's not mandatory, and
> it is difficult, but it is best-practice.
> 
> Might I suggest a little less "so I'm told" and a little
> more "so I
> tried this out and this is what I got...".  In this
> particular case, if
> you are worried about the poor authentication of rsync
> without ssh, but
> concerned with the overhead of encrypting all the data
> transferred, then
> why not just set up ssh so that it does encryptionless data
> transfer
> between these two machines?  Then you get the benefit
> of the improved
> authentication strength of ssh, but not the overhead of the
> encryption
> on the link.  But, in truth, as long as you aren't
> running an atom CPU
> or something like that, you should have more than enough
> CPU horsepower
> to encrypt a gigabit link's worth of data transfer. 
> And especially if
> you choose to use the md5sum comparisons in rsync, your
> machines will be
> far busier just reading the data from disk and doing
> md5sums of the
> entire array, so worrying about the CPU overhead of the
> encryption is
> kinda silly.
> 
> -- 
> Doug Ledford <dledford@redhat.com>
>               GPG KeyID:
> CFBFF194
>           http://people.redhat.com/dledford
> 
> Infiniband specific RPMs available at
>           http://people.redhat.com/dledford/Infiniband
> 
> 


      

Re: Is My Data DESTROYED?!

[Thomas Fjellstrom]

On Sun October 25 2009, adfas asd wrote:
> --- On Sat, 10/24/09, Christopher Chen <muffaleta@gmail.com> wrote:
> > Part of this sounds like you're looking for best practices.
> > I imagine
> > that's why you made a raid 10, and why you're using JFS.
> > It's probably
> > why you've been fiddling around with blockdev --setra and
> > all that
> > too
> 
> Exactly.
> 
> > The issue is, you're shooting in the dark unless you really
> > understand
> > what you want to do and why. You also said HTPC. Is this
> > basically a
> > large bucket for videos and other media?
> 
> Yes it's my video collection which I've worked long and hard to gather. 
>  Your point is taken that it doesn't have to be hot online, but if it can
>  why not?  I hate tape, and claim that it's obsolete.
> 
> I am shocked at all who think that human error is so prevalent, and in fact
>  obviates the case for RAID as backup.  I've run Debian for 12 years on all
>  my personal servers and remember literally only 3 or 4 cases in that time
>  where I muggered something up and had to go to backup.  There must be alot
>  of fsckups out there...
> 
> That said, I am now considering making the storage server in the garage a
>  backup rather than a RAID.  This means I'll want it to go to sleep most of
>  the time, and I'll need a mobo that does wake-on-LAN successfully and
>  automatically.
> 
> Now a backup by cron is nice and all, but what if it silently fails in some
>  obscure way?  This is one thing I like about RAID or ZFS, it lets you know
>  when anything's wrong.  I can imagine setting up a fancy-pants backup
>  system then going about my life, and some quirk happens on the next update
>  which subtlely hoses my exotic backup system.  It is desirable to have
>  bolt-tight assurance of backed-up data.  (And please don't bore us with
>  'nothing is for sure')

All I can say is I've been using RAID5 for a while now, and it surely isn't 
any kind of backup solution. When I first started using it I figured it would 
be "good enough" and it really REALLY isn't. A couple of times the array got 
corrupted beyond repair, and another couple times PEBKAC errors hit the array 
causing a total loss (each time loosing some important data, and 500G-1.5T of 
video)

Soon I intend to start up a "backup array" on a separate machine using raid6 
or raid0+1, or even just LVM (I'm not sure I like how raid10 isn't re-
sizable). Then I'll have my other arrays backed up to the backup array. And 
then I'll backup the important (non video stuff) to DVDR and a remote webhost 
(I really wish my upload was faster, currently uploading one of my backups 
will take on the order of a day or so to upload).

Long story short, RAID != Backup. It provides redundancy in case one (or more) 
disks fail, it does not protect from PEBKAC errors (like assembling the array 
wrong, or rm -fr /array), nor random bit flips caused by supposed cosmic rays, 
and other factors (failing ram?). RAID5 will happily save whatever is in ram 
at any given point and then XOR that, even if its wrong.

> Seems like a sync process, and then a checksum process to compare drives
>  and email a result, although minor files are changing all the time and I
>  wouldn't want to be notified if /tmp has changed.
> 
> Also I've noticed rsync mentioned several times.  This seems to have
>  facilities for incremental backups, but I've also read that it is
>  non-secure over networks and that we should use scp instead.  But scp
>  doesn't seem to have incremental attributes.  Yes, this is my home LAN,
>  but I have a thing about security in and out.  Isn't there another way of
>  syncing two disks (over a network)?
> 

rsync supports the use of ssh, so it should be fine. I use rsync+ssh to backup 
all of the important documents and settings off of all of my machines. runs a 
couple times a day using rsnapshot.

> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Thomas Fjellstrom
tfjellstrom@shaw.ca

RE: Is My Data DESTROYED?!

[Leslie Rhorer]

> Warning: I can only be polite and diplomatic to a limited number of
> technically incompetent people each day. Today isn't your day.

	Well...

> That's like saying a bicycle is not as good as a frying pan. They are
> totally different things, used for different reasons. A raid array is a
> technique used to improve the performance or reliability of a single
> dynamic copy of data. A backup is an independent copy of the data at
> some point in time, and will continue to exist if the original is
> damaged or destroyed.
> 
> Note: a good backup will be off-site to prevent physical destruction.

	When possible, I like a multi-tiered approach.  The most common
cause of data loss is human error.  By the same token, however, it is also
completely harmless to the hardware. Well, usually.  I did once have an
idiot raise the floor tile underneath one of my servers and then drop it.
That was back in the days when a 300M (that's MEGABYTE, not GIGABYTE) drive
cost $1000.  It was my personal system, too...

	I digress.

	The point is, keeping a live backup system on-site for all data
allows dumb-ass losses to be recovered extremely quickly.  For more critical
data, the backup needs to be kept off-site.  This can be done with a
"sneakernet" solution for best economy, or using a WAN connection.  Either
way, recovering the data is going to be a bit slower, although a WAN
connected system can recover a handful of modestly sized files quite
quickly.  Hyper-critical data can go to vault storage, with no access except
by a very small handful of authorized individuals.

> One of the few things I liked about running servers for at&t was that
> they actually had a "smoking hole recovery plan" requiring steps to
> recover if the data center was physically destroyed. The only other
> organization I have worked with who had that level of concern was a bank
> in Ireland during "the troubles." My general data will survive loss of
> my office and a two mile radius around it, my critical data will survive
> lose off the continental US. Okay, I may take this too seriously. ;-)

	Maybe, maybe not.  In either case, however, if the continental U.S.
is lost, we have bigger problems.  :-)

> > - Of course I wish that backing up could save many terabytes of data for
> less than $10,000.  But that is not practical today.
> >
> >
> Hogwash! You can get an eSATA array tower with four bays from Newegg for
> <$200, 1TB drives for $85/ea on sale (mine are WD 'green' which run
> about 10C cooler than Seagate or Hitachi), and have 3TB RAID-5 for
> ~$600, capable of being daisy chained. Choice of built-in or software
> raid. 2TB drives will add about $400, and with an independent copy of
> the filesystem on a box you have backup. For another $400 you can have a
> cheap 2nd system connected by Gbit network and be totally independent.

	What's really silly is he already HAS this.  He is implementing
RAID10 over two separate systems connected by a 1G Ethernet link.  The
remote system is in his garage.  I keep telling him, "Forget the RAID10
solution, and go with an independent system with backups managed via rsync."
Then he complains about poor RAID10 performance and has a cow when he
encounters a file system corruption (or what he thought was file system
corruption).

> > Fact:  I have terabytes of data that I want to keep from losing.
> > Fact:  Disk drives have never been cheaper.
> > Fact:  It is most cost-effective to save terabytes of data on disk
> drives, if the proper regimen can be determined for safety.
> >
> 
> That means backup, sorry, stuff happens if you only have one copy.

	Exactly.  He seems to have a logic-tight compartment wherein "hard
drive" != "backup".  The most economical backup solutions by far right now
are hard drive based.

> > Fact:  After one month's use mdadm RAID has resulted in a failure which
> > could have been catastrophic had I not determined that somehow JFS
> > functionality was destroyed.

	OP: you have provided no evidence mdadm caused this.

> > Fact:  Now one of my  arrays has gone into degraded mode for mysterious
> > reasons, and we are so busy arguing about backups that no one can advise
> > on what to do about this.

	OP: The root cause is likely to be the same as that which degraded
the array.  If you insist on recovering the array directly, we are going to
need more diagnostics.  At a high level, if the suspect drive is bad, then
it needs to be replaced and the array re-synced.  Another choice would be to
divide up the array into two separate RAID0 arrays and fix the one with a
bad drive.  This is an example of exactly what I meant when I told you this
topology is going to be more difficult to manage than a pair of independent
RAID0 or RAID5 arrays.

> I advise you to go to backup. If you can afford to have "terabytes of
> data" you either live with losing it and just wonder when, or you go to
> real backup.

	Or just convert his RAID10 array into two independent arrays and use
one as a backup.

Re: Is My Data DESTROYED?!

[berk walker]

Mattias Wadenstein wrote:
> On Fri, 23 Oct 2009, Christian Pernegger wrote:
> 
>>> I believe you are confusing raid with backup.
>>
>> For lots of people the primary role of RAID is as a protection against
>> data-loss nowadays. Backups just aren't feasible/cost-effective
>> anymore for the amounts of data involved. Sticking your head in the
>> sand and repeating that mantra doesn't change that and it isn't
>> helping.
> 
> Well, claiming that RAID will protect your data under all circumstances 
> isn't helping either. Backups will actually protect against such things 
> as rm -rf:ing the wrong directory or mkfs:ing the wrong device, etc. 
> Things that RAID will never protect against.
> 
> And I don't see how backups aren't feasable, USB/network harddrives keep 
> pace with in-box harddrive sizes just fine. Offsite backup might be 
> trickier/costlier, so you might constrain those to just the data that 
> you would be really sad to see gone if the house burns down (photo 
> album, own creations, etc).
> 
> /Mattias Wadenstein
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
Sir - Whereas Neil, et al, profess that RAID is NOT equal to BACKUP - 
Most of us know that tape backup is VERY costly, in several ways, in our 
multi-terrabyte situations. Your mention of USB/network solutions does 
beg the obvious question-- How would one do USB/network solutions 
without some degree of encoded backup, and trust?  BTW, worse yet is 
implied trust in Cloud, eh?

And then, you say:

RE: Is My Data DESTROYED?!

[Leslie Rhorer]

> Sir - Whereas Neil, et al, profess that RAID is NOT equal to BACKUP -
> Most of us know that tape backup is VERY costly, in several ways, in our

	No one used the word "tape".  Tapes have not been a practical means
of backups for many systems for quite some years.  Today, for most large
systems, the most practical backup solution is hard drive based.  Since the
OP already has a RAID10 system he has enough or nearly enough drives for a
hard drive based backup.  Since he is already talking about a remote NAS
system, his additional costs can be as low as $0, or at most the cost two or
three additional drives.

Re: Is My Data DESTROYED?!

[Christopher Chen]

On Sat, Oct 24, 2009 at 6:36 PM, Leslie Rhorer <lrhorer@satx.rr.com> wrote:
>> Sir - Whereas Neil, et al, profess that RAID is NOT equal to BACKUP -
>> Most of us know that tape backup is VERY costly, in several ways, in our
>
>        No one used the word "tape".  Tapes have not been a practical means
> of backups for many systems for quite some years.  Today, for most large
> systems, the most practical backup solution is hard drive based.  Since the
> OP already has a RAID10 system he has enough or nearly enough drives for a
> hard drive based backup.  Since he is already talking about a remote NAS
> system, his additional costs can be as low as $0, or at most the cost two or
> three additional drives.

I think that may be a point of contention. Places where I've worked,
primary data stores, on the order of hundreds of terabytes have been
backed up to tape, and were part of an offsite rotation. Does that
mean everyone can? Maybe not. But if people can afford to purchase
multi-million dollar SAN and NAS systems, they can certainly afford a
tape library and some LTO tapes. Is it expensive? Certainly. But often
disk-based backups can provide a false sense of economy--disks use
power, take up rack space, generate heat--these are all things people
should consider when building out a data center.

But, of course, he's not building out a data center, and he's probably
not going to buy LTO4 drives either.

Did we use disk-based backups? Certainly, and often as a part of a
snapshot system where you could go "yesterday" and pick up data. But
they were shipped to tape too.

But, like I said, data is only important if it's important, and for
some organizations, it's VERY important :)

cc

-- 
Chris Chen <muffaleta@gmail.com>
"The fact that yours is better than anyone else's
is not a guarantee that it's any good."
-- Seen on a wall
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Is My Data DESTROYED?!

[Leslie Rhorer]

> -----Original Message-----
> From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
> owner@vger.kernel.org] On Behalf Of Christopher Chen
> Sent: Saturday, October 24, 2009 8:51 PM
> To: Leslie Rhorer
> Cc: berk walker; Mattias Wadenstein; Christian Pernegger; linux-
> raid@vger.kernel.org; adfas asd
> Subject: Re: Is My Data DESTROYED?!
> 
> On Sat, Oct 24, 2009 at 6:36 PM, Leslie Rhorer <lrhorer@satx.rr.com>
> wrote:
> >> Sir - Whereas Neil, et al, profess that RAID is NOT equal to BACKUP -
> >> Most of us know that tape backup is VERY costly, in several ways, in
> our
> >
> >        No one used the word "tape".  Tapes have not been a practical
> means
> > of backups for many systems for quite some years.  Today, for most large
> > systems, the most practical backup solution is hard drive based.  Since
> the
> > OP already has a RAID10 system he has enough or nearly enough drives for
> a
> > hard drive based backup.  Since he is already talking about a remote NAS
> > system, his additional costs can be as low as $0, or at most the cost
> two or
> > three additional drives.
> 
> I think that may be a point of contention. Places where I've worked,
> primary data stores, on the order of hundreds of terabytes have been
> backed up to tape, and were part of an offsite rotation. Does that

	True.  In the case of many, many terrabytes of data, and if
accessibility is not an issue, tapes can be the backup of choice.  That's
why I said, "for many systems".  If the cost of the drive subsystems is in
excess of $100K, then spending $40K for a tape drive makes sense, rather
than spending another $100K - $20M for a drive based solution.  If the total
backup is less than 50T in size, or if availability is a concern, then tapes
are not a good solution.  Right now, at least, tapes cost a bit less than
inexpensive disks, but the drive is quite costly.  It is only once the cost
of the tapoe drive is swamped by the cost of the main drive systems that the
tape is more attractive economically.

> mean everyone can? Maybe not. But if people can afford to purchase
> multi-million dollar SAN and NAS systems, they can certainly afford a
> tape library and some LTO tapes.

	Yeah, but this is a guy with a 4T MythTV server at his house.  If he
were General Motors searching for a backup solution, I would advise him
differently.  If he were a storage solutions company, I would advise him
differently again.  The solution needs to fit the application.

> Is it expensive? Certainly. But often
> disk-based backups can provide a false sense of economy--disks use
> power, take up rack space, generate heat--these are all things people
> should consider when building out a data center.

	This isn't for a data center.  For giant systems, these are all a
consideration.  For systems less than 100T in size, they really aren't.
What's more, cold drives don't use any more power than a tape.  For medium
to large sized off-site backups, removable hard drives are a very attractive
solution.  At about $60 a terrabyte and less than $500 for the enclosure,
it's hard to beat.

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Is My Data DESTROYED?!

[adfas asd]

Today I went in to my HTPC, to find it was hung and the drive light was stuck on.  After all attempts to revive it or switch to terminal 2 or 3 had failed I reset the system.  

It rebooted to tell me that it cannot mount /home, the RAID10offset2 device. 

When I reboot in recovery mode and try to mount /dev/md0 manually it informs me there is an invalid superblock!  I shut down and unplugged each drive in turn, and /proc/mdstat shows the appropriate volume gone, but still can't mount the array.

What has happened here?  Is all my data destroyed?