Question : What is SWIFT?

-- SWIFT is a tool from RackWare for backup, replication, and disaster recovery of container platforms.


Question: What platforms does SWIFT support?

-- SWIFT works with Kubernetes and OpenShift clusters.


Question: Which cloud services does SWIFT support?

-- SWIFT supports EKS (AWS), OKE (Oracle), AKS (Azure), IKS (IBM), and GKE (Google Cloud). 


Question: Can SWIFT work across different cloud platforms?

-- Yes, SWIFT supports cross-cloud, cross-platform, and cross-version replication and disaster recovery.    


Question: What is the backup frequency policy does SWIFT support? 

-- SWIFT Support's Disaster Recovery (DR) policy allows you to create backup and DR plans with different scheduling options, such as scheduled intervals, set frequencies, one-time backups, or continuous sync.


Question: What environments are supported for migration?

-- SWIFT support's On-prem to cloud (AWS, Azure, GCP, OCI,IBM, LKE). Cross-cluster. SWIFT also supports cross-clouds and multi-region container migrations


Question: Can I do multiple backups to object storage?

-- Yes. You can run multiple backup policies to different object targets (e.g., short retention + long retention, or separate buckets/accounts for compliance) Backups are incremental and can be scheduled independently from DR syncs. Supported object targets include major clouds (AWS, Azure, OCI, GCP, IBM, Huawei) 


Question: Do I need application quiescing and downtime for syncs?

-- No downtime is required for crash-consistent snapshots and incremental sync policies. There is no quiescing during cutover window either.


Question: Why do I need SWIFT for stateless workloads?

--  Stateless still has important state: manifests, configs, secrets, ingress/service objects, and container images/registries. SWIFT replays the full application topology so you can redeploy consistently across clusters/clouds (and reduce configuration drift). If data is external, SWIFT still accelerates recovery by restoring the app layer fast and predictably. 


Question: My app is HA, why do I need DR? (HA vs DR)

-- HA keeps services running within the same site/region for common failures (node/zone). It does not cover site-wide outages. DR protects against site/region failure by syncing app + data to a standby environment and orchestrating failover. Most customers use both: HA for everyday resilience, DR for “worst day” events. DR-based backups also protect against ransomware attacks with restore-anywhere ability of SWIFT .


Question: Does fallback cost me separately?

-- Failover/failback doesn’t consume a separate “per event” license—licensing is for ongoing protection (apps + storage). What you do pay for is target-side infrastructure during DR (compute, storage, load balancers), because those are your cloud/platform resources. Migration is typically a one-time license (non-perpetual); DR protection is subscription-based for ongoing sync and readiness .


Question: Do you need SSH or application access?

-- No. SWIFT operates through Kubernetes APIs/RBAC and storage snapshot/sync mechanisms—no SSH to worker nodes is required. Application credentials are not required either for crash-consistent protection.  


Question: Do you need admin security permissions (in Cloud)?

-- You usually don’t need full cloud account admin—what matters is Kubernetes access with the right RBAC privileges. Typical permissions: read/apply manifests, manage PV/PVC and snapshots, and (optionally) create ingress/load balancer objects. If using object storage or registry sync, you’ll also need scoped IAM credentials for the bucket/registry. All required permissions across different Clouds are well documented and also available as Freshdesk public KBs .


Question: How many SWIFT VMs do I need and with what specs?

-- Most deployments start with 1 SWIFT management VM per environment; add capacity (or separation) as throughput and concurrency grow. Typical starting point: 4–8 vCPU, 16–32 GB RAM, and fast local disk for metadata/staging; scale with #apps, PV capacity, and target RPO. We finalize sizing from POC results and required sync throughput (bandwidth throttling and concurrency help tune). (Re)Distributing SWIFT licenses across SWIFT VMs is possible and free (for DR) .


Question: Will apps retain IPs?

-- Pod IPs are ephemeral in Kubernetes; across clusters, service/load balancer IPs often change as well. SWIFT restores the service/ingress objects so the *names* stay consistent—best practice is to front with DNS/ingress hostnames. For strict “same IP” needs, use cloud/network VIP or traffic manager patterns (architecture discussion).  


Question: Can SWIFT perform backups to multiple object storage targets?

-- Yes. SWIFT supports multiple backup policies targeting different object storage locations or buckets. Customers can configure short-term and long-term retention policies independently. Supported object storage platforms include AWS, Azure, OCI, GCP, IBM Cloud, and Huawei Cloud.


Question: Does Marketplace licensing continue when the SWIFT VM is stopped?


CloudMigrationDR
Azure
No. Azure Marketplace uses usage-based (hourly) billing. Marketplace software charges are incurred only while the VM is running and reporting usage. When the VM is stopped and deallocated, Marketplace software charges do not accrue. Billing resumes when the VM is started again.No. When the SWIFT VM is stopped and deallocated, Marketplace software charges do not accrue. Billing resumes when the VM is started again.
GCP
No. While the SWIFT VM is running, the customer is billed for both GCP infrastructure and the Marketplace software license. When the VM is stopped (powered off), Marketplace software license billing is paused. Billing resumes when the VM is started again.No. The Marketplace software license is not consumed while the SWIFT VM remains stopped. Billing resumes when the VM is started again.
OCI
Not necessarily. OCI Marketplace offerings are pay-as-you-go and are charged hourly based on the applicable Marketplace meter. Powering off the VM may stop compute charges, but it does not reliably pause or suspend Marketplace subscription/license charges. To stop Marketplace software charges, terminating the Marketplace instance is the safest approach. Back up required configuration and data before termination.Not necessarily. Powering off the VM may stop applicable OCI compute charges, but it does not reliably stop Marketplace software charges. If the intent is to stop Marketplace software charges, terminate the Marketplace instance after ensuring that required configuration and data are backed up.