OnePass agent - considerations when switching from classic archiver

Last post 02-26-2015, 8:17 AM by Pete Clements. 3 replies.
Sort Posts: Previous Next
  • OnePass agent - considerations when switching from classic archiver
    Posted: 02-03-2015, 9:26 AM

    Hey team,

    I've only just finally given the Onepass migration a go, and I'm a little concerned with some of its implementation restrictions. Perhaps I'm missing something, or perhaps there's a way around it that someone has across.

    It comes down to storage policy allocation.

    Previously the backup agent would write to the backup SP, and the archvie clients could be configured to write to a different policy. In some situations, these SPs may be writing to seperate maglibs. Not an unreasonable design in certain situations.

    Implemententing OnePass now means you have to write all data to a single SP, and this can cause issues due to:

    Wanting to seperate backup and archvie data to different maglibs, perhaps on different arrays/locations etc.

    Content Indexing of the archived data only, and not all backed up data. As CI is enabled at an SP level, you'd have to consume more CI DB space and licences if processing all backup and archive data!

    Also, you will end up have historic data spread across two storage policies.


    Has anyone come across these situations at all yet?

    Comments welcome :-)

    Pete

  • Re: OnePass agent - considerations when switching from classic archiver
    Posted: 02-09-2015, 3:44 PM

    Well, for anyone reading this post and in the same situation, the only way I can see around this is to use multiple backupsets.

    You can set on backupset to backup, another to archive, and then seperate out the storage policies and Content Indexing settings.

    However it kind of defeats the "Onepass" concept in my mind.

    Perhaps there's another way around this, either now or in the future.

  • Re: OnePass agent - considerations when switching from classic archiver
    Posted: 02-26-2015, 7:07 AM

    Hey Pete,

     

    Is true, the only way that you can go is to create SP for each subclient (backup and archive).

    In my opinion, OnePass is dedicated for big environments, where backup and archive jobs last for to long. In this kind of environments, doing the administration of the SP or multible backupsets, is not a chalange.

    I think is up to you, depending of your needs.

    Vali


    I'm Certifiable, not only certified.
    It just means my answers are from experience, not from a book.
  • Re: OnePass agent - considerations when switching from classic archiver
    Posted: 02-26-2015, 8:17 AM

    Hey Vali,

    Yes I agree with that too. It was just worth seeing if anyone else had any different thoughts. The customer I was working with was reasonably small, so the performance/speed wasn't an issue initially.

    Cheers

    Pete

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