Backup is the job everyone considers important and nobody does regularly. portvMind Backup ties it to a schedule: you define your backup policy once, the system runs it every time and cleans up old backups itself. When something goes wrong, you don’t just get your data back — you can bring your server up directly from a backup.
Backup is a service that automatically copies your disks at the intervals you set and keeps those copies for the period you define. You define a policy in the console: which disks, on which schedule, for how long. After that no manual work is needed; backups are taken when the time comes and expired ones are deleted by rule.
Backups and snapshots are often confused, but they do different jobs. A snapshot is a quick, manually taken copy of a disk’s current state — you take one before releasing a version and roll back if something goes wrong. A backup is about continuity and retention: it runs at regular intervals, builds a timeline of the past and cleans up old copies automatically. A snapshot is a safety net; a backup is a policy.
The standout feature of portvMind Backup is bootable backup support. From a backup you don’t just restore data, you can create a new server directly from it. This makes rehearsing a disaster recovery plan genuinely possible: without touching production, you bring up a server from last week’s backup and see whether it actually works. Learning that a backup is restorable for the first time during a disaster is the most common and most expensive mistake in backup.
Set your backup schedule yourself with cron-based timing. You define the policy once, and the system runs it every time.
Create a new server directly from a backup. Disaster recovery and test environment setup are done without a from-scratch installation.
Old backups are cleaned up automatically according to the lifecycle rules you define. Storage doesn’t balloon on its own and cost stays under control.
You define backup rules as policies, not disk by disk. When you add a new disk, you just include it in the policy.
With bootable backups you test your recovery plan without affecting production. You know your backup works before the disaster, not during it.
Your backups stay in the Istanbul and Ankara data centers. Data you must retain by regulation is kept within the country’s borders.
| Feature | Detail |
|---|---|
| Scope | Block Storage disks |
| Scheduling | Custom cron-based schedule definition |
| Backup type | Point-in-time copy; no manual intervention required |
| Bootable backup | Supported; a new server can be created directly from a backup |
| Retention management | Automatic cleanup with lifecycle rules |
| Management | Policy definition and monitoring via the console |
Detailed technical specifications and policy examples are published in the documentation.
For detailed technical specifications and policy examples, see Documentation
Enter the disk capacity you want to back up and your retention period, and see the total cost instantly.
Cost drivers: Backed-up disk capacity and how long backups are retained
Your cost depends on two things: the disk capacity you back up and how long you keep the backups. By adjusting your retention policy to your needs, you control the cost directly.
Your resources are metered for as long as they are running — you never pay for time you don’t use. In the console you can define a monthly or period-specific budget and get alerts when your spending reaches the 50%, 80% and 100% thresholds. Turn on overrun forecasting to see in advance whether your current consumption rate will take you over budget by the end of the period.
Alerts arrive by e-mail; with webhook support they can also be sent to Slack, Microsoft Teams or your own application.
Backup is one of the line items whose cost grows quietly: a new copy is added every day, and if old copies are not cleaned up the space keeps growing. Defining your retention policy limits this growth from the start; a budget threshold helps you notice a policy that slipped through.
Budget alerts send notifications; they do not stop resources automatically. You decide which resource to scale down.
The full pricing model| Snapshot | Backup | |
|---|---|---|
| Purpose | Quick rollback | Continuity and retention |
| Trigger | Manual, when needed | Scheduled, automatic |
| Duration | Short-term | Retention period set by the policy |
| Cleanup | Deleted manually | Cleaned up automatically by rule |
| Server creation | Derived from the disk | Directly from a bootable backup |
| Typical use | Before releasing a version | Nightly protection, regulation, disaster recovery |
They are not alternatives to each other; they are used together. You take a snapshot before a release; the backup policy handles daily protection.
A snapshot is a quick, manually taken copy of a disk’s current state; you take one before releasing a version and roll back if something goes wrong. A backup runs on a schedule, builds a timeline of the past and automatically cleans up old copies by rule. The two are used together.
From a backup you don’t just restore data, you can create a new server directly. This lets you rehearse your disaster recovery plan without affecting production, or quickly derive a test environment from production data.
Your Block Storage disks. Every disk you include in a backup policy is backed up automatically on the schedule you define.
With cron expressions. You can define policies that run daily, weekly or at custom intervals of your choosing.
No. You define the policy once; backups are taken on their own according to the schedule. No manual intervention is needed.
They are cleaned up automatically according to the retention rule you define. For example, you can set up a policy that keeps the last thirty days of backups and deletes older ones; storage doesn’t balloon on its own.
Just include the disk in your existing backup policy. You don’t need to write a separate rule.