Networker

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

2009-01-02 23:27:11
Subject: Re: [Networker] SV: [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: Sat, 3 Jan 2009 06:20:31 +0200
Ben Deng wrote:
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.

If your script already uses mminfo to select those ssids to be deleted from the volumes, all you need to do is modify the mminfo q flag and add the volume= flag to restrict the query results to the problematic volume.


-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