Networker

Re: [Networker] SV: [Networker] Backup to Adv-file device

2009-01-01 19:17:47
Subject: Re: [Networker] SV: [Networker] Backup to Adv-file device
From: Yaron Zabary <yaron AT ARISTO.TAU.AC DOT IL>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Fri, 2 Jan 2009 02:15:20 +0200
Ben Deng wrote:
Thanks for these answers,

We do not use staging because those savesets on disk volumes already are cloned 
to tapes after backupgroups was finished. And a scheduled cloning job also 
running and search savesets, not being cloned by backupgroups, and clone them 
to tapes.  Once a day there is a scheduled job to search for savesets that are 
older than 28 days and delete them. So far it works ok. But it doesn't help to 
solve the problem with a volumes not have anymore space during backup, while in 
the same time there are plenty spaces in other volumes.  Advfile device is 
designed to be use with diskdevices and why should spaces be limited within a 
single volumes? Just because it's design from beginning as such behaviour, 
doesn't mean it couldn't be change for the better.

  Ac couple of suggestions:

. When you are out of space on a AFTD use your existing script that deletes old savesets, but tell it to delete savesets older than 27 days (or 26). Just do that until you get enough space. By the way, you practically implemented "delayed staging" which is a feature that I always thought is desired for AFTD.

. Try to distribute the backup process to all devices. I suppose that all AFTDs belong to the same pool. You can monitor the utilization of them and put the most utilized device in read only mode so that new data doesn't go to it. This will make sure that data is spread evenly on all devices.

. If you are not intimidated by a 30Tb file system, you can simply collapse all existing file systems into a single one and avoid this utilization problems. If you are on Solaris 10, ZFS should be able to do that quite easily, although I am not sure what will be the performance impact of such a change. >Iknow there's EMC representatives monitoring this forum, so I therefore urge them to consider a redesign of adv-file device, maybe making a adv-file volume group will solve this problem.

Yes, unfortunately, I wasn't under the impression that they are in a position to conduct an open dialog with our user community. They are most likely restricted by some EMC policy (most likely devised by legal advisers), which doesn't allow them to do that. They usually lurk and I also didn't see any ideas discussed in this list show up later in Networker (as opposed to a dialog).


Regars,

Ben Deng



--

-- Yaron.

To sign off this list, send email to listserv AT listserv.temple DOT edu and type 
"signoff networker" in the body of the email. Please write to networker-request 
AT listserv.temple DOT edu if you have any problems with this list. You can access the 
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER