I suggest you ...

restore : it should be easy process..

restore shud be possible in new application right on same server, present process is too long > clone> DNS change > restore original site> test and then reverse the complete process.
all this cud be simpler if restore to an application is possible on same server.

2 votes
Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)

We’ll send you updates on this idea

Anonymous shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

2 comments

Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
Submitting...
  • Trevor Lohrbeer commented  ·   ·  Flag as inappropriate

    I'll chime in and say that point-in-time restore is not sufficient here.

    Restoring to a point in time is useful if you just want to revert a change. However, if you want to test the Cloudways backup system (which everyone should be doing--trusting that backups just "work" without doing test restores from time-to-time is almost the same as having no backups at all), this doesn't help.

    Also, if you want to test a potential rollback+fix scenario on a test server before deploying that to production, point-in-time restores don't help.

    If you were able to access restore points on cloned applications, that would help solve some of these problems. Then you could clone the application, roll back to a previous restore point on the clone, test different fixes, and then when everything is working, port those changes over to production.

    Alternatively, the ability to download backups and then restore from a local backup through the UI would help achieve a similar aim.

Feedback and Knowledge Base