toasters

toasters@lists.teaparty.net

13514 discussions

Cyclades Tricks
by Robert Borowicz 08 Oct '04

08 Oct '04

OK I went out and got myself a couple of Cyclades Terminal servers (asc32's) and love them. But I haven't figured out how to send a "Stop A" or "L1 A" on the Suns to them. Has anybody here got some tricks to do that on your Cyclades? I wrote their support about "ctl-alt-del" and they summarily told me it was NOT possible on a serial device. Thanks -Bob

2 1

Demos um pulinho na Deep Trance
by Raves.com.br 08 Oct '04

08 Oct '04

1 0

Free NetApp 36U cabinets available
by Scott Fischmann 07 Oct '04

07 Oct '04

1 0

Undeliverable: Re:
by System Administrator 07 Oct '04

07 Oct '04

Your message To: Malek.hamdan Subject: Re: Sent: Thu, 7 Oct 2004 13:19:12 +1000 did not reach the following recipient(s): Malek.hamdan on Thu, 7 Oct 2004 12:19:22 +1000 The recipient name is not recognized The MTS-ID of the original message is: c=au;a=telememo ;p=davnet pty. ltd.;l=SYD-MAIL-0104100702194AVY75RH MSEXCH:IMS:Davnet Pty. Ltd.:Sydney:SYD-MAIL-01 0 (000C05A6) Unknown Recipient

1 0

Undeliverable: Re:
by System Administrator 06 Oct '04

06 Oct '04

Your message To: Malek.hamdan Subject: Re: Sent: Thu, 7 Oct 2004 06:11:47 +1000 did not reach the following recipient(s): Malek.hamdan on Thu, 7 Oct 2004 05:11:55 +1000 The recipient name is not recognized The MTS-ID of the original message is: c=au;a=telememo ;p=davnet pty. ltd.;l=SYD-MAIL-0104100619114AVY7YM5 MSEXCH:IMS:Davnet Pty. Ltd.:Sydney:SYD-MAIL-01 0 (000C05A6) Unknown Recipient

1 0

(no subject)
by Marco Teeuwen 06 Oct '04

06 Oct '04

1 0

Undeliverable: Re:
by System Administrator 06 Oct '04

06 Oct '04

Your message To: Malek.hamdan Subject: Re: Sent: Wed, 6 Oct 2004 11:23:34 +1000 did not reach the following recipient(s): Malek.hamdan on Wed, 6 Oct 2004 10:23:44 +1000 The recipient name is not recognized The MTS-ID of the original message is: c=au;a=telememo ;p=davnet pty. ltd.;l=SYD-MAIL-0104100600234AVY7TLM MSEXCH:IMS:Davnet Pty. Ltd.:Sydney:SYD-MAIL-01 0 (000C05A6) Unknown Recipient

1 0

RE: Backups of Snapshots
by Alan Biren 05 Oct '04

05 Oct '04

Alan, I agree with your recommendations. However, I usually leave keep a couple of snapshots that were used for backs around for even quicker restores, instead of going to tape. I also use a naming pattern similar to NetApp and create a hidden share to the .snapshot directory as each volume has it's own. Ie: rsh filer snp delte dailybackup.1 rsh filer snap rename dailybackup.0 dailybackup.1 rsh filer snap create volname dailbackup.0 backup \\filer\snapshare\dailbackup.0 <file:///\\filer\snapshare\dailbackup.0> Regards, Alan Biren Senior Systems Engineer/Storage Architect AMC Corporation 48 West 37th Street New York, NY 10018 (212) 736-0111 www.amccorp.com -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Alan.McLachlan(a)didata.com.au Sent: Tuesday, October 05, 2004 12:38 AM To: toasters(a)mathworks.com Subject: Re: Backups of Snapshots Kevin, This isn't what Jack's trying to acheive. However, besides that it's a dangerous recommendation. Automatic scheduled snapshots are rotated out by their naming convention. i.e. "nightly.0" is always last night's midnight snapshot. So, if for some reason the backup takes more than 24 hours to write to tape, or is delayed by a sheduling issue or a downed drive or whatever, you run the risk of a temporally inconsistent backup on tape after the snapshot rotation occurs. This might be made obvious by errors occuring because a file that was in the original directory map and was deleted during the backup disappear from the "nightly.0" snapshot when it's rotated for the next night (the previous night becomes "nightly.1"). i.e. you should always backup using the automatic "snapshot for backup.x" created by the NDMP client in Data OnTap, or use a manual snapshot. It is never wise to use the built-in scheduled snapshots for anything other than point-in-time restores from disk, because their contents will change at the next shedule period. I agree with your comment about using a static name. But you need both the name _and_ the *contents* to remain static, which isn't the case with the OnTap sheduled snapshots. A manual snapshot is always best for this, i.e. a script like: (using the snapshot name "dailybackup" rsh filer snap delete dailybackup ;(delete previous manual snapshot you've hung on to for restores) rsh filer snap create dailybackup backup /filer/.snapshot/dailybackup/ ;(or for Windows create a share that always points to the root of the snapshot and use that) regards, Alan McLachlan ___________________________________ Solution Architect - Data Centre Solutions Dimension Data Australia Alan.McLachlan(a)didata.com.au Tel. +61 (0)2 61225123 Fax +61 (0)2 62486346 Mobile 0428 655644 ----- Forwarded by Alan McLachlan on 05/10/2004 02:20 PM ----- "Kevin Mascarenhas" <KMascarenhas(a)syncsort.com> Sent by: owner-toasters(a)mathworks.com 01/10/2004 11:28 PM Please respond to "Kevin Mascarenhas" To: "Jack Lyons" <jack.lyons(a)martinagency.com> cc: <toasters(a)mathworks.com> Subject: Re: Backups of Snapshots Hi Jack, One other option you can consider is specifying an existing snapshot as your NDMP backup source. For example, if you configured your filer to take nightly snapshots at say 11:00pm and had your scheduled NDMP backups start at sometime after that, then you could configure the backup job to use the "nightly.0" snapshot as the backup source. When a snapshot is specified in this way, NDMP driven dump will not create another one for backup. Any backup software should allow you to define a job that uses an existing snapshot (or a snapshot that will exist at the time the job will run) for backup. Of course it's simplest if you configure the job to use a static snapshot name rather than one which will change each time the job is run so NetApp scheduled automatic snapshots will work perfectly. HTH. Kevin Kevin Mascarenhas KMascarenhas(a)syncsort.com Syncsort Inc. 50 Tice Blvd. Woodcliff Lake, NJ 07677 Tel: (201) 930-9700 http://www.syncsort.com ----- Original Message ----- From: "Jack Lyons" <jack.lyons(a)martinagency.com> To: "Paul Galjan" <galjan(a)gmail.com> Cc: <toasters(a)mathworks.com> Sent: Friday, October 01, 2004 6:45 AM Subject: Re: Backups of Snapshots > I guess that makes sense. it would have been nice to be able to look > restore a snapshot directory from 4 months ago! > > It looks like I could do a monthly snapshot manually and see how much space > it takes up. Right now, my snapshots are only taking up 23% of the space > allocated for snapshots. I am going to experiment with taking 6 "monthly > snapshots" > > Jack > ----- Original Message ----- > From: "Paul Galjan" <galjan(a)gmail.com> > To: "Jack Lyons" <jack.lyons(a)martinagency.com> > Cc: <toasters(a)mathworks.com> > Sent: Thursday, September 30, 2004 7:23 PM > Subject: Re: Backups of Snapshots > > > > Hi Jack, > > > > The snapshot directory is not included as part of the NDMP dump. When > > the filer is told to do an NDMP dump, it actually takes a snapshot, > > then dumps the data from that snapshot. > > > > --paul > > > > On Thu, 30 Sep 2004 18:41:11 -0400, Jack Lyons > > <jack.lyons(a)martinagency.com> wrote: > >> I had a user request a file from 4 months ago. The tape backups happened > >> at > >> 11:00 PM but the file they needed was earlier in the day. I was thinking > >> that the backups might have included the snapshot directory but it > >> didn't? > >> Is that configurable? > >> > >> Jack > >> > >> > > > ************************************************************************ ****** - NOTICE FROM DIMENSION DATA AUSTRALIA This message is confidential, and may contain proprietary or legally privileged information. If you have received this email in error, please notify the sender and delete it immediately. Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments. ************************************************************************ ****** ***************************************************************************************************** If you have received this email in error please notify the the system manager or the sender immediately and do not disclosed the to anyone or make copies. ** eSafe scanned this email for viruses, vandals or malicious content ** ** To find out eSafe(TM) and other Aladdin Security Products, contact AMC Corporation at (212) 620-0700 *****************************************************************************************************

1 0

filer MRTG mods to see tape and disk IO, and consistent network io, and larger charts
by Tim McDonough 05 Oct '04

05 Oct '04

Hi Folks: Looking for general MRTG docs on how to modify the stock config to see: tape io for the filer ( read and write ) disk io .... larger charts consistent network info ( have gaps, and 'stuck points' where the network rate is the same for 3 hours ( sysstat confirms it's now ) Thanks

1 0

Re: Backups of Snapshots
by Alan.McLachlan＠didata.com.au 05 Oct '04

05 Oct '04

Kevin, This isn't what Jack's trying to acheive. However, besides that it's a dangerous recommendation. Automatic scheduled snapshots are rotated out by their naming convention. i.e. "nightly.0" is always last night's midnight snapshot. So, if for some reason the backup takes more than 24 hours to write to tape, or is delayed by a sheduling issue or a downed drive or whatever, you run the risk of a temporally inconsistent backup on tape after the snapshot rotation occurs. This might be made obvious by errors occuring because a file that was in the original directory map and was deleted during the backup disappear from the "nightly.0" snapshot when it's rotated for the next night (the previous night becomes "nightly.1"). i.e. you should always backup using the automatic "snapshot for backup.x" created by the NDMP client in Data OnTap, or use a manual snapshot. It is never wise to use the built-in scheduled snapshots for anything other than point-in-time restores from disk, because their contents will change at the next shedule period. I agree with your comment about using a static name. But you need both the name _and_ the *contents* to remain static, which isn't the case with the OnTap sheduled snapshots. A manual snapshot is always best for this, i.e. a script like: (using the snapshot name "dailybackup" rsh filer snap delete dailybackup ;(delete previous manual snapshot you've hung on to for restores) rsh filer snap create dailybackup backup /filer/.snapshot/dailybackup/ ;(or for Windows create a share that always points to the root of the snapshot and use that) regards, Alan McLachlan ___________________________________ Solution Architect - Data Centre Solutions Dimension Data Australia Alan.McLachlan(a)didata.com.au Tel. +61 (0)2 61225123 Fax +61 (0)2 62486346 Mobile 0428 655644 ----- Forwarded by Alan McLachlan on 05/10/2004 02:20 PM ----- "Kevin Mascarenhas" <KMascarenhas(a)syncsort.com> Sent by: owner-toasters(a)mathworks.com 01/10/2004 11:28 PM Please respond to "Kevin Mascarenhas" To: "Jack Lyons" <jack.lyons(a)martinagency.com> cc: <toasters(a)mathworks.com> Subject: Re: Backups of Snapshots Hi Jack, One other option you can consider is specifying an existing snapshot as your NDMP backup source. For example, if you configured your filer to take nightly snapshots at say 11:00pm and had your scheduled NDMP backups start at sometime after that, then you could configure the backup job to use the "nightly.0" snapshot as the backup source. When a snapshot is specified in this way, NDMP driven dump will not create another one for backup. Any backup software should allow you to define a job that uses an existing snapshot (or a snapshot that will exist at the time the job will run) for backup. Of course it's simplest if you configure the job to use a static snapshot name rather than one which will change each time the job is run so NetApp scheduled automatic snapshots will work perfectly. HTH. Kevin Kevin Mascarenhas KMascarenhas(a)syncsort.com Syncsort Inc. 50 Tice Blvd. Woodcliff Lake, NJ 07677 Tel: (201) 930-9700 http://www.syncsort.com ----- Original Message ----- From: "Jack Lyons" <jack.lyons(a)martinagency.com> To: "Paul Galjan" <galjan(a)gmail.com> Cc: <toasters(a)mathworks.com> Sent: Friday, October 01, 2004 6:45 AM Subject: Re: Backups of Snapshots > I guess that makes sense. it would have been nice to be able to look > restore a snapshot directory from 4 months ago! > > It looks like I could do a monthly snapshot manually and see how much space > it takes up. Right now, my snapshots are only taking up 23% of the space > allocated for snapshots. I am going to experiment with taking 6 "monthly > snapshots" > > Jack > ----- Original Message ----- > From: "Paul Galjan" <galjan(a)gmail.com> > To: "Jack Lyons" <jack.lyons(a)martinagency.com> > Cc: <toasters(a)mathworks.com> > Sent: Thursday, September 30, 2004 7:23 PM > Subject: Re: Backups of Snapshots > > > > Hi Jack, > > > > The snapshot directory is not included as part of the NDMP dump. When > > the filer is told to do an NDMP dump, it actually takes a snapshot, > > then dumps the data from that snapshot. > > > > --paul > > > > On Thu, 30 Sep 2004 18:41:11 -0400, Jack Lyons > > <jack.lyons(a)martinagency.com> wrote: > >> I had a user request a file from 4 months ago. The tape backups happened > >> at > >> 11:00 PM but the file they needed was earlier in the day. I was thinking > >> that the backups might have included the snapshot directory but it > >> didn't? > >> Is that configurable? > >> > >> Jack > >> > >> > > > ****************************************************************************** - NOTICE FROM DIMENSION DATA AUSTRALIA This message is confidential, and may contain proprietary or legally privileged information. If you have received this email in error, please notify the sender and delete it immediately. Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments. ******************************************************************************

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters