I´ve already went through some of these suggestions and didn´t get a working 
solution because:

-Changing my deletescript from 28 days to a shorter day may or may not release 
spaces to a waiting backupgroup, because the those savesets being deleted isn´t 
necessary coming from the volume needed. And I´ve already a mix of 
deletescripts implemented (28 days, 14 days and 7 days). The reason  we decide 
to use cloning instead of staging  is offsite tape  location policy. Tapes for 
a weeks backup will be move out of out company and keeping save in outside 
location.

-Distribute the backup process is already implemented as far as it can be, the 
problem is when a volume have only 200GB space left and out Oracle backup needs 
300GB, the backup process will stop after the use of 200GB. 200GB is normally 
adequate for other backup clients, so it will be waist of many GB if I always 
reserve enough space in all volume for our Oracle DB. I wish Networker have a 
spacecheck feature before it starts to make backup to a device.

-We are using Windows 2003 as Networker host and those volumes are located in 2 
of our Nexsan Satabeast disksystems. Therefore it will be difficult to make a 
single volume. Even if we could it will then suffer from performance impact. 
I´ve already tested it before installing out Networker host.

Regards.

Ben

 
-----Oprindelig meddelelse-----
Fra: Yaron Zabary [mailto:yaron AT aristo.tau.ac DOT il] 
Sendt: 2. januar 2009 01:15
Til: EMC NetWorker discussion; Ben Deng
Emne: Re: [Networker] SV: [Networker] Backup to Adv-file device

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