Unsolved

This post is more than 5 years old

4 Posts

1136

January 3rd, 2012 05:00

NetWorker with FalconStor HyperTrac

Hi all,

by using FalconStor HyperTrac, it is possible to create snapshots on a FalconStor SAN environment and connect these snapshots to a specific (in our case) NetWorker Server.

The NW Server then gets a new mounted volume (also possible to use a mountpoint) which then is configured for backup (a specific mountfolder or drive letter as saveset).

By usinge savepnpc (pre = mounting the snapshot to the backup server, post = unmounting the snapshot) we use the server to backup the data directly to VTL.

But using the server directly seems to have some disadvantages:

- the configured client is the backup server itself with a specific saveset (disk or folder if a mountpoint is used)
This also means that every backup also has an index and bootstrap backup.

- we notice that when we want to restore, we don't see all of the disks or mountpoints. We also need to change the browse time (date and especially the time) that NetWorker knows that a specific saveset was backupped.

Has anybody already seen such behaviour?
What would you propose to make this better? Using a storage node is out of the question.

We are thinking about using a specific client (virtual one) which we can also use as a proxy client.

Regards and thanks for any help.


Steven

736 Posts

January 4th, 2012 02:00

Hi Steven,

You can prevent the index being backed up if you wish by setting 'no index save' at the group level. Not seeing the mountpoints when you want to recover would seem llike a more serious problem however.  You'd need to look into which mountpoints you see and which you don't to try to identify what the problem is.  You can change the browse time manually using the nsrmm command (and put that in your script if you wish) but I'm not sure why you would want to do that.  Can't you just set the browse time normally in NetWorker?   You could mount them onto a client and backup the client and this would prevent the bootstrap being backed up (providing the server client instance is in another active group). 

-Bobby

4 Posts

January 4th, 2012 07:00

I needed to recover some files from Septembe and in the mails I could see when they were backupped.

We did manage to recover them with the saveset restore but for 50MB of data, NetWorker needed to read 2 complete virtual tapes so a browsable recovery would be much better.

The browse time period for the monthly backups (which is the one I needed for this restore) was 6 months so I should be able to browse it normally.
I am under the impression that saving such a number of volumes with the NetWorker Server also results in backupping the bootstrap the same number of times

Would this be any different by only prevent the index backup every time?

I am already happy that I could restore it but it took too mucht time.


Regards

Steven

6 Operator

 • 

14.4K Posts

 • 

56.2K Points

January 10th, 2012 08:00

sald wrote:

The NW Server then gets a new mounted volume (also possible to use a mountpoint) which then is configured for backup (a specific mountfolder or drive letter as saveset).

By usinge savepnpc (pre = mounting the snapshot to the backup server, post = unmounting the snapshot) we use the server to backup the data directly to VTL.

But using the server directly seems to have some disadvantages:

- the configured client is the backup server itself with a specific saveset (disk or folder if a mountpoint is used)
This also means that every backup also has an index and bootstrap backup.

- we notice that when we want to restore, we don't see all of the disks or mountpoints. We also need to change the browse time (date and especially the time) that NetWorker knows that a specific saveset was backupped.

You can use -c to force backup to be registered under client index you wish.  While I never tried this from backup server (only storage nodes), I believe same rule should apply here too.  No index save won't help on groups with backup server inside so I would rather do this through script.  Script would be:

- mount mnt (your pre part)

- save -c /mnt

- umount mnt (your post part)

You can combine multiple mnt points / snapshots in this of course.  This method also does not trigger index and bootstrap backup and index is happily updated.

As for disks being visible, I have seen that only when using directives with skip.  Then you have usually all saveset for client with skip directive for mnts and additional mnt backups later on.  Trick is to change browsetime to correct value to see each of them individually.  By using save -c approach above I believe you would also address that problem.

0 events found

No Events found!

Top