Yorigu Disaster Recovery
Machine and DB System Replication for OCI
Protect physical servers, virtual machines, and mission-critical DB systems with agentless recovery workflows built specifically for Oracle Cloud Infrastructure.
Physical Servers are replicated or migrated to the selected target without changing the source configuration.
Virtual Machines follow the same workflow as Physical Servers, with validation tracked through every phase.
DB Systems add Database-Aware consistency, validation, and cutover readiness for mission-critical database workloads.
Target-Specific Delivery
Yorigu Disaster Recovery for OCI is suited when datacenter recovery capacity should live outside your own site on Oracle Cloud Infrastructure. Recovery state stays prepared without requiring target compute VMs to run continuously, so teams can maintain a reliable recovery position, automate validation, and avoid standby VM compute cost until validation or failover actions require compute capacity.
Replicated workloads are placed in the OCI region selected by the organization, keeping the data residency boundary tied to that region.
For Disaster Recovery, Yorigu is designed around powered-off standby targets: replicated state is kept ready, compute is used for scheduled validation and failover, and readiness is evidenced through the workflow rather than assumed.
Operational Controls
Failover runs as an organization-owned, orchestrated workflow with readiness state, tracking, and validation context, not as an unattended automatic trigger and not as a manual sequence of commands.
Yorigu runs scheduled validation tests and produces recovery readiness evidence, including Machine, network, and database state where Database-Aware workflows apply.
AutoHealing keeps Disaster Recovery workflows working through source-side variations and reduces operator effort during target activation.
Recovery point and recovery time objectives are set per workload. Sync frequency, target preparation, validation workflow, and cutover procedure are tuned according to workload priority.
Standby targets stay powered off until a recovery event, so disaster recovery does not require continuously running duplicate compute. Workloads that must stay under continuous synchronization are handled as scoped exceptions.
Failback is part of the same product lifecycle, not a separate product, separate license, or disconnected reverse workflow.
Database-Aware Workflows
Yorigu can automate DR workflows for physical servers, virtual machines, and mission-critical source DB Systems. When database-aware coverage is required, DB Systems brings consistency, validation, cutover readiness, and recovery state into the same operational view as machine-level workflows for recovery and validation toward OCI.
Database-aware workflows track consistency and validation state, so DB systems return in a usable, consistent state rather than as generic block-level copies. This matters most for transactional systems such as Oracle and SAP HANA.
View DB System WorkloadsPhysical server and virtual machine coverage for environments that do not need database-aware workflows.
Machine + DB System packaging includes Physical Server and Virtual Machine coverage alongside Database-Aware workflows.
Machine-only packaging is available for environments that do not require database-aware recovery workflows.
For organization-specific licensing, deployment scope, or a POC License, contact Yorigu.
Next Step
Yorigu can help assess the right deployment model based on your operational requirements and recovery objectives.
