IDATA Tools v4

 NetWorker  3 Responses »
Apr 302009
 

For the last several weeks I’ve been doing a lot of development work, putting the finishing touches on IDATA Tools v4, and it’s being released 1 May (AU/NZ – 30 April US, etc.)

This represents a significant functionality bump over the last version of IDATA Tools, and I thought I’d spend a few minutes mentioning some of the new features that I think make the tool set both useful and very compelling. This is by no means a comprehensive list – there’s been a lot of improvements.

By the way, in the list below I’m saving the best to last, so make sure you follow it right to the bottom!

list-resources

This is a new utility with one purpose, that being to quickly list all the resources of a given type as defined on the NetWorker server. This is basic, and a lot of people have scripted similar things in the past, but included in this tool suite, it helps you write your own scripts. Using list-resources, you can quickly grab details of all the configured clients, and then step through each client name in your own script to run some task, or do something to each configured group, etc. It has two output modes – the default is “human readable”, designed for when you just want to get some information out of the server. The second is delimited format – your choice of delimiter. This means you can extract information about any resource (and any field within a resource) in one simple command, in the format you want, for use wherever else you want.

For example, if you wanted a list of all your groups, whether they automatically clone and which pool they clone to, it would be as simple as:

C:\> list-resources -t group -c, -F "clones,clone pool"
Default,No,Default Clone
Daily Desktops,Yes,Daily Clone
Daily Development,Yes,Daily Clone
Daily NMC,No,Default Clone

Or, if you wanted a list of your licenses with their enabler codes and authorisation codes, you could run:

# list-resources -t license -c, -F "enabler code,auth code"

I developed list-resources on a whim, because I got tired of firing up nsradmin (let alone NMC!) every time I wanted to quickly check out some configuration option or get a list of resources. I was pleasantly surprised when every beta tester for IDATA Tools v4 commented on how useful the utility was for their environment.

check-clients

This long-term utility has been a bit of a sleeper – it’s not used as often as I think it should be used. I do strongly recommend that you give it a go – it’s great at automating a lot of tests and checks against clients, meaning that if you’ve got even just one client that’s malfunctioning, you can set check-clients running against it and gather all results in one command. For example, even something as basic as reconfirming name resolution for all active clients is as simple as could be using check-clients:

[root@nox ~]# check-clients -t resolution -g all_active
=======================================================
Running test: resolution (Test/confirm name resolution)
=======================================================
    aralathan
        Name: aralathan (aralathan.lab.idata.com.au) (192.168.100.7)
        Name: aralathan.lab.idata.com.au (aralathan.lab.idata.com.au) (192.168.100.7)
        Addr: 192.168.100.7 (aralathan.lab.idata.com.au)
    archon
        Name: archon (archon.lab.idata.com.au) (192.168.100.1)
        Name: archon.lab.idata.com.au (archon.lab.idata.com.au) (192.168.100.1)
        Addr: 192.168.100.1 (archon.lab.idata.com.au)
    arcweld
        Name: arcweld (arcweld.lab.idata.com.au) (192.168.100.232)
        Name: arcweld.lab.idata.com.au (arcweld.lab.idata.com.au) (192.168.100.232)
        Addr: 192.168.100.232 (arcweld.lab.idata.com.au)

Now in v4, there’s several new checks and pseudo-reporting options available. One requested by a new IDATA Tools customer is a particular favourite – generating details of the amount of space occupied by all backups for each client. The output looks like the following:

[root@nox ~]# check-clients -t used_space -g all_active
============================================================
Running test: used_space (Calculates used space for backups)
============================================================
    Client                         Used Space (GB)    
    ----------------------------   --------------------
    aralathan                                 138.51074
    archon                                     53.18894
    arcweld                                     2.98269
    asgard                                      7.92337

(I’ve cut the output there – you don’t need to see a full list of all my lab machines to get the idea.) Note the “all_active” option there; the command line means: run the used_space test against all clients that happen to belong to groups that are active (autostart enabled). No fussing around with long lists of clients if you don’t want to.

Additionally, as a sanity check run once a week (or even once a day), how about checking to see whether there’s any clients with empty indices?

C:\> check-clients -t empty -a
=======================================================
Running test: empty (Report clients with empty indices)
=======================================================
    rhltst5 has an empty index
    nazgul has an empty index
    rhltst6 has an empty index
    shrike has an empty index
    rhltst3 has an empty index
    rhltst4 has an empty index
    grumpy has an empty index

Phew! Lucky it’s a lab server otherwise there’d be trouble at the station.

Reporting enhancements

Under reporting more generally, there’s a whole raft of enhancements:

  1. Both client-report and review-res now allow you to specify additional fields to be reported on; thus, it doesn’t matter if your reporting requirements are different any more, you can just run the same reporting utility and add the extra required fields in. We also report on the client ID wherever possible too.
  2. (In fact, given how important it is to regularly, routinely extract details of clients and their client ID fields, the check-clients utility also has a new test which extracts and prints this information.)
  3. The idata-notify tool, always an excellent savegroup completion parser, has some extra options. First, it can now give you details of the last full backup date for each saveset listed in the savegroup completion report, and it can also now send all the additional information as a HTML attachment, such as in this example.
  4. Additional options are available in the find-files utility to allow you to run faster queries.

Portion Control for Cloning and Staging

These are without a doubt the two biggest enhancements to IDATA Tools in this release. By “portion control” I mean automatically break up cloning and staging operations into smaller, more granular activities with pauses inbetween by running operating on savesets at any one time.

Where is this useful? Let’s examine each utility:

  • In relation to cloning, sslocate supports portioning of the data to be cloned so you can set a large clone job running and know that periodically it’s going to stop, release resources, and in doing so give them up to anything that’s been sitting waiting for resources to become available. If a recovery is waiting for the tape you’re reading on to clone from, the recovery will get a chance to run before all cloning has finished, rather than you having to abort the cloning.
  • In relation to staging, dbufree is significantly more useful at freeing up space faster. Consider the following – you’ve got 200GB of a backup left to run, your disk backup unit fills, and you have to wait for NetWorker to stage out 500 GB due to watermarks before you can finish your backup. It’s maddening, right? Well, with portioning, you could still tell dbufree to stage out 500 GB of data, but to do it in portions of approximately 100GB. Disk backup unit space will get released at the end of each portion, meaning that instead of waiting for 500 GB to be staged, you’ll see space reclaimed after approximately 100GB, then another 100GB, and so on.

For both cloning and staging, you also get a level of reporting not normally available. Everyone when they run cloning and staging eventually get to the point of wondering “where is this at? how much is left to go?” Now by keeping an eye on the portion based cloning and staging, you’ll have a much better idea of how much data has already been copied, and how much is left to run.

In Summary

We’ve really put a lot of new features into IDATA Tools for this new release. Existing users should find the upgrade reasons compelling, and those of you who haven’t tried out IDATA Tools yet should contact us to request a trial.

 Posted by Preston de Guise at 19:57  Tagged with: , ,

Screen shots don't constitute logs

 NetWorker, Support  No Responses »
Apr 292009
 

You might term this an appeal from every person who does support.

If you’re dealing with a support service with NetWorker, regardless of whether it’s EMC or some other company, it always pays to remember that screen shots do not constitute logs. Some people do have a tendency to shoot of a screen request when they request support, and as a long term provider of support and consulting in NetWorker, I’d just like to humbly beg you, if you’re about to do that, to seriously, seriously reconsider what you’re doing.

I like to rationalise it this way – consider your support “event” to be a movie. For example, if tape drives have been experiencing issues and failures overnight from 22:00 through to 08:00 the next day, that’s a 10 hour movie.

Using this analogy, sending a screen shot is akin to sending one single frame from a 10 hour movie and asking someone to provide you a complete plot summary and script for that movie.

As you may imagine, that doesn’t really work.

Sometimes there is a place for screen shots – they can be useful in certain situations. However, with NetWorker, a product that features excellent logging, there is no substitute for sending through the appropriate log files to your support provider. Like the entire movie vs a single frame, these provide the complete plot to your support team, and allow them to fully appreciate the overall state of the NetWorker server for the duration of the issue.

When you do send through logs, rather than screen shots, for NetWorker, you should always:

  • Take a copy of the file first
  • Compress the copy of the file

You will normally get at least a 10:1 compression ratio on text logs. So what might be a 5MB screen shot, or a 4MB plain text log file, should come down to 400KB or less.

Please, send logs, not screen shots, unless you’re asked otherwise. Your support person will thank you for it, and you’ll probably get resolution quicker.

–
I have one other personal preference when it comes to screen shots. Please, please don’t send them as a picture pasted into a word document. Either paste them directly into the email (modern email systems support this), or save them as an independent picture and send them through as an attachment.

 Posted by Preston de Guise at 16:58

Basics – nsrlic

 Basics  No Responses »
Apr 282009
 

One question that commonly comes up is “how do I get details of used licenses?”

The easiest way I find for this is the command line utility nsrlic. Run without any options, it’s only partially useful; run with a “-v” option for verbose mode, it becomes a lot more informative.

For example, here’s nsrlic output from a lab server:

[root@nox ~]# nsrlic -v
connecting to nox ...
12116:nsrlic: License Summary:
66441:nsrlic:  Available: sv=26, virt=0, ndmp=0
64047:nsrlic:  Borrowed:  sv_borrowed=0
66442:nsrlic:  Remaining: sv=2, virt=0, ndmp=0
69792:nsrlic: Connected Clients:(24)
 aralathan archon arcweld asgard delphi djwmp faero grumpy hammer loki mallet nazgul nimrod nox pan rhltst1 rhltst2 rhltst3 rhltst4 rhltst5 rhltst6 spanner thor valhalla
12128:nsrlic: NetWorker Module for Oracle on Linux: Available=1, Remaining=0, Used=1

      STANDARD CLIENT LICENSES
                     Available: 26
                          Used: 24
             Loaned to Virtual: 0
                     Remaining: 2
             Connected Clients: aralathan, archon, arcweld,
                                asgard, delphi, djwmp, faero,
                                grumpy, hammer, loki, mallet,
                                nazgul, nimrod,
                                nox, pan, rhltst1,
                                rhltst2, rhltst3, rhltst4,
                                rhltst5, rhltst6, spanner,
                                thor, valhalla;

       VIRTUAL CLIENT LICENSES
                     Available: 0
          Borrowed from Server: 0
                          Used: 0
                     Remaining: 0
             Connected Clients                              
          NDMP CLIENT LICENSES
                     Available: 0
                          Used: 0
                     Remaining: 0
             Connected Clients                              
   SERVER/CLUSTER CLIENT TYPES
                           AIX: 0
                  Digital UNIX: 0
                         HP UX: 0
                        HP MPE: 0
                         Linux: 13
                       NetWare: 1
             Network Appliance: 0
                 IBM DYNIX/ptx: 0
                           SGI: 0
                       Solaris: 2
                         SunOS: 0
                      UnixWare: 0
             Windows NT Server: 2                              
      WORKSTATION CLIENT TYPES
                           DOS: 0
                     Macintosh: 4
                          OS/2: 0
                  Windows 3.1x: 0
                    Windows 95: 0
        Windows NT Workstation: 2
                       UX/4800: 0
                        Others: 0

               Defined Clients: belle;
          PRE-5.0 CLIENT TYPES                              
          APPLICATION LICENSES

NetWorker Module for Oracle on Linux
                     Available: 1
                          Used: 1
                     Remaining: 0
             Connected Clients: delphi;

As you can see, there’s a lot of useful information in this report. For a start, you can see the report is broken into several sections, namely:

  • Initial output – provides a quick summary of all hosts that have some license allocated to them;
  • Standard client licenses – details for standard client connection license usage;
  • Virtual client licenses – details for virtual client licenses (I’m fairly certain this is new to 7.5);
  • NDMP client licenses – details for NDMP license usage;
  • Server/Cluster client licenses – details for clusters and servers;
  • Workstation client types – details for workstations;
  • Pre-5.0 Client types – any older clients;
  • Application Licenses – per (installed) module breakdown of hosts using application modules.

Each section gives clear details of licenses in use; for licenses that are allocated to individual clients, the actual “connected” (allocated) client details are provided when run in verbose mode. This allows you to quickly see what clients have access to which licenses.

What’s useful about nsrlic is that it aggregates and summarises licensing regardless of whether it’s occurring in NetWorker, in License Manager, or a combination of the two. Thus, you don’t have to go checking in diferent areas depending on your license allocation.

Tip: nsrlic can be run with a ‘-i’ option for interactive mode, where it behaves somewhat like nsradmin. While there’s little extra information available here than just running with the other command line options, it’s regardless useful to know.

 Posted by Preston de Guise at 09:08  Tagged with: ,

Meet your library

 General thoughts, Policies  No Responses »
Apr 262009
 

For larger sites in particular, we frequently end up in situations where backup or system administrators are sufficiently remote from the datacentre that they rarely interact with servers “face to face”. As remote management features continue to advance, allowing interaction with pseudo-shutdown servers and devices, this will only increase.

This level of remoteness can create unrealistic expectation of operation performance, particularly when the chips are down and something (e.g., a recovery) needs to be done urgently.

So there’s something very important you should do with your tape libraries – you should meet them. By meeting them, I mean the following:

  • Sit in front of them, with a laptop or console.
  • Make sure you can hear the library in operation.
  • Run at least the following commands:
    • Load;
    • Unload;
    • Relabel;
    • Inventory;
    • Import;
    • Device clean;
    • Export.
  • If possible, also do the following:
    • Monitor how long it takes media to rewind and become available for eject once EOM is reached;
    • Generate a SCSI bus reset while media is being read from to and observe how long it takes the library to recover;
    • Generate a SCSI bus reset while media is being written to and observe how long it takes the library to recover.

Knowing how long these operations take to complete fulfill two important (and overlapping) functions:

  1. You now have a timeframe for common activities to rely on when you’re otherwise stressed;
  2. You’re less likely to panic and intervene because something seems to be taking too long, when in actual fact you just don’t normally note how long an operation takes.

This is pretty important – I’ve seen a lot of important recoveries go from say, stressful to full panic when excessive intervention is taken on a tape library and it isn’t given appropriate time to “recover” from errors or interrupts.

Meeting brings understanding, understanding brings patience, patience brings success.

 Posted by Preston de Guise at 18:52  Tagged with: ,

Aside – Keyboards

 Aside  5 Responses »
Apr 252009
 

As a high speed touch typist, I have more than a strong regard for good keyboards. As someone who has dealt with RSI for the last 10+ years, I have an even stronger regard for healthy keyboards.

First, I’ll say from the outset that it’s my non-professional opinion that if you’re suffering from RSI and using a “wavy” keyboard (as pioneered by Microsoft), you need to throw it out. There’s a very important reason for this. The wave style keyboard is designed for hands “at rest” – and when you’re typing, your hands are not at rest. Thus, while the wavy keyboards are supposedly ergonomic, I and many other long term RSI sufferers find they simply exacerbate symptoms.

Kinesis-Ergo Keyboard

For a good 8 years, up until 18 months ago, I used one style of keyboard whenever I was at a desk – the Kinesis-Ergo Contoured keyboard:

Kinesis Ergo Contoured Keyboard (Photo from Kinesis product page)

Kinesis-Ergo Contoured Keyboard (photo linked from Kinesis product page)

This has two very important features for RSI sufferers:

  • The halves of the keyboard are separated far enough to encourage your arms into a 90 degree posture at your sides rather than stretching out or in;
  • The concave nature of the keys means that your fingers, when you type, stretch outwards/down, which is an entirely natural movement.

Honestly, if it weren’t for the Kinesis keyboard I’d have had to find another industry to work in.

Apple’s new streamlined keyboards

When Apple’s new streamlined keyboards came out, I was still using my Kinesis-Ergo keyboard, and was entirely dismissive of these spartan designs. I was certain the pseudo-chiclet key design would just make for a bad typing experience. If you’ve not seen these, they look like this:

Apple aluminium/streamlined keyboard (photo from Apple product page)

Apple aluminium/streamlined keyboard (photo linked from Apple product page)

Several weeks after the keyboards came out I was wandering past an Apple reseller’s store and noticed they had the keyboards, so I went into the store to type on the keyboard to affirm my distrust of them.

Imagine my surprise when I found it was quite simply the best keyboard experience I’ve ever had. The killer feature in these keyboards is the miniscule travel associated with hitting each key. Honestly, the typing force required on one of these keyboards is tiny – the only way I can describe it is that if you know the required force difference between trying to type on a manual type writer and a standard keyboard, you have some appreciation of the force difference required between typing on a regular keyboard and these Apple keyboards. It’s not quite the same amount, but it’s still quite a large amount.

I now use the Apple streamlined keyboards exclusively when I’m at a desk. They’re that good.

Physical Treatment

Having been a daily rail commuter for work, I usually saw a chiropractor every 4 weeks (now it’s around every 6); for years now I’ve been getting hand/arm adjustments as well as the regular adjustments (it’s not something a chiropractor typically looks at unless you ask them) – this definitely helped as a periodic treatment.

However, about 3 years ago I was referred to a “neuromuscular massage therapist”, who worked wonders on my RSI. Through some extremely painful sessions, she worked at decalcification in the tissues in my arms, which enabled better blood flow and muscular strength, which literally wiped 8 years of RSI from me in two sessions. Two very painful, but very important sessions. I now go back every year or so for a refresher.

Final thoughts

Obviously different people have different experiences with RSI, but given how much I had to endure while looking for solutions, I wanted to post my experiences in the hopes that it helps others.

I’m not a doctor, or have any physical sciences background – I’m a backup consultant, so don’t think I’m giving medical recommendations, just explaining what happened to work for me.

 Posted by Preston de Guise at 11:57  Tagged with: , ,

7.5(.1) changed behaviour – deleting savesets from adv_file

 Features, NetWorker  7 Responses »
Apr 252009
 

Yesterday I wanted to delete a few savesets from a lab server I’d upgraded from 7.4.4 to 7.5.1.

Wanting to go about it quickly, I did the following:

  • I used “nsrmm -dy -S ssid” for each saveset ID I wanted to delete, to erase it from the media database.
  • I used “nsrstage -C -V volumeName” for the disk backup unit volumes to run a cleaning operation.

Imagine my surprise when, instead of seeing a chunk of space being freed up, I got a lot of the following notifications:

nsrd adv_file warning: Failed to fetch the saveset(ss_t) structure for ssid 1890993582

I got one of these for every saveset I deleted. And since I’d run a lot of tests, that was a lot of savesets. The corresponding result was that they all remained on disk. What had been a tried and true version of saveset deletion under 7.4.x and below appears to not be so useful under 7.5.1.

In the end I had to run a comparison between media database content and disk backup unit content – i.e.:

# mminfo -q "volume=volName" -r "ssid(60)"

To extract the long saveset IDs, which are in effect the names of the files stored on disk, then:

# find /path/to/volume -name -print

Then for each filename, check to see whether it existed in the media database, and if it didn’t, manually delete it. This is not something the average user should do without talking to their support people by the way, but, well, I am support people and it was a lab server…

This change is worrying enough that I’ll be running up a couple of test servers using multiple operating systems (the above happened on Linux) to see whether its reproducible or whether there was just say, some freaky accident with the media database on my lab machine.

I’ll update this post accordingly.

[Update - 2009-04-27]

Have done some more tests on 7.5.1 on various Linux servers, comparing results to 7.4.4. This is definitely changed behaviour and I don’t like it, given that it’s very common for backup administrators to delete one or two savesets here and there from disk. Chatting to EMC about it.

In the interim, here’s a workaround I’ve come up with – instead of using nsrmm -d to delete the saveset, instead run:

# nsrmm -w now -e now -S ssid

To mark the saveset as immediately recyclable. Then run “nsrim -X” to force a purge. That will work. If you have scripts though that manually delete savesets from disk backup units, you should act now to update them.

[Update - 2009-04-30]

It would appear as well that if you delete then attempt to reclaim space, NetWorker will flag the “scan required” flag for a volume. Assuming you’re 100% OK with what you’ve manually deleted and then purged from disk using rm, you can probably safely clear the flag (nsrmm -o notscan). If you’re feeling paranoid, unmount the volume, scan it, then clear the flag.

[Update - 2009-05-06]

Confirmed this isn’t present in vanilla 7.5. It seemed to occur in 7.5.1.

[Update - 2009-06-16]

Cumulative patches for 7.5.1 have been released; according to EMC support these patches include the fixes for addressing this issue, allowing a return to normal operations. If you’re having this issue, make sure you touch base with EMC support or your EMC support partner to get access to the patches. (Note: I’ve not had a chance to review the cumulative patches, so I can’t vouch for them yet.)

[Update 2009-08-11]

I forgot to update earlier; the cumulative patches (7.5.1.2 in the case of what I received) did properly incorporate the patch for this issue.

 Posted by Preston de Guise at 05:24  Tagged with: , , , ,

Ready for {reading|writing}, idle

 NetWorker  No Responses »
Apr 232009
 

Sometimes NetWorker adminsitrators find themselves gnashing their teeth over the following device/media status messages:

  • ready for reading, idle

or

  • ready for writing, idle

Now, we often see these messages briefly during normal backup, cloning, recovery or staging operations. Where the teeth gnashing tends to start is when a device/volume sits in that state for an extended period of time.

The problem I find is that when a device/volume appears to be wedged in this state people start looking at the wrong things. 99.9999% of the time this message does not indicate there’s an issue with the device or volume that is “ready/idle”, but there’s an issue elsewhere.

This message means: “the device is ready, and waiting, but currently inactive”. So you have to ask yourself when a device/volume is wedged in this position – what is it waiting for? This is why the answer isn’t to investigate that device or volume, but to look at other activity.

Consider the following examples:

  • In a disk to tape cloning operation, a disk backup unit may be reported as “ready for reading, idle”. Chances are NetWorker is waiting for something to clone to. So check to see why media isn’t being made available for writing.
  • In a tape to tape cloning operation, a tape device unit may be reported as “ready for writing, idle”. So that means that it’s waiting for something to read from – maybe something is preventing the mount of the read volume? Or maybe the read volume is being read from for something else? (E.g., a recovery).

In very, very few cases the ready/idle state is the default of the device that’s in the idle state, but my recommendation is that if you’ve got a device wedged in this state, you need to look elsewhere to see why NetWorker isn’t able to send data to, or retrieve data from the device/volume.

 Posted by Preston de Guise at 18:02  Tagged with: ,

Why interfaces must be beautiful as well as functional

 Aside  No Responses »
Apr 222009
 

It’s been a long time since I’ve read such a thoughtful and simple argument for beautiful interface design, rather than simply aiming for functional interface design.

I thoroughly recommend that if you work with designing software or hardware interfaces, you need to read this article at A List Apart.

 Posted by Preston de Guise at 12:32  Tagged with: ,

Recovering with scanner and uasm

 NetWorker  2 Responses »
Apr 222009
 

There are some types of recoveries that fall into the “last ditch effort” category – everything else has been tried, but the data just won’t come back. I would have to say that in 99.99% of cases this is due to one of the following two things:

  1. The data was never properly backed up in the first place.
  2. Cloning wasn’t done, and the only piece of media that holds a particular backup is broken.

Assuming the data was actually backed up, as a last thing to try*, you can recover filesystem data using scanner and uasm. This is documented in the man page for scanner – and also available as a PDF to Windows administrators in the command reference guide.

As per the man page, the way of running scanner and uasm to facilitate a recovery is as follows:

# scanner -S ssid device | uasm -r -v -m /source=/dest

or, if you prefer to avoid using the pipe,

# scanner -S ssid device -x uasm -r -v -m /source=/dest

Where in each of those commands:

  • ssid is the saveset ID you want to recover from
  • device is the path to the device where the volume holding that saveset can be accessed
  • /source is the source path you’re recovering that you want to replace with:
  • /dest is the replacement to the source path

Out of these, probably the “/source” and “/dest” makes the least sense, until you see an example.

Say for instance you have a backup of “/home” that you want to recover this way. Chances are, you don’t want to recover it on top of an existing /home; thus, you’d use “-m /home=/tmp/recovery”, or something like that. This instructs uasm to replace the “/home” path in the incoming data stream with “/tmp/recovery” when writing the data back out.

However, it’s not just a saveset ID argument that scanner takes in this mode; in fact, you can pass through most arguments in relation to restricting what is scanned – that is, clients, saveset names, and even file/record numbers.

If you’re dealing with potentially damaged media, the file/record numbers can sometimes be your saving grace. Say you’re doing a recovery and mid-way through the recovery NetWorker aborts saying there’s an error at file number 33 on the tape. At this point, you should at this point have a clone. Honestly, you really, really should have a clone.

Assuming though that for some reason you don’t have a clone, there’s a good chance your data is hosed** – recover, nwrecover, winworkr are not going to get you past that point.

Scanner might. There’s no guarantee, but it might. If the media error is limited to just a single portion of the tape, you may find that you can run a scanner/uasm combination that starts at the next file marker and hope that it gets your data back. Assuming we’re needing to get /home back for the client ‘baal’ on /dev/nst0***, this would make the command

# scanner -c baal -N /home -f 34 /dev/nst0 | uasm -r -v -m /home=/tmp/recovery

If you need to get even more data back, you could even use a starting record number. Say the recovery failed at file number 33, media record 1138; you might try the following:

# scanner -c baal -N /home -f 33 -r 1139 /dev/nst0 | uasm -r -v -m /home=/tmp/recovery

However, in each case, remember that the extent to which scanner and uasm will be able to recover your data will be limited to the amount of physical damage on the tape.

As I mentioned before, there’s no guarantees scanner is going to … ahem, save your bacon … if things have reached this point – but, what is there to lose by trying?

–
* This is also a valid technique where you have a decommissioned server and you just need to urgently pull back a few files without doing a full rebuild.

** And it’s not NetWorker’s fault of media or devices go bad, and it’s the only copy of the data!

*** If you’re needing to do this because of a media failure, make sure you use a different tape drive for your “last attempt”, just in case it was the tape drive that caused the failure.

 Posted by Preston de Guise at 07:26  Tagged with: , , , , ,

Basics – nsraddadmin

 Basics, NetWorker  No Responses »
Apr 202009
 

A simple and straight-forward command, nsraddadmin answers that problem of needing to quickly add a user account as a NetWorker administration without having to fire up either NMC or nsradmin.

The command only takes a single argument sequence:

# nsraddadmin -u entry

Where ‘entry’ is a valid NetWorker user entry, i.e., one of:

  • user@host

or

  • user=name,host=name

For example, on the NetWorker server as a current administrator, if you wanted to add “preston” on the machine “faero” as an administrator, you’d simply run:

# nsraddadmin -u "user=preston,host=faero"

or, using the old format:

# nsraddadmin -u preston@faero
 Posted by Preston de Guise at 17:41  Tagged with: ,
 Older Entries
© 2012 The NetWorker Blog Suffusion theme by Sayontan Sinha