This product needs massive changes

Last post 10-19-2011, 12:28 PM by syrob. 10 replies.
Sort Posts: Previous Next
  • This product needs massive changes
    Posted: 05-26-2011, 11:31 AM

    Simpana 9 is not very well put together. Documentaion is horriable at best. say it with me... centralized Database for CV...if job results are kept on a commcell.. why the heck does each client have its own set of jobresults? Also logging.... really... we are going to enable logging by default when the agent gets installed.... so your saying... our software will fail... which is why we have log files being generated.... come on folks.... Symantec is going to wipe the floor with you all if you dont make some adjustments..

  • Re: This product needs massive changes
    Posted: 05-26-2011, 12:01 PM

    GATORFAN:

    Simpana 9 is not very well put together. Documentaion is horriable at best. say it with me... centralized Database for CV...if job results are kept on a commcell.. why the heck does each client have its own set of jobresults? Also logging.... really... we are going to enable logging by default when the agent gets installed.... so your saying... our software will fail... which is why we have log files being generated.... come on folks.... Symantec is going to wipe the floor with you all if you dont make some adjustments..

    The job results on the CS is not an accomulation of all the job results on each client, so each local job results is necessary to produce file lists, accurate failure tracking, ect. 

    To say logging being enabled is because the software is going to fail, is outlandish. 

  • Re: This product needs massive changes
    Posted: 05-26-2011, 12:09 PM

    See previous comment about centralized DB... Retarded that each client keeps its own job results... poor!

  • Re: This product needs massive changes
    Posted: 05-26-2011, 12:13 PM

    Hi Gatorfan,

    First, let me welcome you to our forum! I think you will find a very active and intelligent community here and

    Please send me your concerns with the documentation and I will get them addressed as needed.

    Job results are stored client side for a configurable #of days/disk size and can be backed up by the filesystem agent hosted on that server. Job results contains scan results, backup.out(list of protected objects) and failed objects. There are times where the files contained in job results will be large but it should "maintain" itself using our pruning logic. If your job results are taking up too much drive space you can point those results to a different partition or you can also try configuring these pruning settings

    • Prune job results after

      Establishes the time period (days) for which the job results of data protection and data recovery operations are maintained.

    • Prune job results when disk capacity reaches

      Specifies a disk capacity threshold that, if exceeded, causes the software to prune job results. The disk referred to is the disk on which the job results of the client computer are stored (probably a local disk). Note that capacity utilization refers to the combined disk usage of all data (including applications) stored on the disk, not just that portion used for job results.

    Assuming you're referring to our agent logs on the client? These do leave a small footprint but that value is included in our system requirements. Support relies heavily on our logging when you place a case with us and there is no current way to completely disable that function of the software.

    Symantec certainly is a competitor in our vertical, that said it is also the most commonly displaced software when implementing Simpana.

  • Re: This product needs massive changes
    Posted: 05-26-2011, 12:26 PM

    Stephen

    Firstly.. Job results prunning.. OK... but guess what.. if i have 1000 servers.. that is 1000 servers i have to MANUALLY change this on.. Why no central management?

    Secondly.... If a server is allready low on disk space moving the jobresults directory is not always possiable.. case in point on why this is a bad idea to keep this on a host. What is the problem with keeping those results on a CS? Makes more since to keep that type of info on the CS... I would also imagine you would have better performance and lessen the network traffic, since you would not have to make those calls to a client.

    On to Documentation....

    Ok have you ever tried to look up and error code from the failed job in the CS? 99.9% of the time you get the nice little "Sorry we dont have record of this issue, but it has been noted". Ok what is wrong with acutlly having a troubleshooting doc with error codes and resolutions?

  • Re: This product needs massive changes
    Posted: 05-26-2011, 3:23 PM

    Hello again Gatorfan,

    Thanks for the response.

    You're correct - no global way to set job results - although you could probably push a registry key out with the change via Simpana control panel. I believe the idea of a global option would be tough due to each of your 1000 servers needing to have the same exact filesystem structure.

    To your second point, the files would need to be written at the host --> shipped to the CS(more bandwidth) which eventually end in those files being aged off within (7) days by default.

    As far as the error code links embedded in our event messages - we are aggressively trying to build a response for each and every error code and when you click that link which results in a "non helpful" that error is messaged to our KB team for review.

  • Re: This product needs massive changes
    Posted: 05-27-2011, 12:25 PM

    You're painting with rather broad strokes Gator.  Not having a readily available list of error codes may be limiting, but it hardly makes the documentation worthless.  And while I think you're right that changing logging options across a group of server is a good change request, it not presently happening hardly spells the doom for this software.


    Just my 1.4 cents (after taxes)
  • Re: This product needs massive changes
    Posted: 05-27-2011, 5:18 PM
    • Aplynx is not online. Last active: 09-13-2019, 12:47 PM Liam
    • Top 10 Contributor
    • Joined on 05-04-2010
    • New Jersey
    • Master
    • Points 1,705
  • Re: This product needs massive changes
    Posted: 10-10-2011, 1:53 AM

    GATORFAN:

    See previous comment about centralized DB... Retarded that each client keeps its own job results... poor!

     

    I'm not quite certain as to how having a centralized Database is a point of failure in CommVault's design.   To the best of my knowledge, the majority of NetBackup's data resides in 3 central databases, all retained on the Master Server (or a seperate EMM server, if you so wish to deploy one):

    • NetbackupDB - central database
    • EMMDB - "MediaManager" equivalent which controls all media (tld(*), media server registration, maybe vaulting?)
    • Catalog - similar to Index Cache, but not quite.
    So if anything, I don't see how this is a bad point.   What I will point out however, is the database design is quite different.  
    So let's go off on a tangent here and look at DR restores for example.  
    With NetBackup, due to legacy decisions, primary ID's within catalogs/databases are based against master/media server names, not IDs.  What this means is that in Netbackup land you are tied to the one server name, from install, for life.
    • Want to perform a Catalog recovery and the original media server doesn't exist or is no longer named what it was?  Have to manually edit catalog files (TECH48819).
       
    • Want to rename the Master server?  Not supported unless you contact SYMC Professional Services for "catalog manipulation services".
    With CommVault this is all un-necessary .. names are simply that, names.  You are not tied to your server names, and are free to migrate your servers, and your CommServe around as you need to which can happen every once in a while in an organisation (merger/de-mergers, acquisitions, organisational changes to your network, etc.)
    To be honest, if you're going to compare CommVault against NetBackup then you need to be looking at something more tangible.
    (Just my 2 cents..)
  • Re: This product needs massive changes
    Posted: 10-18-2011, 11:31 AM

    Hey Gatorfan...

    You say: This product needs major change...

    I say... You could always change product!!! 

    I have been using this product for a long time... While it is not perfect... Who's is?  And the staff is dedicated and helping!

    Also my 2 cents...

  • Re: This product needs massive changes
    Posted: 10-19-2011, 12:28 PM

    The only change this product needs is two types of logs.

    1. The detailed techno babble of the current logs, great for debugging. k.rap for reading.

    2. A user friendly log, for idiots like myself, that tells me in simple terms what a job has failed, is waiting, or needs some tlc.

    Other than that, I quite like commvault.

The content of the forums, threads and posts reflects the thoughts and opinions of each author, and does not represent the thoughts, opinions, plans or strategies of Commvault Systems, Inc. ("Commvault") and Commvault undertakes no obligation to update, correct or modify any statements made in this forum. Any and all third party links, statements, comments, or feedback posted to, or otherwise provided by this forum, thread or post are not affiliated with, nor endorsed by, Commvault.
Commvault, Commvault and logo, the “CV” logo, Commvault Systems, Solving Forward, SIM, Singular Information Management, Simpana, Commvault Galaxy, Unified Data Management, QiNetix, Quick Recovery, QR, CommNet, GridStor, Vault Tracker, InnerVault, QuickSnap, QSnap, Recovery Director, CommServe, CommCell, SnapProtect, ROMS, and CommValue, are trademarks or registered trademarks of Commvault Systems, Inc. All other third party brands, products, service names, trademarks, or registered service marks are the property of and used to identify the products or services of their respective owners. All specifications are subject to change without notice.
Close
Copyright © 2019 Commvault | All Rights Reserved. | Legal | Privacy Policy