BEFORE YOU BEGIN
Check before you begin
This public guide covers planning and acceptance. Multiple repositories, inter-site replication, centralized monitoring and automatic failover are different scopes; a single console or automatic switchover is not assumed for every platform. Contact support for internal topology and technical access guidance.
Visual note: no suitable real management screenshot without internal topology or customer information is available; an unrelated platform screen was not substituted. This work changed no site, repository, access or replication settings and ran no recovery operation.
- Product release, platforms and site owners
- Data scope, capacity and connectivity objectives
- Access boundaries and secret protection
- Isolated testing and recovery acceptance plan
011. Define the management scope
Identify the management scope of sources, repositories and sites. Management within one master differs from unified management of independent masters. Do not promise universal federation or single-console coverage without verification.
Expected resultScope and acceptance results are documented with the responsible owner.
022. Match inventory and ownership
Match source and repository identities to workload owners and prevent confusion from similar names. Do not associate old identities with incorrect data after source moves or storage changes. Never publish internal addresses or customer inventories.
Expected resultScope and acceptance results are documented with the responsible owner.
033. Validate access separation
Assess monitoring, policy-change and recovery-initiation privileges separately. Validate role and scope behavior against the installed release; one successful test does not establish identical access controls for every operation. Request an approved technical permission matrix from support.
Expected resultScope and acceptance results are documented with the responsible owner.
044. Plan policies and capacity together
Match scheduling, retention, job concurrency and repository capacity to business requirements. Do not assume a central setting immediately applies to every agent or running job. Verify scope and new/existing-job behavior against release documentation.
Expected resultScope and acceptance results are documented with the responsible owner.
055. Separate monitoring from data acceptance
Assess job state, latest recovery point, capacity and alerts together. An accessible console does not establish health of every data path. Central metric collection is not management authority or an automatic HA/failover guarantee.
Expected resultScope and acceptance results are documented with the responsible owner.
066. Validate changes through controlled acceptance
Within an authorized small test, check policy effects, access boundaries, error notifications and isolated restore acceptance. State job/agent/platform scope in the report. Perform production changes with a maintenance plan and rollback conditions.
Expected resultScope and acceptance results are documented with the responsible owner.
077. Complete operations and support planning
Define job tracking, escalation and decision ownership when management components are unavailable. Refresh acceptance plans after upgrades or adding sites. Contact destek@menabyte.com.tr with a redacted requirements summary for architecture, access and release-specific scope.
Expected resultScope and acceptance results are documented with the responsible owner.
COMMON QUESTIONS
Does centralized monitoring provide automatic high availability?
No. Monitoring, unified management and automatic failover are separate acceptance scopes. Verify support for the installed platform and release.