Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backup functionality which is part of core #44

Open
markkap opened this issue Sep 7, 2018 · 2 comments
Open

Backup functionality which is part of core #44

markkap opened this issue Sep 7, 2018 · 2 comments
Milestone

Comments

@markkap
Copy link

@markkap markkap commented Sep 7, 2018

Need to do research into which plugins can be serve as base for this. Most important aspect is ability to perform a lightweight backup before installing and reverting in case of any failure.

User triggered backup/restore can wait for later phase of development.

@markkap markkap added this to the 1.0.0 milestone Sep 7, 2018
@mikeschinkel
Copy link

@mikeschinkel mikeschinkel commented Oct 30, 2018

What would be good would be to add a backup API and then a simple backup implementation thus allowing more robust backups to be created by 3rd parties.

@markkap
Copy link
Author

@markkap markkap commented Jul 16, 2021

Minimal option for backup with the main goal of being able to recover the site after bad core/theme/plugin upgrade or install.

Backup should create backups of code files and options (options table). The idea is that if any content was created in time time between backup and restore it will not get lost, and same goes for user related settings.
Potential problem might be users which were added in between and might lack the appropriate role, probably will need some audit of users after restore, or some smartness in the code.

It should be possible to trigger backup manually and perform automatically before upgrades (should it be a setting?).

Backups should be created in uploads/.protected/backups directory where the filename has the form of backup-{time}. In addition a "meta" file will be created as well under the name of meta-{time} and will include some meta infromation for the backup like version of calmPress, trigger etc. (separate file and not in the backup itself to make it faster to read the information).

Backups should be removed when they become older than 30 days and there are more than 30 in the directory. Probably should be configurable.

What is backuped should be extendable. Core of code files and options should always exist for a restore from safe mode, but plugins should be able to add whatever to it. Also trigger action when a backup was finished to be able to move the backups (but not remove) to external storage.

An action in the end of restore process should enable pluggins to trigger their own part of the restore. An action before the restore starts might enable plugins to "download" backups from external storage to present more restore options to the user.

markkap added a commit that referenced this issue Jul 28, 2021
markkap added a commit that referenced this issue Jul 28, 2021
…ructures for testing, modify backup code to use it. #44
markkap added a commit that referenced this issue Aug 4, 2021
markkap added a commit that referenced this issue Aug 5, 2021
markkap added a commit that referenced this issue Aug 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants