I'm setting up a file disk device finally on a new RAID. I am cloning a set of tapes for offsite storage for a year. I've set the browse/retention time to one year so the tapes don't expire. I can use mminfo to get the list of cloneid's on the disk volumes that are older than a certain time, depending on disk space, maybe 6 or 8 weeks. And then pipe those id's to nsrmm to have them removed from the databases. My question is how do they actually get removed from the disk to free up space? Nsrmm doesn't seem to do that in my tests. I still see the files on the volume with the name format of 'ssid'.0. So a script to remove them with the ssid from mminfo isn't a problem if the .0 is consistant, is it? I don't see a query in mminfo to show the actual file name. Is there a better way to delete the files?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
NW 6.1.3 Solaris file disk management 1
- Thread starter mtinode
- Start date
Database operations usually so not affect the backup media at all, especially not in NW 6.3.
In NW 7.x you can do this but in this case you or the NW server must initiate the nsrim command.
This applies to EXPIRED save sets only (recyclable). However, if you REMOVE/SELETE the SS information, what do you expect NW to do? - How shall it find information about such save sets?
In NW 7.x you can do this but in this case you or the NW server must initiate the nsrim command.
This applies to EXPIRED save sets only (recyclable). However, if you REMOVE/SELETE the SS information, what do you expect NW to do? - How shall it find information about such save sets?
- Thread starter
- #3
So far, I've only used expired save sets. But I'd like to be able to keep the offsite clones from expiring. So the plan was to set the browse and recovery times to accomodate the offsite tapes. Then let the online backups to the file device be maintained via scripts using mminfo to determine which save sets clones were older than a certain time and pass that information to nsrmm -d to remove them from the indexes leaving the tape clone save set information intact. But I still need to actually remove the data from the disk device. It's of no use if it's not in the indexes.
I could just keep my expire time at a shorter interval that would not quite fill the disks, then just remove the expired ones. But that still leaves me the problem of how do the actual files get removed from the disk? And how do I determine their actual name without resorting to ls, or is the name always suffixed by .0? So far that's working. I can mminfo -av -q ssrecycle,family=disk -r ssid,cloneid and then use that information to nsrmm -d to delete the disk clone from the indexes. And then finally rm the ssid.0 file from the disk. But if I don't rm the file, it just sets there forever, unless I just haven't waited long enough. This leaves me the tape offsite still in the index, but it's expired, so I can't browse it if I need to recover something from it quickly.
The alternative is wasting some disk space to stage to and then relabeling it to delete the files from it and the indexes. That's just not very efficient, and way too much overhead.
I could just keep my expire time at a shorter interval that would not quite fill the disks, then just remove the expired ones. But that still leaves me the problem of how do the actual files get removed from the disk? And how do I determine their actual name without resorting to ls, or is the name always suffixed by .0? So far that's working. I can mminfo -av -q ssrecycle,family=disk -r ssid,cloneid and then use that information to nsrmm -d to delete the disk clone from the indexes. And then finally rm the ssid.0 file from the disk. But if I don't rm the file, it just sets there forever, unless I just haven't waited long enough. This leaves me the tape offsite still in the index, but it's expired, so I can't browse it if I need to recover something from it quickly.
The alternative is wasting some disk space to stage to and then relabeling it to delete the files from it and the indexes. That's just not very efficient, and way too much overhead.
- Thread starter
- #5
- Thread starter
- #7
-
1
- #8
I would use nsrmm as you've already tried. I've never ran in to the problem that it does not delete the files though. But it has been some time since I actually used 6.1.3. For what you are trying to do I usually use nsrmm to delete the cloneid for the save set on the disk. Something like
nsrmm -d -S ssid/cloneid -y
This removes the save set on disk and leaves the one on tape if you have set up your mminfo query correct. It doesn't touch the file index, only media index so the other cloneid will still be subject to the original browse and retention policies.
I can't remember if the nsrstage -C option was available in 6.1.3, but you could have a look for that in the docs. That does volume cleaning for you.
nsrmm -d -S ssid/cloneid -y
This removes the save set on disk and leaves the one on tape if you have set up your mminfo query correct. It doesn't touch the file index, only media index so the other cloneid will still be subject to the original browse and retention policies.
I can't remember if the nsrstage -C option was available in 6.1.3, but you could have a look for that in the docs. That does volume cleaning for you.
To Rif123...
Your statements are simply wrong. Also they are unlogical. Why do you want to keep the file index info if there is no save set associated with it any longer? - what would that be good for?
Your help is appreciated. But please avoid such confusing statements and read the manpage first or do a brief test.
Your statements are simply wrong. Also they are unlogical. Why do you want to keep the file index info if there is no save set associated with it any longer? - what would that be good for?
Your help is appreciated. But please avoid such confusing statements and read the manpage first or do a brief test.
What is confusing? If you have two copies of a SSID and removes one of them, by using the nsrmm -d -S ssid/cloneid the other cloneid is not deleted. This is still both in media and file index. It would NOT be such a good idea to remove file index when the other copy still relies on that information. The point was to have a short retention on disk (simply by removing it before actual retention expires) and a long browse/retention for the clone on tape. So if you remove one of the copies, that does not remove the file index or alter the browse/retention policies. That wouldn't make any sence. I've used this many times before the individual retention was introduced in 7.3.
I am sorry, i forgot about the clone ('normal' ss also have a clone id, of course).
However, i still disagree with your statement "This removes the save set on disk ...". I just tested this with NW 6.1.4 again and as i said, a deleted save set instance will not automatically be deleted from the disk media. And later, this will not be possible as the reference in the media index does not exist any more.
However, i still disagree with your statement "This removes the save set on disk ...". I just tested this with NW 6.1.4 again and as i said, a deleted save set instance will not automatically be deleted from the disk media. And later, this will not be possible as the reference in the media index does not exist any more.
You are right that NetWorker 6 does not delete the files from the disk with nsrmm. This works in NetWorker 7.X though and the adv file type device.
But this was why I suggested to use nsrstage -C -V VolumeName, ie volume cleaning, which I by the way now have tested with 6.1.3 and that deletes all non referenced cloneid's from the disk. So I would prefere using this approach rather than deleting files on my own. So the approach would be to run
mminfo ????? -r ssid,cloneid
nsrmm -d -S ssid/cloneid -y
nsrstage -C -V VolumeName
This should do the job and clean the disk.
But this was why I suggested to use nsrstage -C -V VolumeName, ie volume cleaning, which I by the way now have tested with 6.1.3 and that deletes all non referenced cloneid's from the disk. So I would prefere using this approach rather than deleting files on my own. So the approach would be to run
mminfo ????? -r ssid,cloneid
nsrmm -d -S ssid/cloneid -y
nsrstage -C -V VolumeName
This should do the job and clean the disk.
- Thread starter
- #13
- Status
Similar threads
- Locked
- Question