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
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    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
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      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