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.
  • 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.

Recovering with scanner and uasm

Posted by Preston on 2009-04-22

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.

Advertisements

One Response to “Recovering with scanner and uasm”

  1. […] a regular filesystem backup as a last resort this still would not be impossible to recover from – using scanner and uasm you can still suck the data off the tape(s) without NetWorker needing both in the media database. […]

Sorry, the comment form is closed at this time.

 
%d bloggers like this: