Re: [gpfsug-discuss] Snapshots for backups

[Skylar Thompson]

On Wed, May 09, 2018 at 04:33:26PM -0400, valdis.kletni...@vt.edu wrote:
> On Wed, 09 May 2018 15:01:55 -0400, "Marc A Kaplan" said:
> 
> > I see there are also low-power / zero-power disk archive/arrays available.
> >  Any experience with those?
> 
> The last time I looked at those (which was a few years ago) they were 
> competitive
> with tape for power consumption, but not on cost per terabyte - it takes a 
> lot less
> cable and hardware to hook up a dozen tape drives and a robot arm that can
> reach 10,000 volumes than it does to wire up 10,000 disks of which only 500 
> are
> actually spinning at any given time...


I also wonder what the lifespan of cold-storage hard drives are relative to
tape. With BaFe universal for LTO now, our failure rate for tapes has gone
way down (not that it was very high relative to HDDs anyways).

FWIW, the operating+capital costs we recharge our grants for tape storage
is ~50% of what we recharge them for bulk disk storage.

-- 
-- Skylar Thompson (skyl...@u.washington.edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine
___
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss

Re: [gpfsug-discuss] Snapshots for backups

[valdis . kletnieks]

On Wed, 09 May 2018 15:01:55 -0400, "Marc A Kaplan" said:

> I see there are also low-power / zero-power disk archive/arrays available.
>  Any experience with those?

The last time I looked at those (which was a few years ago) they were 
competitive
with tape for power consumption, but not on cost per terabyte - it takes a lot 
less
cable and hardware to hook up a dozen tape drives and a robot arm that can
reach 10,000 volumes than it does to wire up 10,000 disks of which only 500 are
actually spinning at any given time...


pgpP6MPq9UfOf.pgp
Description: PGP signature
___
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss

Re: [gpfsug-discuss] Snapshots for backups

[Kristy Kallback-Rose]

+1 for benefits of tape and also power consumption/heat production (may help a 
case to management) is obviously better with things that don’t have to be 
spinning all the time. 

> 
> At scale tape is a lot cheaper than disk. Also sorry your data is going
> to take a couple of weeks to recover goes down a lot better than sorry
> your data is gone for ever.
> 
> Finally it's also hard for a hacker or disgruntled admin to wipe your
> tapes in a short period of time. The robot don't go that fast. Your
> disks/file systems on the other hand effectively be gone in seconds.
> 
> JAB.
> 
> -- 
> Jonathan A. Buzzard Tel: +44141-5483420
> HPC System Administrator, ARCHIE-WeSt.
> University of Strathclyde, John Anderson Building, Glasgow. G4 0NG
> 
> 
> ___
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss

___
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss

Re: [gpfsug-discuss] Snapshots for backups

[Keigo Matsubara]

Not sure if the topic is appropriate, but I know an installation case 
which employs IBM Spectrum Scale's snapshot function along with IBM 
Spectrum Protect to save the backup date onto LTO7 tape media. Both 
software components running on Linux on Power (RHEL 7.3 BE) if that 
matters. Of course, snapshots are taken per independent fileset.
---
Keigo Matsubara, Storage Solutions Client Technical Specialist, IBM Japan
TEL: +81-50-3150-0595, T/L: 6205-0595


___
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss

Re: [gpfsug-discuss] Snapshots for backups

[Fosburgh,Jonathan]

I agree with your points.

The thought here, is that if we had a complete loss of the primary site, we 
could bring up the secondary in relatively short order (hours or days instead 
of weeks or months).  Maybe this is true, and maybe this isn’t, though I do see 
(and have advocated for) a DR setup much like that.  My concern is that the use 
of snapshots as a substitute for traditional backups for a Scale environment is 
that that is an inappropriate use of the technology, particularly when we have 
a tool designed for that and that works.

Let me take a moment to reiterate something that may be getting lost.  The 
snapshots will be taken against the remote copy and recovered from there.  We 
will not be relying on the primary site for this function.

We were starting to look at ESS as a destination for these backups.  I have 
also considered that a multisite ICOS implementation might work to satisfy some 
of our general backup requirements.

From:  on behalf of Andrew Beattie 

Reply-To: gpfsug main discussion list 
Date: Wednesday, May 9, 2018 at 7:51 AM
To: "gpfsug-discuss@spectrumscale.org" 
Cc: "gpfsug-discuss@spectrumscale.org" 
Subject: Re: [gpfsug-discuss] Snapshots for backups


From my perspective the difference / benefits of using something like Protect 
and using backup policies over snapshot policies - even if its disk based 
rather than tape based,  is that with a backup you get far better control over 
your Disaster Recovery process. The policy integration with Scale and Protect 
is very comprehensive.  If the issue is Tape time for recovery - simply change 
from tape medium to a Disk storage pool as your repository for Protect, you get 
all the benefits of Spectrum Protect and the restore speeds of disk, (you might 
even - subject to type of data start to see some benefits of duplication and 
compression for your backups as you will be able to take advantage of Protect's 
dedupe and compression for the disk based storage pool, something that's not 
available on your tape environment.

If your looking for a way to further reduce your disk costs then potentially 
the benefits of Object Storage erasure coding might be worth looking at 
although for a 1 or 2 site scenario the overheads are pretty much the same if 
you use some variant of distributed raid or if you use erasure coding.






Andrew Beattie
Software Defined Storage  - IT Specialist
Phone: 614-2133-7927
E-mail: abeat...@au1.ibm.com


- Original message -
From: "Fosburgh,Jonathan" 
Sent by: gpfsug-discuss-boun...@spectrumscale.org
To: gpfsug main discussion list 
Cc:
Subject: Re: [gpfsug-discuss] Snapshots for backups
Date: Wed, May 9, 2018 10:28 PM



Our existing environments are using Scale+Protect with tape.  Management wants 
us to move away from tape where possible.

We do one filesystem per cluster.  So, there will be two new clusters.

We are still finalizing the sizing, but the expectation is both of them will be 
somewhere in the3-5PB range.



We understand that if we replicate corrupted data, the corruption will go with 
it.  But the same would be true for a backup (unless I am not quite following 
you).



The thought is that not using Protect and simply doing replication with 
snapshots will enable faster recovery from a catastrophic failure of the 
production environment, whereas with Protect we would have to restore petabytes 
of data.



FWIW, this is the same method we are using in our NAS (Isilon), but those 
utilities are designed for that type of use, and there is no equivalent to 
mmbackup.  Our largest Scale environment is 7+PB, and we can complete a backup 
of it in one night with mmbackup.  We abandoned tape backups on our NAS at 
around 600TB.



From:  on behalf of Andrew Beattie 

Reply-To: gpfsug main discussion list 
Date: Tuesday, May 8, 2018 at 4:38 PM
To: "gpfsug-discuss@spectrumscale.org" 
Cc: "gpfsug-discuss@spectrumscale.org" 
Subject: Re: [gpfsug-discuss] Snapshots for backups



Hi Jonathan,



First off a couple of questions:



1) your using Scale+Protect with Tape today?

2) your new filesystems will be within the same cluster ?

3) What capacity are the new filesystems



Based on the above then:



AFM-DR will give you the Replication that you are talking about -- please talk 
to your local IBM people about the limitations of AFM-DR to ensure it will work 
for your use case

Scale supports snapshots - but as mentioned snapshots are not a backup of your 
filesystem - if you snapshot corrupt data you will replicate that to the DR 
location



If you are going to spin up 

Re: [gpfsug-discuss] Snapshots for backups

[Jonathan Buzzard]

On Wed, 2018-05-09 at 12:50 +, Andrew Beattie wrote:
>  
> From my perspective the difference / benefits of using something like
> Protect and using backup policies over snapshot policies - even if
> its disk based rather than tape based,  is that with a backup you get
> far better control over your Disaster Recovery process. The policy
> integration with Scale and Protect is very comprehensive.  If the
> issue is Tape time for recovery - simply change from tape medium to a
> Disk storage pool as your repository for Protect, you get all the
> benefits of Spectrum Protect and the restore speeds of disk, (you
> might even - subject to type of data start to see some benefits of
> duplication and compression for your backups as you will be able to
> take advantage of Protect's dedupe and compression for the disk based
> storage pool, something that's not available on your tape
> environment.

The way I see it is that snapshots are not backup. They are handy for
quick recovery from file deletion mistakes. They are utterly useless
when your disaster recovery is needed because for example all your NSD
descriptors have been overwritten (not my mistake I hasten to add). AT
that point your snapshots are for jack.

>  
> If your looking for a way to further reduce your disk costs then
> potentially the benefits of Object Storage erasure coding might be
> worth looking at although for a 1 or 2 site scenario the overheads
> are pretty much the same if you use some variant of distributed raid
> or if you use erasure coding.
>  

At scale tape is a lot cheaper than disk. Also sorry your data is going
to take a couple of weeks to recover goes down a lot better than sorry
your data is gone for ever.

Finally it's also hard for a hacker or disgruntled admin to wipe your
tapes in a short period of time. The robot don't go that fast. Your
disks/file systems on the other hand effectively be gone in seconds.

JAB.

-- 
Jonathan A. Buzzard Tel: +44141-5483420
HPC System Administrator, ARCHIE-WeSt.
University of Strathclyde, John Anderson Building, Glasgow. G4 0NG


___
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss

Re: [gpfsug-discuss] Snapshots for backups

[Andrew Beattie]

 
From my perspective the difference / benefits of using something like Protect and using backup policies over snapshot policies - even if its disk based rather than tape based,  is that with a backup you get far better control over your Disaster Recovery process. The policy integration with Scale and Protect is very comprehensive.  If the issue is Tape time for recovery - simply change from tape medium to a Disk storage pool as your repository for Protect, you get all the benefits of Spectrum Protect and the restore speeds of disk, (you might even - subject to type of data start to see some benefits of duplication and compression for your backups as you will be able to take advantage of Protect's dedupe and compression for the disk based storage pool, something that's not available on your tape environment.
 
If your looking for a way to further reduce your disk costs then potentially the benefits of Object Storage erasure coding might be worth looking at although for a 1 or 2 site scenario the overheads are pretty much the same if you use some variant of distributed raid or if you use erasure coding.
 
 
 
 
 
 
Andrew Beattie
Software Defined Storage  - IT Specialist
Phone: 614-2133-7927
E-mail: abeat...@au1.ibm.com
 
 
- Original message -From: "Fosburgh,Jonathan" Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main discussion list Cc:Subject: Re: [gpfsug-discuss] Snapshots for backupsDate: Wed, May 9, 2018 10:28 PM 
Our existing environments are using Scale+Protect with tape.  Management wants us to move away from tape where possible.
We do one filesystem per cluster.  So, there will be two new clusters.
We are still finalizing the sizing, but the expectation is both of them will be somewhere in the3-5PB range.
 
We understand that if we replicate corrupted data, the corruption will go with it.  But the same would be true for a backup (unless I am not quite following you).
 
The thought is that not using Protect and simply doing replication with snapshots will enable faster recovery from a catastrophic failure of the production environment, whereas with Protect we would have to restore petabytes of data.
 
FWIW, this is the same method we are using in our NAS (Isilon), but those utilities are designed for that type of use, and there is no equivalent to mmbackup.  Our largest Scale environment is 7+PB, and we can complete a backup of it in one night with mmbackup.  We abandoned tape backups on our NAS at around 600TB.
 
From:  on behalf of Andrew Beattie Reply-To: gpfsug main discussion list Date: Tuesday, May 8, 2018 at 4:38 PMTo: "gpfsug-discuss@spectrumscale.org" Cc: "gpfsug-discuss@spectrumscale.org" Subject: Re: [gpfsug-discuss] Snapshots for backups
 
Hi Jonathan,
 
First off a couple of questions:
 
1) your using Scale+Protect with Tape today?
2) your new filesystems will be within the same cluster ?
3) What capacity are the new filesystems
 
Based on the above then:
 
AFM-DR will give you the Replication that you are talking about -- please talk to your local IBM people about the limitations of AFM-DR to ensure it will work for your use case
Scale supports snapshots - but as mentioned snapshots are not a backup of your filesystem - if you snapshot corrupt data you will replicate that to the DR location
 
If you are going to spin up new infrastructure in a DR location have you considered looking at an object store and using your existing Protect environment to allow you to Protect environment to HSM out to a Disk basked object storage pool distributed over disparate geographic locations? (obviously capacity dependent)
 
Andrew Beattie
Software Defined Storage  - IT Specialist
Phone: 614-2133-7927
E-mail: abeat...@au1.ibm.com
 
 
- Original message -From: "Fosburgh,Jonathan" Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main discussion list Cc:Subject: [gpfsug-discuss] Snapshots for backupsDate: Tue, May 8, 2018 11:43 PM 
We are looking at standing up some new filesystems and management would like us to investigate alternative options to Scale+Protect.  In particular, they are interested in the following:
 
Replicate to a remote filesystem (I assume this is best done via AFM).
Take periodic (probably daily) snapshots at the remote site.
 
The thought here is that this gives us the ability to restore data more quickly than we could with tape and also gives us a DR system in the event of a failure at the primary site.  Does anyone have experience with this kind of setup?  I know this is a solution that will require a fair amount of scripting and some cron jobs, both of which will introduce a level of human error.  Are there any other gotchas we should be aware of?
The 

Re: [gpfsug-discuss] Snapshots for backups

[Fosburgh,Jonathan]

Our existing environments are using Scale+Protect with tape.  Management wants 
us to move away from tape where possible.
We do one filesystem per cluster.  So, there will be two new clusters.
We are still finalizing the sizing, but the expectation is both of them will be 
somewhere in the3-5PB range.

We understand that if we replicate corrupted data, the corruption will go with 
it.  But the same would be true for a backup (unless I am not quite following 
you).

The thought is that not using Protect and simply doing replication with 
snapshots will enable faster recovery from a catastrophic failure of the 
production environment, whereas with Protect we would have to restore petabytes 
of data.

FWIW, this is the same method we are using in our NAS (Isilon), but those 
utilities are designed for that type of use, and there is no equivalent to 
mmbackup.  Our largest Scale environment is 7+PB, and we can complete a backup 
of it in one night with mmbackup.  We abandoned tape backups on our NAS at 
around 600TB.

From:  on behalf of Andrew Beattie 

Reply-To: gpfsug main discussion list 
Date: Tuesday, May 8, 2018 at 4:38 PM
To: "gpfsug-discuss@spectrumscale.org" 
Cc: "gpfsug-discuss@spectrumscale.org" 
Subject: Re: [gpfsug-discuss] Snapshots for backups

Hi Jonathan,

First off a couple of questions:

1) your using Scale+Protect with Tape today?
2) your new filesystems will be within the same cluster ?
3) What capacity are the new filesystems

Based on the above then:

AFM-DR will give you the Replication that you are talking about -- please talk 
to your local IBM people about the limitations of AFM-DR to ensure it will work 
for your use case
Scale supports snapshots - but as mentioned snapshots are not a backup of your 
filesystem - if you snapshot corrupt data you will replicate that to the DR 
location

If you are going to spin up new infrastructure in a DR location have you 
considered looking at an object store and using your existing Protect 
environment to allow you to Protect environment to HSM out to a Disk basked 
object storage pool distributed over disparate geographic locations? (obviously 
capacity dependent)

Andrew Beattie
Software Defined Storage  - IT Specialist
Phone: 614-2133-7927
E-mail: abeat...@au1.ibm.com


- Original message -
From: "Fosburgh,Jonathan" 
Sent by: gpfsug-discuss-boun...@spectrumscale.org
To: gpfsug main discussion list 
Cc:
Subject: [gpfsug-discuss] Snapshots for backups
Date: Tue, May 8, 2018 11:43 PM



We are looking at standing up some new filesystems and management would like us 
to investigate alternative options to Scale+Protect.  In particular, they are 
interested in the following:



Replicate to a remote filesystem (I assume this is best done via AFM).

Take periodic (probably daily) snapshots at the remote site.



The thought here is that this gives us the ability to restore data more quickly 
than we could with tape and also gives us a DR system in the event of a failure 
at the primary site.  Does anyone have experience with this kind of setup?  I 
know this is a solution that will require a fair amount of scripting and some 
cron jobs, both of which will introduce a level of human error.  Are there any 
other gotchas we should be aware of?

The information contained in this e-mail message may be privileged, 
confidential, and/or protected from disclosure. This e-mail message may contain 
protected health information (PHI); dissemination of PHI should comply with 
applicable federal and state laws. If you are not the intended recipient, or an 
authorized representative of the intended recipient, any further review, 
disclosure, use, dissemination, distribution, or copying of this message or any 
attachment (or the information contained therein) is strictly prohibited. If 
you think that you have received this e-mail message in error, please notify 
the sender by return e-mail and delete all references to it and its contents 
from your systems.
___
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss



The information contained in this e-mail message may be privileged, 
confidential, and/or protected from disclosure. This e-mail message may contain 
protected health information (PHI); dissemination of PHI should comply with 
applicable federal and state laws. If you are not the intended recipient, or an 
authorized representative of the intended recipient, any further review, 
disclosure, use, dissemination, distribution, or copying of this message or any 
attachment (or the information contained therein) is strictly prohibited. If 
you think that you have received this e-mail message in