Hello,

Incremental/full backups with Zstd compression, snapshots and the ability to manage backups via UI/WHMCS module will be available in SolusVM 2.0.

The details are here https://solusvm.com/roadmap/

snapshots, and live backups would be great for KVM nodes. Also, the ability for customers to view/restore themselves via the WHMCS plugin.

Don't know why SolusVM removed their End user backup feature.

We desperately need a cloud snapshot style backup system where clients can make backup and restore it anytime they want.

It will also good if we can charge for the backups like other cloud provider charging small fees for their backups

So a variable for WHMCS would be a bonus

Snapshots for openvz or similar would be very nice

I had already written a comment on this. Meanwhile i switched to borg for OpenVZ and KVM, which just works great. Its deduplicating + compressing, so backups need almost no additional space (depending on the changes since the last backup).

What I really want to say:

If you are planning a new backup concept, please use incremental backups and, for security reasons, the backups should be pulled, not pushed.
Otherwise, the new backup system would not be better than it is now.

Another option would be to build the new backup system modularly so that developers can add their own backup systems.

I opt for copies on request but also that the backups made automatically in the node can be restored in another different slave node

How about instead of using gzip to compress use lzop which would be better and faster for compression. Also via the admin interface a way to restore the backups would alsob be good rather than command line restores.

Would love to see even just basic backup functionality where you can set a backup over SSH with API functions to restore / create.

I'd love to see some sort of incremental backup, but would definitely be able to get by with something simple as above.

Incremental backups would be great to save disk space. Currently i create a ploop snapshot, mount it and use rdiff-backup to backup all openvz VEs.

For KVM i am using lvmsync for incremental backups.

Maybe this tools gives you an inspiration.

Hi Joel,

Acronis seems to have limited options for backups and restores when it comes to LVM without significant disruption.

Additionally it also seems to run completely independently with its own management UI.

perhaps I am missing something are you able to provide a link to the specific Acronis product/version you have in mind?

Hi Chris,

For clarity are you looking for an option to do backups to a separate local volume in the same physical server or over the WAN/LAN or both?

Obviously there are some challenges with both in terms of generating IO wait or link saturation while transferring multiple TB's of data.

r1Soft is already an option with no further integration required via the r1soft Server backup manager, what sort of integration would you like to see, please be as detailed as possible.

Obviously backups in general have become a popular request so it is important to understand the most likely use cases and methods by hosts to get this right.

Had asked for a working backup solution (to 2nd or 3rd HDD in same server) for years ... was promised many times and never done.

Add Acronis Backup as an option

A viable backup solution for customers to manage their own VP backups that are not stored on the node is needed.

Please add the ability to perform Automated Backups for KVM VMs

The idea itself is good - snapshots, could definitely work, though IO wise, would need to be limited, as it'd affect all customers in the node. If that's using the central storage too, could indeed work, but you'd need a very fast network, probably within the same network to do this on a reasonable timeframe.

Voted.

Allow customers to enable auto backup and restore backups right from client panel and we can bill the customer on this backup service.

And backups go to a central storage that someone has already proposed.

No need to mention that this features should be available on API.