snmdla-tm's Posts

snmdla-tm's Posts

I believe that /etc/vfstab is SVR4 specific, and is rarely used outside of Solaris. Why did EMC choose to implement the btrfs backup configuration in such a highly non portable location?
Wallace, that's good news, and very interesting! I still have some questions needing clarifiction: From the release notes of Networker 8.2.4: Linux BTRFS file system support NetW... See more...
Wallace, that's good news, and very interesting! I still have some questions needing clarifiction: From the release notes of Networker 8.2.4: Linux BTRFS file system support NetWorker 8.2.4 supports backups of B-tree file systems (BTRFS). When a server-initiated backup starts, only BTRFS sub-volumes that are configured in the /etc/vfstab file are backed up. When NetWorker encounters a subdirectory that has a sub-volume ID that differs from the parent sub-volume ID, NetWorker does not back up the contents of the subdirectory, unless you specify the save -x command in the Backup command field in the properties of the Client resource. When you specify a BTRFS volume or sub-volume save set during a manual backup, NetWorker performs a recursive back up of the directory tree that you specified with the save command. When NetWorker encounters a subdirectory that has a subvolume ID that differs from the parent sub-volume ID, NetWorker does not back up the contents of the subdirectory, unless you specify the -x option with the save command. BTRFS is not supported with the following features: - Block based backup - NetWorker snapshot management I assume that this new feature will also require that client and server be on at lease 8.2.4? The concept of /etc/vfstab is not known in SLES 12, as far as I know. How will the client behave on platforms without /etc/vfstab support? As I see that my current 8.2.3 client does (dumb?) backups of btrfs subvolumes (like var/log in SLES 12), to my understanding, moving to a current 8.2.4 client bears the risk that there will be less or no backup of btrfs subvolumes in the absense of a proper configuration (or /etc/vfstab support on platforms like SLES): quite dangerous, agree? Kind regards, Thomas
Wallace, thanks! Do you know if there is a chance that btfrs support might be backported to a Networker 8 version. Moving to 9 is quite a challange ...
As Networker 9.1 has been released, I wonder whether btrfs support has somehow made it into the new features. Could not find anything about it. Does somebody know more?
In our case it is SLES 11 SP3. I get the error even when all networker services on storage node are down.
Hrvoje, sjirdtag will report SJIRTAG: Input/output error 1640:sjirdtag: Code:0x29, Str=<Illegal Request, Invalid Command Operation Code> So that's why I guessed we lack the SJI sup... See more...
Hrvoje, sjirdtag will report SJIRTAG: Input/output error 1640:sjirdtag: Code:0x29, Str=<Illegal Request, Invalid Command Operation Code> So that's why I guessed we lack the SJI support. Regards, Thomas
A full inventory will do what we expect, and will correctly recognize the tapes. I will run a very long time. I'm afraid that we do not run SJI compliant jukeboxes. Kind regards, Thomas
No, I don't think that our issue is related to savesets changing to E (expired), it is an issue about the media database.
EMC support recommends to do a full inventory in such a situation!
Bingo, when I do the "p" in nsradmin, I get "" for all troublesome volumes. The output of mminfo is also very confusing, e.g. nsrhost:~ # mminfo -q "barcode=XY0336L3" -r "volume,ba... See more...
Bingo, when I do the "p" in nsradmin, I get "" for all troublesome volumes. The output of mminfo is also very confusing, e.g. nsrhost:~ # mminfo -q "barcode=XY0336L3" -r "volume,barcode" 6095:mminfo: no matches found for the query nsrhost:~ # mminfo -q "volume=XY0336L3" -r "volume,barcode" volume        barcode XY0336L3      XY0336L3 nsrhost:~ # Kind regards, Tom
Hrvoje, thanks for replying. It's not really about moving around tapes in the jukebox, it's mainly about putting fresh tapes into it. "nsrjb -HvE" did not help, sorry. Kind r... See more...
Hrvoje, thanks for replying. It's not really about moving around tapes in the jukebox, it's mainly about putting fresh tapes into it. "nsrjb -HvE" did not help, sorry. Kind regards, Thomas
After updating to version 8.2.3.3 of Networker, fast inventory on our jukeboxes (nsrjb -II ...) will only perform a fast inventory on tapes that have not changed position, and will report an erro... See more...
After updating to version 8.2.3.3 of Networker, fast inventory on our jukeboxes (nsrjb -II ...) will only perform a fast inventory on tapes that have not changed position, and will report an error for all tapes that have been changed, e.g. 09/12/16 09:20:30.866477 Info: The media data base has no volume with barcode = `XY0247L6'. 09/12/16 09:20:30.866501 Info: Fast Inventory cannot identify volume in slot `23'. ... 09/12/16 09:20:30.867000 Error: Fast Inventory fail to identify some or all of the selected slots. The message "The media data base has no volume with barcode ..." is definitely wrong, as there always is a volume with that barcode in the media database. For these tapes / slots we then have to perform a slow inventory. EMC support mainaints that we should be fine with that, but I disagree, and we do not want to spend hours for inventorying large jukeboxes I suspect the change in the ressources database to SQLite might play a role in this: "In NetWorker 8.2 SP3, SQLite replaces WiSS as the media database." Did anybody see similar effects? Who could offer a solution? Kind regards, Tom
Thanks a lot for that tip! I looked at so many columns of mminfo, but did not realize that sumflags would have answered the question about the saveset completeness. Thanks and regards, Tom
So it happened, that we accidentally deleted a tape, with file and media index. Consequently we re-read the tape with the scanner command (scanner -s nsrhost  -m -p -z -v ...). What confuse... See more...
So it happened, that we accidentally deleted a tape, with file and media index. Consequently we re-read the tape with the scanner command (scanner -s nsrhost  -m -p -z -v ...). What confused us a lot was the fact, that not all of the SSIDs that re-appeared in the media index were recoverable (or cloneable in our case): An attemt to clone only reported    ...    5767:nsrclone: NSR server <ourserver>: busy    5766:nsrclone: waiting 30 seconds then retrying    ... And at the server, we got the alert       Tue 12:16:09 PM media waiting: Waiting for 1 writable volume(s) to       backup pool '<ourpool>' disk(s) or tape(s) on <ourstoragenode> After a lot of researching we finally came to the insight that we needed to also scan the "neighbouring" tapes, so that Networker got the complete picture of savesets that span multiple tapes. The overwhelming output of the scanner command run on the tape that was accidentally deleted, had a hint:    ...    scanner: CONT NOTE ssid 4236283626, off 518781797512, flags 0x10103, info 1740881526    scanner: ssid 4236283626: continued from `<oulabel>', scan for synchronization    ... The flags that the Saveset 4236283626 showed via mminfo were vF (for "valid" and "finished (ended)") had given us no notion of the fact that the SSID was continued: we would have expected an additional "C". What is your opinion: is this a bug? In any case, the man-page of the scanner command should contain a tip, that there often will be continuation save sets           that might need a re-scan with scanner, too. Kind regards, Tom
Just heard that BTRFS support is being worked on for upcoming feature release 9.1. As version 9 is so much different from version 8.x, I would still appreciate BTRFS support in V8.2.x for exam... See more...
Just heard that BTRFS support is being worked on for upcoming feature release 9.1. As version 9 is so much different from version 8.x, I would still appreciate BTRFS support in V8.2.x for example. Kind regards, Tom
Apparently, Networker actually does backups of mounted BTRFS file systems, but I would like to see BTRFS explicitely mentioned where ext3, xfs etc are mentioned, and I cannot say if the current b... See more...
Apparently, Networker actually does backups of mounted BTRFS file systems, but I would like to see BTRFS explicitely mentioned where ext3, xfs etc are mentioned, and I cannot say if the current backups are sufficient: I see that some pathes visible in subdirs of /var/lib/docker (with docker setup to use BTRFS) are not backed up, and cannot explain why With no explicit support from EMC, I doubt that the backup and restore of extended file attributes or poxix ACLs is being tested by EMC Furthermore, Networker client would have to implement some deeper understanding of  BTRFS internals, as it would need to avoid the backup of each mounted snapshot pointing to identical BTRFS leaves. The article about HP data protector has details about this issue We will be submitting an enhancement request to implement full BTRFS support in Legato Networker ASAP, and anybody that also needs it is welcome to submit such an enhancement request, too. Kind regards, Tom
in the Networker 8.2 Admin Guide we read:    Linux Journaled file system support    Backup and recovery operations are supported on the following Linux    journaled file systems:    - e... See more...
in the Networker 8.2 Admin Guide we read:    Linux Journaled file system support    Backup and recovery operations are supported on the following Linux    journaled file systems:    - ext3    - reiserfs    - jfs    - xfs No statement about support of BTRFS. I fear that the networker client cannot handle btrfs filesystem. SuSE Enterprise Linux (SLES) 12 comes with the installation default of BTRFS for the OS, and docker can profit a lot from BTRFS based installations. Networker client should really provide BTRFS support very soon! You are welcome to voice affirmation Regards, Tom
Thanks for the details outlining the mechanisms. Our issue is the following: the Media alerts go out to a IT team inbox, where the admin on duty needs to take action ... when there is need for... See more...
Thanks for the details outlining the mechanisms. Our issue is the following: the Media alerts go out to a IT team inbox, where the admin on duty needs to take action ... when there is need for action. Thus, tape alerts that get resolved over night are nuisance alerts: the admin on duty will start NMC and have a look, only to see that everything is OK. If I understand the explanations correctly, rising the value of target sessions could alleviate the issue, but this will probably have other implications, as more sessions are multiplexed to tape, potentially raising recovery duration. I consider switching off the mail alert, and polling the NMC for open alerts with a monitoring tool like Nagios. Would this be possible? Regards, Thomas
Hrvoje, the situation with the new library is similar to the situation before: there is always on drive available. We did some modifications to the device parallelism, but an increased parall... See more...
Hrvoje, the situation with the new library is similar to the situation before: there is always on drive available. We did some modifications to the device parallelism, but an increased parallelism should not lead to more tape alerts, I guess. The logs say nothing about the cause of the tape alert. Is it possible to adjust the logging to learn more about that? Thanks, Thomas
certainly, I understood, but here only a single tape drive is enabled at all, there should be no confusion about several ones.