Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Providing "undo" functionality appears to be a usability best-practice: A List Apart: Never Use a Warning When you Mean Undo.
Currently, you have to disable a site before deleting it, and you get a great big warning after that requiring confirmation. This ought to be enough warning for anyone, but inevitably clients will delete their sites by mistake.
However, since we already keep the site node, as well as the latest backup the parts are there to allow for undoing a site deletion. Though I suppose we'd have to ensure at least one backup.
Comments
Comment #1
Anonymous (not verified) commentedThe site gets backed up one last time in the backend prior to deletion. So even on Delete task, you have a tarball backup of the site in the 'backups' dir. You could re-create this site by running provision-deploy with the tarball as an argument to a target platform, reverify the platform and the site will be imported back into the system
This kind of leads into another ticket that discusses the ability to create/import a site by uploading a tarball through the frontend. See #322788: generic import mechanism for external database dumps and site backups. We feel this is the best approach to solving this issue and so it'd be good to see discussion take place there.
Comment #2
omega8cc commentedThe problems I see here:
What if the original platform of the deleted site is no longer available (we now allow to completely wipe out the empty platform files from the filesystem, not just platform node).
Or what if after the site was deleted, the platform got modified/upgraded, whatever and is no longer compatible with deleted site? What kind of checks should be performed before trying to restore deleted site? Is the complication involved worth the result?
It reality it would be better to see such a deleted site as a candidate for the fresh import, but remember - we have archived only sites/domain, not core drupal and no sites/all (modules/themes) and in fact it is pretty easy to make such a deleted site impossible to recover without knowing/tracking about all required modules, its versions etc etc.
Comment #3
ergonlogicCertainly #322788: generic import mechanism for external database dumps and site backups is much more useful in general. I'm not familiar enough with the surrounding code yet to see how anything like those patches will overcome the changed/migrated platform problem. Assuming we can get it to work, it would not only greatly ease migrating onto Aegir, but also seems to allow for site portability between Aegir service providers. I think this last point will be important in the long-run.
At any rate, my feature request here is more for a short-term "undo" than anything more comprehensive. Mig5's suggestion was what I had in mind:
I think it would be completely acceptable to limit availability of such an undo to the lifetime of the platform on which the deleted site existed.
The use case basically comes down to this:
Comment #4
adrian commentedyou know. this is kind of why 'disable' exists. there's only so much we can stop our users from their own stupidity.
maybe make it so you can only delete a site X time after you have disabled it.
Comment #5
steven jones commentedSo actually, I think this is a valid request, but one should be able to restore an arbitrary backup to any given platform without too much hassle, at the moment if you need to do this you have to resort to the command line.
Comment #6
cweagansHow would one approach this task? This would be a pretty awesome feature to have.
Comment #7
ergonlogicCurrently, Aegir's front-end isn't aware of the pre-delete backup, so the first thing to do would be #2022849: Ensure all automated backups are available via Hostmaster.. After that, we'd need something like #2022863: Add a restore task to Deleted sites. or #2023917: Create a 'Deploy from backup' task. Since there's prototype code in the former, I'll close this one as a duplicate.