NetWorker Blog

Commentary from a long term NetWorker consultant and Backup Theorist

  • This blog has moved!

    This blog has now moved to nsrd.info/blog. Please jump across to the new site for the latest articles (and all old archived articles).
  •  


     


     

  • Enterprise Systems Backup and Recovery

    If you find this blog interesting, and either have an interest in or work in data protection/backup and recovery environments, you should check out my book, Enterprise Systems Backup and Recovery: A Corporate Insurance Policy. Designed for system administrators and managers alike, it focuses on features, policies, procedures and the human element to ensuring that your company has a suitable and working backup system rather than just a bunch of copies made by unrelated software, hardware and processes.
  • Advertisements
  • This blog has moved!

    This blog has now moved to nsrd.info/blog. Please jump across to the new site for the latest articles (and all old archived articles).
  •  


     


     

  • Twitter

    Error: Twitter did not respond. Please wait a few minutes and refresh this page.

Archive for the ‘Support’ Category

Don’t resent your log files!

Posted by Preston on 2009-10-21

There was a recent discussion on the NetWorker mailing list as to whether some additional logging information that appeared in 7.4.x was worthwhile or whether it was worthless to the point of getting in the way of an administrator.

So that everyone is across what I’m talking about, the messages that started in 7.4.x are along the lines of:

nsrim: Only one browsable Full exists for saveset X. Its browse period is equal to retention period.

So here’s my take on the discussion: log files aren’t to be resented.

I recognise there’s a point where log files become either useless or waste people’s time. However, there’s really only one time for this – when the exact same information is needlessly repeated. In the case of these log messages though, it’s not the exact same information needlessly repeated. It’s different information – it’s going to be about a different saveset each time.

What is the message about, you may be wondering? Well, I actually don’t 100% know for sure. My suspicion is that it’s a message introduced to deal with processing saveset retention following changes introduced for pool based retention policies. But it doesn’t matter.

One thing that will drive me nuts with just about any product is encountering an issue where there’s insufficient logs to actually work out what is going on. Obviously, there’s a fine line to walk – log too much and you waste space and potentially reveal too much about the IP of the package. However, don’t do enough and it becomes extremely challenging for the people doing support (or the people who write the patches (or the people who wrote the software)) to resolve an issue. I don’t believe that having accurate logs guarantees quickly resolving an issue, but they certainly help – and not having them certainly hinders.

So my point is – don’t resent your log files. The amount of space they generally take up in NetWorker is quite minimal (compared to say, the index region), and so you shouldn’t be concerned about space. Nor, I’ll insist, should you be concerned about how to go about stripping out messages you don’t need to review when scanning log files. Backup administrators of enterprise products in particular should be quite conversant with log analysis and text extraction.

If those extra logged entries allow me to quickly find something in a Knowledge Base, or similarly allows support to find something quickly in an engineering database, or allows a patch developer to isolate the section of code that causes the problem, or allows the core developer to target the section of code to write an enhancement, it’s fantastic, and well worth the extra few bytes here and there that occupy my filesystems.

Advertisements

Posted in Backup theory, Support | Tagged: , | Comments Off on Don’t resent your log files!

A cautionary tale about changing pools

Posted by Preston on 2009-10-08

Sometimes I feel like a NetWorker old-timer. (When I don’t feel like a NetWorker old-timer, it doesn’t change the fact that I am.) These days, given the huge architectural gulf between them, I’d suggest that anyone who has been using NetWorker since v4.x or v5.x days is a NetWorker “old timer”. Since I’ve been using it with a trailing edge of v3.x days and heavily from v4.x, that puts me well into that territory.

One of the things NetWorker old timers will remember is that for a lot of its history, it was impossible to change anything to do with pools whenever a backup was running. If for instance, you had a backup going to a Monthly pool, and you wanted to configure a new group that would go to the Daily pool, you had to wait for all backups to complete, even though there was no overlap in pool interests, before you could add that group to the Daily pool.

When the restriction was first relaxed, the NetWorker GUIs would prompt with a warning when pool changes were being made during backup activities to indicate that it wasn’t recommended, but giving a proceed/OK button to force the change. These days, NetWorker is more permissive, but not always more forgiving.

A customer experienced a problem recently where he’d configured a new group, and started the group, only to realise that he’d not configured it to go to the correct pool. Rather than stopping the group and making the pool change, he hoped that he could change the pool settings and see the group start requesting media from the correct pool instead of the Default pool. Once the change was made though, the group kept on asking for media in the Default pool, so he stopped the group, waited a few minutes, and restarted.

NetWorker kept asking for media in the Default pool. The NMC pool configuration pane clearly showed that the group was now configured for the correct pool, but plain as day, the group wanted to still write to the Default pool.

Stopping and starting NetWorker didn’t seem to help either.

When he logged the case, and explained about the pool-change-during-backup, I immediately thought back to how NetWorker previously wouldn’t have allowed such a change to happen, and how it in an interim period used to allow the change to happen after issuing a warning. But what if, I thought, there’s still some locking that can happen which would cause a screw-up if the pool were changed for a group while the group was already requesting media?

So I suggested two courses of action to the customer:

  • EMC engineering’s hated solution: Stop NetWorker, clean out /nsr/tmp, restart, and see if that fixes it.
  • Stop the backup, take the group back out of the pool, restart and allow it to write to Default, then put the group back in the correct pool and run the backup again.

In this case, the customer chose the first option – cleaning out /nsr/tmp. While it wasn’t tested, I equally suspect that the second option would have worked too.

There is a lesson with this: avoid making changes to pools for data which is already actively trying to be written to media. Even though it’s technically supported, operationally it can still cause issues.

Posted in Features, NetWorker, Support | Tagged: , | Comments Off on A cautionary tale about changing pools

Gotchas for disparate versions of NMC and NetWorker

Posted by Preston on 2009-09-15

A few days ago a customer was having a rather odd problem. They’re currently running NetWorker 7.3.3 and getting ready to jump directly to NetWorker 7.5.1, but to do so they wanted to first run up a NetWorker 7.5.1 server and confirm current client types, databases, etc., will backup without issue*.

So the customer installed NetWorker 7.5.1 on a new Linux host, created some devices and pools, but then encountered a particularly odd problem when they went to create the clients. NMC would allow them to fill in all the properties for the client, but when they clicked OK in the new client dialog box, nothing would happen. No errors were produced, but nor were any clients actually created.

When they raised this with me I was a little puzzled for a few minutes, then asked if they were using the NMC that comes with NetWorker 7.5.1, or the NMC that comes with 7.3.3 and had just added the new server to the control zone.

The answer was that the control zone for the existing NMC that came with NetWorker 7.3.3 was just extended to include the 7.5.1 server.

For pools, devices and groups this was not a problem – these were all successfully created on the 7.5.1 server using the 7.3.3 NMC. However, when it came to clients, it wouldn’t work.

The reason is quite simple – as new features and functions are added to NetWorker over time, different fields within a configuration resource may or may not become mandatory. Some of the time this is obvious, because we’re required to fill in certain fields – e.g., client names, schedules, etc. However, in other instances, NetWorker has predefined defaults that it slots into place if a value isn’t entered – e.g., parallelism, priority, browse/retention time, etc. Just because defaults are put into place however doesn’t mean that fields are any less mandatory – it’s all about allowing you to create resources quicker.

So, what’s all this got to do with differing NMC/NSR versions? In short, everything!

You see, what happened for this customer is that between NetWorker 7.3 and 7.5, there has been a raft of client based functionality added – e.g., data deduplication, support for defining a client as being virtual, etc.

Undoubtedly some of these new features have mandatory values – so that if the server is probing details for the clients, it can safely request say, dedupe status or virtual status without worrying about getting an (undefined!) style response. Each version of NetWorker is “aware”, via base configuration, what fields must be supplied when creating a new resource, and thus, the scenario for this customer would have been:

  1. Fill in client properties in NMC 7.3.3
  2. Attempt “client create” 7.3.3 -> 7.5.1.
  3. The 7.5.1 server reviews the proposed client resource and,
  4. The 7.5.1 server rejects the proposed client resource as not having all the mandatory fields filled in.

Should NetWorker/NMC have provided an error to explain what was going wrong? Undoubtedly that would have been good, and I’d suggest that NMC/NSR should be able to better communicate resource creation/update failure in these circumstances. However, that being said, the fundamental problem remained the same – the version of NMC in use couldn’t create new clients because it wasn’t supplying all the mandatory details to the more recent version of NetWorker.

In many small sites, the NMC server and the NetWorker server are on the same host, and are thus upgraded in lock-step. However, for sites where the NMC server is installed on another host, this is a valuable lesson – unless you have a very valid reason, don’t run a version of NMC that matches an earlier version of NetWorker than the current server version. It may work (mostly), but if it does fail, it’s unlikely to be immediately obvious why it’s failing.


* This is what I’d call an excellent upgrade policy – you can read the release notes until they’re 100% memorised, but nothing quite beats actually running up your own test server.

Posted in NetWorker, Support | Tagged: , , , , , , , , | Comments Off on Gotchas for disparate versions of NMC and NetWorker

What does supported mean?

Posted by Preston on 2009-08-24

It’s easy to get confused on ‘supported’. That is, when EMC (or any other vendor) publishes a guide on say, what operating systems are supported, many will ask whether that means if some operating system X that does not appear in the list will work.

The terms ‘work’ and ‘supported’ are not synonymous, and should not be confused.

I’ll be the first to point out that I routinely use CentOS in my lab – a Linux distribution that is most definitely not on the supported operating systems list. It’s a repackaged RedHat Enterprise Server, and I can install it as many times as I want at zero cost. On the other hand, if I needed to actually buy a RedHat Enterprise Server license for every Linux test VM, I’d be very, very poor.

So clearly, CentOS works with NetWorker, even though it’s not supported.

Would I recommend it being used at a customer site in a full production environment? Not without rigorous caveats.

You see, backup is one of those fundamentally low-level scenarios where taking risks is just plain wrong. It’s like the difference between leading edge and bleeding edge. There’s nothing wrong with being leading edge in the backup environment; many companies depend on being leading edge so they can meet their backup and recovery windows. Bleeding edge though – going out and using untested or uncertified configurations, just asks for trouble. Indeed, the term says it all – bleeding.

There are typically two key reasons why something may ‘work’ but be ‘unsupported’. These are:

  • The vendor has not had a chance to test that particular configuration. I.e., it’s unqualified. For example, a Widgets Inc. Tape Library with LTO-5 drives and four robot heads may just not have made it to the vendor labs for qualification; so, while it may technically work, it’s never been tested.
  • The vendor is not comfortable with the supplier support for the product.

Now, in the case of a solution or a configuration option being unqualified, there’s a solution. EMC for instance will work with customers and partners to determine whether a particular configuration can be qualified – indeed, most vendors have a similar process. While everyone would undoubtedly prefer that they get all the qualification done in their labs, we must also accept that it’s practically impossible to achieve, so some level of on-site qualification must be accepted as required from time to time.

In the second instance though, things are a little more difficult. If a vendor isn’t comfortable that the supplier of a product will be able to suitably support that product at an enterprise level, then getting it qualified is unlikely at best.

In these instances, if you want to deploy unsupported components in your system, ask yourself these questions:

  1. Is there a supported option available?
  2. What are the pros and cons of the supported option vs the unsupported option?
  3. What is the risk to the business if the unsupported option has issues and the vendor refuses to support it?
  4. If the unsupported option is chosen, can a test lab be setup using the supported option so as to prove, at any point, that the use of the unsupported product does not contribute to an issue?

The last point may seem a little odd – after all, if you can afford the supported option for a lab, why wouldn’t you deploy in production? I’ve actually seen this scenario with CentOS – a company couldn’t afford RedHat Enterprise Server licenses for all their production machines, so they deployed CentOS, but they also did buy a RedHat Enterprise Server license for a lab machine. Whenever an issue occurred that required escalation to the vendor, they’d first reproduce it on the RedHat Enterprise Server. That way, when it went to the vendor, they could (rightly) claim an issue on a supported operating system.

Even so, this isn’t necessarily ideal. What was obviously not accounted for here was the potential for a high severity issue occurring. E.g., if a severity-1 fault occurred on a system, where data recovery was imperative, but recreating the configuration would take a long period of time, the risk remained that either (a) an escalation based on an unsupported operating system would be rejected or (b) the SLAs might be blown out of the water recreating the issue on a supported platform in order to get a successful escalation.

In short – the decision to use unsupported software/hardware is not the decision of IT staff. It must be the decision of senior management. It must be signed off, and stakeholders of affected systems and processes must be aware of the potential consequences.

While unsupported does not necessarily imply doesn’t work, it’s important to remember that unsupported can most definitely mean unsupported when it stops working.

Posted in NetWorker, Support | Tagged: , , | 2 Comments »

NetWorker 7.4.5

Posted by Preston on 2009-08-15

I received an automated alert from PowerLink overnight telling me that the release notes for NetWorker 7.4 had been updated. Having downloaded the updated release notes this morning, I can see that there’s information in there about an (as yet unreleased) NetWorker 7.4.5. This is not uncommon – sometimes the release notes for NetWorker in PowerLink has been known to be updated with details of new versions for up to 1-2 weeks before the downloads hit.

Obviously at this point I don’t have the opportunity to test out 7.4.5 given I’m not yet able to see it in downloads. I have to imagine though that it’s somewhat similar to 7.4.4.7, the last cumulative patch build that I received from EMC. There are around 3.5 pages worth of fixed bug notes in the release notes, which seems to mean that it not only includes all the cumulative patch updates, but a swag of other updates as well.

As per usual, it’s reassuring to see a bunch of bugs for which I’ve had patches delivered for my customers appearing in the fixed bug list – EMC is certainly making a lot of improvements in eliminating issues that repeatedly crop up in successive versions!

I’ll do a new posting once I’ve had a chance to download and test out 7.4.5, but certainly on the basis of the fixed bug lists (and the very minimal “known issues and limitations” list), this may be a promising update to the 7.4 tree.

[Edit – later the same day…]

NetWorker 7.4.5 has now appeared in PowerLink for downloads. I’m going to kick off a few key platform downloads today and start testing over the coming 48 hours.

Posted in NetWorker, Support | Tagged: , | Comments Off on NetWorker 7.4.5

NetWorker 7.4.4.7 is out

Posted by Preston on 2009-08-03

Cumulative patch cluster 7.4.4.7 of NetWorker was released on the weekend. There’s a whole raft of fixes in this. On a personal front, I’m pleased to see the inclusion of LGTsc24186 in this build. I’ve been working with EMC for quite some time for several customers over that particular issue, and while I’ve had some patches for it for a while, seeing it included in a cumulative release always makes me feel more confident that said patches will make it into core code. (LGTsc24186 deals with periodic/random failure of cloning operations with “authentication type 0 not adequate” logged for the failure.)

If you’re encountering odd problems with 7.4.4, you may want to chat to your support provider to see whether 7.4.4.7 will make life easier.

Posted in NetWorker, Support | Tagged: , | Comments Off on NetWorker 7.4.4.7 is out

Debugging autochanger operations

Posted by Preston on 2009-06-01

Having a strong support background, and having a preference for working in software rather than hardware, when I use NetWorker’s nsrjb utility with tape libraries I like to get as much feedback as possible on operations.

When performing command line operations with nsrjb, this is relatively straight forward – just add on a few “-v” options to the operation. Indeed, my customers sometimes probably tire of hearing me start every nsrjb command with:

# nsrjb -vvv

It’s become such a force of habit that I literally don’t consider running it without those three verbose flags any more*. If you’re not sure why you would do this, or have never run nsrjb with verbose flags, you should go and do it – you get a lot more information about the progress of the operation, which can actually be very important if you’re debugging or otherwise trying to resolve hanging hardware operations.

Being able to run nsrjb in verbose mode is all well and good, but it doesn’t help you diagnose periodic or random failures if they’re only happening during backup operations. To keep track of progress on these, you need to use a setting within the jukebox resource – the debug trace level option.

This updates the daemon.raw log file with extra details about autochanger operations, in a similar way to the additional details you get when you run nsrjb with additional verbosity flags. It can be set to a number, and like the debug option for a lot of NetWorker commands, defaults to 0 (for no additional information), and can be set to ever larger numbers that generate a lot of extra information. It doesn’t generate the same information as running nsrjb with multiple “-v” flags, but it still helps.

Now, before I go further, I’d suggest that this is probably something you shouldn’t leave enabled all the time. That is, if you’re having an intermittent problem with a tape library, consider turning this on so that you have the option of reviewing log files from overnight backups to see if there’s any relevant/helpful information from the time of failures. However, when you finish your debugging, turn it back off by setting it to zero.

There’s two ways you can set it – either from the command line, using nsradmin, or from NetWorker Management Console when viewing a jukebox resource with “diagnostic” details turned on.

Let’s look at nsradmin first:

# nsradmin -s nox
NetWorker administration program.
Use the "help" command for help, "visual" for full-screen mode.
nsradmin> show name:; debug trace level:
nsradmin> print type: NSR jukebox
                        name: LTO1_LIB;
           debug trace level: 0;
nsradmin> update debug trace level: 9
           debug trace level: 9;
Update? y
updated resource id 31.0.255.110.0.0.0.0.60.6.146.73.0.0.0.0.10.0.0.1(5348)
nsradmin> print
                        name: LTO1_LIB;
           debug trace level: 9;

It’s as simple as that!

If you want to see it from within NMC, you’d make the changes in the “Debug Trace Level” field, as per the screen-shot below:

Advanced tab of Autochanger properties

Advanced tab of Autochanger properties

(The debug trace level setting is the bottom-most option on the left-hand side of this tab.)

You’ll find that debug level of 9 will more than likely be more than enough for any regular fault finding exercise, as the amount of information produced by this is quite high. For instance, at the bottom of this post I’ve got output from a single operation, “nsrjb -lvvv -S 1” to the volume in slot one into a drive.

Remember when you’re done of course to turn the trace level back off by setting the debug trace level to zero.

nox nsrlcpd getenv_ulong(NSR_LCPD_BASEELEMOFFSET=0,0:65535, 0) returning 0
nox nsrlcpd getenv_ulong(NSR_LCPD_NO_LOAD_EXP=0,0:1, 0) returning 0
nox nsrlcpd getenv_ulong(NSR_LCPD_NOVUELMASC=0,0:1, 0) returning 0
nox nsrlcpd getenv_ulong(NSR_LCPD_AUTOEJECT=0,0:1, 0) returning 0
nox nsrlcpd getenv_ulong(NSR_LCPD_AUTOEXT=0,0:1, 0) returning 0
nox nsrlcpd getenv_ulong(NSR_LCPD_AUTOEXT2=0,0:1, 0) returning 0
nox nsrlcpd getenv_ulong(NSR_LCPD_RES_DRVACCESS=0,0:1, 0) returning 0
nox nsrlcpd Event LE_CONTINUE raised for cmdid 16055
nox nsrlcpd Processing: cmdid 16055 & cmdop 12 for event: LE_CONTINUE
nox nsrlcpd Event LE_COMP_OK raised for cmdid 16055
nox nsrlcpd Responder woke up due to event
nox nsrlcpd LCPD_HDR: server:nox.anywebdb.com vers:1 jbid:LTO1_LIB cmdid:16055 is_master=yes cmdop:UPDATE.
nox nsrlcpd \ncomplete :no
nox nsrlcpd \n
nox nsrmmgd Loading volume `Clone.001' from slot `1' into device `/dev/nst0'.
nox nsrlcpd LCPD_HDR: server:nox.anywebdb.com vers:1 jbid:LTO1_LIB cmdid:16056 is_master=no cmdop:LOAD.
nox nsrlcpd     MOVE MEDIA INFO
nox nsrlcpd         source : S:000031
nox nsrlcpd         source attrlist : NULL
nox nsrlcpd         dest   : D:000001
nox nsrlcpd Event LE_NEWCMD raised for cmdid 16056
nox nsrlcpd Processing: cmdid 16056 & cmdop 4 for event: LE_NEWCMD
Unable to render the following message: freeing unused errinfo with msgid 14947

nox nsrlcpd Event LE_CONTINUE raised for cmdid 16056
nox nsrlcpd Processing: cmdid 16056 & cmdop 4 for event: LE_CONTINUE
nox nsrlcpd lg_lstat(): Calling lstat64().
nox nsrlcpd lg_open(): Calling open64().
nox nsrlcpd lcpd_last_status_set: OK->OK (requested OK).
nox nsrlcpd Event LE_CONTINUE raised for cmdid 16056
nox nsrlcpd Processing: cmdid 16056 & cmdop 4 for event: LE_CONTINUE
nox nsrlcpd lg_lstat(): Calling lstat64().
nox nsrlcpd lg_open(): Calling open64().
nox nsrlcpd LCPD_HDR: server:nox.anywebdb.com vers:1 jbid:LTO1_LIB cmdid:16057 is_master=no cmdop:STATUS.
nox nsrlcpd Responder woke up due to event
nox nsrlcpd LCPD_HDR: server:nox.anywebdb.com vers:1 jbid:LTO1_LIB cmdid:16057 is_master=yes cmdop:STATUS.
nox nsrlcpd pid:7606 lcp_rpc_vers:1, jb_list_len:1
nox nsrlcpd \n
nox nsrlcpd lcpd_last_status_set: OK->OK (requested OK).
Unable to render the following message: freeing unused errinfo with msgid 14947

nox nsrlcpd Event LE_CONTINUE raised for cmdid 16056
nox nsrlcpd Processing: cmdid 16056 & cmdop 4 for event: LE_CONTINUE
nox nsrlcpd Event LE_COMP_OK raised for cmdid 16056
nox nsrlcpd Responder woke up due to event
nox nsrlcpd LCPD_HDR: server:nox.anywebdb.com vers:1 jbid:LTO1_LIB cmdid:16056 is_master=yes cmdop:LOAD.
nox nsrlcpd \ncomplete :no
nox nsrlcpd offset:0    tag:S:000031    ok:yes full: no barcode:       ? dest:D:000001 bay:?
nox nsrlcpd \n
nox nsrlcpd offset:0      tag:D:000001    ok:yes full:yes barcode:       ? source:S:000031 serial#:? bay:?
nox nsrlcpd \n
nox nsrd /dev/nst0 Verify label operation in progress
nox nsrd /dev/nst0 Mount operation in progress
nox nsrlcpd LCPD_HDR: server:nox.anywebdb.com vers:1 jbid:LTO1_LIB cmdid:16058 is_master=no cmdop:STATUS.
nox nsrlcpd Responder woke up due to event
nox nsrlcpd LCPD_HDR: server:nox.anywebdb.com vers:1 jbid:LTO1_LIB cmdid:16058 is_master=yes cmdop:STATUS.
nox nsrlcpd pid:7606 lcp_rpc_vers:1, jb_list_len:1
nox nsrlcpd \n
nox nsrd [Jukebox `LTO1_LIB', operation # 30]. Finished with status: succeeded
nox nsrlcpd Processing: cmdid 4294967295 & cmdop 17 for event: LE_NEWCMD
nox nsrlcpd Event ? raised for cmdid 4294967295
nox nsrlcpd Processing: cmdid 4294967295 & cmdop 17 for event: ?
nox nsrlcpd lg_lstat(): Calling lstat64().
nox nsrlcpd lg_open(): Calling open64().
nox nsrlcpd lcpd_last_status_set: OK->OK (requested OK).
nox nsrlcpd Polling current hw status jukebox:LTO1_LIB status:OK
nox nsrlcpd Event ? raised for cmdid 4294967295
nox nsrlcpd Processing: cmdid 4294967295 & cmdop 17 for event: ?
nox nsrlcpd Event LE_COMP_OK raised for cmdid 4294967295


* With the one exception being when it’s used in scripting.

debug trace level option.

Posted in NetWorker, Support | Tagged: , , , | Comments Off on Debugging autochanger operations

Determining your NetWorker binary build details

Posted by Preston on 2009-05-10

Occasionally, depending on the issue you are having, EMC support or EMC engineering may request that you provide your NetWorker binary build details. This isn’t necessarily the same as the version information, since patches will obviously have different build details.

Usually they just say something along the lines of “can you run what filename and return the output?” or something along those lines. Well, what isn’t always a useful command depending on the Unix environment you’re on, and I’m even seeing some sites where it’s not installed (e.g., Solaris platforms where the /usr/ccs area doesn’t exist).

So, it’s handy to know how to retrieve this information without the benefit of what. It’s actually easy. For Unix, all you need to do is:

# strings /path/to/file | grep '@('

For example, if I wanted to know the build details for /usr/sbin/save on my laptop, I’d run:

[Sun May 10 07:12:30]
preston@archon ~ 
$ strings /usr/sbin/save | grep '@('
@(#) Product:      NetWorker
@(#) Release:      7.5.1.Build.269
@(#) Build number: 269
@(#) Build date:   Fri Mar 20 23:05:02 PDT 2009
@(#) Build arch.:  darwin
@(#) Build info:   DBG=0,OPT=-O2 -fno-strict-aliasing

This is all the information that support/engineering are going to be after when they’re wanting the build number of a binary, so knowing how to use strings and grep to retrieve it gives you a solution that will work on every Unix platform.

On Windows, you can readily find the build information by right-clicking the binary, choosing Properties, and then going to the “Version” tab. You’ll get something like the following:

NetWorker build details on Windows

NetWorker build details on Windows

You can see in the above screenshot that the first three information sections are “Build Date”, “Build Info” and “Build Number” – clicking on each of those will give you the information you need to provide.

Posted in NetWorker, Support | Tagged: , , , , | Comments Off on Determining your NetWorker binary build details

Screen shots don’t constitute logs

Posted by Preston on 2009-04-29

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 in NetWorker, Support | Comments Off on Screen shots don’t constitute logs