Install with:
pip install anybackupRequirements: Python 3.10+
Or clone and run:
git clone https://github.com/anybackup-ai/anybackup.git
cd anybackup
python setup.py install
AI-Native Data Resilience Platform
Backup, recovery, and operational assurance through explainable agent workflows.
Anybackup V9 is a more economical and intelligent data resilience platform. Built on an open-source business model, it helps customers achieve the data resilience their business requires. Powered by Anybackup Agent as an AI backup administrator, the platform enables autonomous backup, autonomous recovery, and autonomous optimization, reducing total cost of ownership by up to 35% and moving teams beyond reactive response.
Traditional backup systems are usually powerful after you already know what to click, which policy to configure, which recovery point to choose, and which risk you are about to create. That is exactly the problem.
Anybackup V9 is not trying to put a chatbot on top of backup software. It is rebuilding the backup and recovery experience around an AI-native workflow:
- Describe the data protection need in natural language.
- Let the Agent generate a structured plan with assumptions and risks.
- Keep the human in control for dangerous actions.
- Let Foundation execute the confirmed backup or recovery task.
- Keep the decision and execution trail auditable.
The goal is simple: make data resilience easier to operate without making it vague, magical, or unsafe.
This is the open-source repository for Anybackup V9, the full platform direction:
| Product part | What it does |
|---|---|
| Anybackup Agent | Understands intent, generates backup and recovery plans, explains risk, manages confirmation, and keeps decision context |
| Anybackup Foundation | Executes backup, recovery, retention, and data protection operations |
| Anybackup Client | Connects protected workloads and provides workload-side data access |
Anybackup Agent is cloud-native and must be deployed on Kubernetes. Anybackup Foundation is host-deployed and runs on managed infrastructure outside the Agent Kubernetes runtime. This README keeps deployment details compact, but it should still respect the real product structure.
Describe a workload and Anybackup Agent turns the request into comparable backup plan candidates. The plan is not just a sentence: it should explain frequency, recovery point expectations, risk trade-offs, and why one option is recommended.
Describe a MySQL failure and the Agent turns it into a structured recovery plan. The plan identifies recovery scope, target point, execution path, and the risk of overwriting or rolling back data.
Any action that can damage production data must go through explicit human confirmation. Anybackup treats AI as a planning and decision-support layer, not as an unchecked operator.
Administrators can ask about backup jobs, recovery progress, and platform state in natural language instead of hunting through raw system details first.
The conversation, generated plan, human decision, execution request, and result should remain traceable. This is essential for real backup and recovery operations, where "why did this happen" matters as much as "did it run."
9.0.0-alpha is an early public preview. It is focused, deliberately narrow, and meant to prove the core loop before the platform grows wider.
In scope now
- Single backup administrator workflow
- MySQL-first backup and recovery scenarios
- Backup recommendation from natural language
- Recovery plan generation from failure descriptions
- Human confirmation before risky execution
- Foundation-backed execution path
- Basic operational query experience
Not promised by this alpha
- Complete multi-tenant SaaS operations
- Full enterprise role and permission model
- Broad workload coverage beyond the first MySQL scenarios
- Fully automated multi-step recovery without operator review
- A polished production installer for every environment
This boundary is intentional. A reliable AI-native data resilience platform should earn trust one operational loop at a time.
Anybackup V9 is installed through the integrated deployment entrypoint. Before running the installer, prepare the model configuration from the provided template, then run deploy/install.sh and follow the installer prompts for required credentials.
Local single-node installation example:
cd deploy
./install.sh \
--local \
--foundation-mode integrated \
--foundation-self-ip <foundation-private-ip>The installer prepares the Kubernetes runtime, deploys KWeaver, Foundation, FoundationClient, Anybackup Agent content, and business services, then publishes the Web access entrypoint.
For detailed deployment steps, model configuration, and credential input methods, see deploy/DEPLOYMENT_en.md.
User:
Recommend a backup plan for our production MySQL database.
Anybackup Agent:
I found three candidate plans:
1. Standard protection
Weekly full backup + daily incremental backup.
2. Low-RPO protection
Weekly full backup + daily incremental backup + minute-level log backup.
3. Simple protection
Daily full backup.
Recommended: Low-RPO protection, because this database is production-facing
and needs a shorter recovery point objective.
User:
The production MySQL instance crashed and all databases are unavailable.
Anybackup Agent:
This looks like an instance-level failure.
Recommended recovery:
- Scope: full MySQL instance
- Target: latest valid backup point
- Execution: restore through Anybackup Foundation
- Risk: this may overwrite current data on the target host
Please confirm before execution.
Natural language request
|
v
Anybackup Agent
Intent, plan, risk, confirmation, audit context
|
v
Anybackup Foundation
Backup, recovery, retention, execution
|
v
Anybackup Client
Protected workload access and data collection
The platform design separates decision, execution, and workload access. That separation matters: AI can help decide and explain, Foundation executes confirmed operations, and Client-side capabilities connect the protected environment.
Anybackup/
├── Agent/ # AI interaction and decision layer
├── CLI/ # Internal command-line tooling and control utilities
├── deploy/ # Cloud-native deployment assets
├── LICENSE # SSPL-1.0
├── NOTICE # Copyright notice
├── README.md # English README
├── README_zh.md # Chinese README
└── VERSION.txt # Current version
CLI and deployment assets exist because real platforms need engineering tools. They are not the main story of this README. The main story is the product capability: AI-native backup, recovery, and data resilience.
Anybackup is released under SSPL-1.0. The project uses an open-source model to make the platform direction visible, inspectable, and extensible while preserving a sustainable path for enterprise-grade development.
Third-party notices are maintained alongside distribution units where applicable. See NOTICE and component-level THIRD_PARTY_NOTICES.md files for details.
- Issues: GitHub Issues
- Discussions: GitHub Discussions
Contributions are welcome as the project evolves. Before submitting a pull request:
- Open an issue to discuss the change or feature.
- Keep changes aligned with the current alpha scope.
- Update relevant documentation and notices when behavior or dependencies change.
- Run checks for the component you modified.
Detailed contribution guidelines will be expanded as the public development workflow matures.
Agent fails to start after deployment
- Verify the Kubernetes cluster has sufficient resources (minimum 4 CPU cores, 8GB RAM recommended).
- Check that all required images are accessible and properly pulled.
- Review pod logs:
kubectl logs -n anybackup <pod-name>.
Foundation cannot connect to Agent
- Confirm the
foundation-self-ipmatches the actual private IP of the Foundation host. - Ensure network policies allow traffic on the configured communication port (default: 8080).
- Check that the Foundation service is running:
systemctl status anybackup-foundation.
Backup jobs hang or time out
- Verify the Anybackup Client is installed on the target workload host.
- Confirm database credentials and connection parameters are correct.
- Check disk space on the storage target — insufficient space will cause silent failures.
Recovery plan not generating
- Ensure the AI model endpoint is reachable and credentials are valid.
- Check model logs for authentication or rate-limit errors.
- Verify the workload metadata is complete in the Client configuration.
If you encounter an issue not covered here:
- Search GitHub Issues for similar reports.
- For questions, use GitHub Discussions.
- When reporting a bug, include: product version, deployment method, error logs, and reproduction steps.