Open Graham-72 opened 7 years ago
It would be convenient but there are still a lot of sites that have backups by a different method so I'm not certain if this is a good candidate for core. The module provides a way to backup the files directory which would cover config in some cases or someone could add the capability to backup another folder. I think it has to be in the web root.
According to Project browser, Backup and Migrate is the 2nd most popular Backdrop module. That, and the importance of easy but reliable ways to make backups and the possiblity to include configuration files could be good reasons to get the module in core even if there are different methods.
On the other hand, it's quite easy to install the contrib module, and I got the impression that it is maintained well.
I would vote against this for the reasons that @herbdool has stated.
If I'm on a host where this is useless or I'm simply employing a different method than this just becomes bloat. I'd prefer to add it when needed.
I understand what you are saying and I personally am happy to carry on installing a backup module as a separate add-on, as I am used to this with Drupal and Backdrop sites.
But what about newcomers to Backdrop? What back up solution should they be using and why cannot it be something that comes with an 'out-of-the-box' Backdrop site?
Is this perhaps another of the technical obstacles in their path? Or is Backdrop just for the technically proficient? How do we stand in comparison to Wordpress?
@Graham-72 can you do some research on that last question? What does Wordpress provide out of the box?
@herbdool yes gladly. I think I will do a Wordpress 'real website' install as if a beginner and try a step-by-step comparison with Backdrop.
Is this perhaps another of the technical obstacles in their path? Or is Backdrop just for the technically proficient?
We've got pretty low standards for "technically proficient" if "top of the first page in Project browser" is too hard.
@jlfranklin you have a very good point. Project browser is excellent.
Perhaps we need something in Backdrop's README.md about the importance of backups, and how to arrange for them, or better still an easy to access and user-friendly readme.html as in Wordpress?
I find that Wordpress 'out-of-the-box' also does not include a backup solution. I had to go to their Codex to find out what they propose and there they give a list and explanation of alternatives. Their list is:
From all the above I conclude that it would not be a good idea to include backup-migrate in core. But I think perhaps we need a section in our User Guide.
Do you want to either change the title of this issue or open another one suggesting the User Guide option? @Graham-72
From all the above I conclude that it would not be a good idea to include backup-migrate in core.
You should be concluding that if we added it, then Backdrop would have a feature that the competition (D8 and WP) does not have 😉
...I mean most CMSes (including Drupal, Backdrop and WP) urge users to do a backup before proceeding to an upgrade. That sends users to a hunt for a solution which disrupts them from the task they started doing (the upgrade). Now, if we had a backup solution in core, we'd simply be including it as an optional step of the upgrade/installation wizard.
open another one suggesting the User Guide option
I believe that issues regarding the user guide are in a different place? And whether a backup solution is or is not in core we should still have a section on the subject in our user guide.
I think @klonos makes a good point here in favour of something optional in core. And I would also like to see an option for automatic updating of core which I think has been raised before.
👍 on docs for various backup solutions
👎 on backup migrate in core;
Some documentation to point out the subtleties, possibilities, and pitfalls is a good start. Let's start with the documentation and if that lights the way to a clear path to an 80% use case that will cause more user happiness then frustration we can then revisit the backup solution in core.
And I would also like to see an option for automatic updating of core which I think has been raised before.
There are at least two issues for this:
Which is of course very complicated in its own right.
Have the scaling problems been fixed with Backup/Migrate? I used the module back in the D6 days and found that the database export I had created could not be restored through the UI because it was far far too large for an HTTP POST operation. I've never bothered with it since, preferring drush
or basic command line tools.
@jlfranklin in D7 it still suffers from the same POST timeout problems; have not tried it in D8.
I think if anything gets included it be just a very basic part of the module, the ability for manual downloads of the database, code and files. And possibly integration with the Nodesquirrel service that Pantheon now runs for storing backups. Everything else could be in contrib.
And possibly integration with the Nodesquirrel service that Pantheon now runs for storing backups.
Integration with third-party services does not belong in core. We're not Nodesquirrel sales and marketing. That belongs in a Nodesquirrel integration module, which Pantheon can install and enable by default in a Pantheon install profile.
Sure, makes sense not to include Nodesquirrel. I'm not invested in the idea.
BTW, Nodesquirrel isn't really useful for sites actually hosted on Pantheon since they have their own built-in backup scheduler that doesn't require backup_migrate, more for sites hosted elsewhere. Not sure why Pantheon owns it but they do.
This is our most popular contributed project. I would also like to see it added to core, but without nodesquirrel, and carefully.
Adding milestone candidate label for 1.14.
I think that basic backup functionality in core would be a big win. While Backup and Migrate is only one of many solutions, I think it's the best solution for most of our target audience. How difficult would this be?
I am looking for a possible feature that we could still get into 1.17 (bonus points for a feature that might get some attention/buzz). This one MIGHT be too difficult to accomplish (and achieve consensus) in just over 20 days, but I'm not sure. Thoughts?
I think the technical reasons already presented for not including Backup and Migrate are many and varied enough that including it should not be taken lightly.
I also think if this were to happen, It should be dis/enableable and disabled by default, because if it were not, I would hack core to remove it, regardless of the number of kittens who died as a result.
For my use case, Backup and Migrate is too bloated and provides features I don't want my users to have access to. I would not want my users to just willy-nilly restore a site using a web UI. Also, how are they going to restore the site if the site is down?
I suspect that even providing the basic functionality would not be something I would want. I handle backups for the sites I host in a different way that is not tied into the site.
For my use case, Backup and Migrate is too bloated and provides features I don't want my users to have access to.
@oadaeh I was under the impression that we were considering adding a very minimal set of the features of Backup and Migrate in core, with the UI limited to a simple "Backup my site" checkbox that would be presented to users when they perform tasks such as db updates etc.
In other words, instead of this:
People would see this:
...and then this:
I see that as a UX improvement compared to the current workflow.
I completely agree with @oadaeh comment from more than year ago - https://github.com/backdrop/backdrop-issues/issues/2409#issuecomment-671965065
This feature is not only useless for many users, but it can be very dangerous and pose additional security risks. Even disabled as a module, such code can be called directly in some cases if an attacker knows the path to the module's directory. Thousands of crawlers are looking for such dangerous code (mostly WP, but not only) to use every day.
BTW, the number of installations (705 as of today) didn't tell me anything about its real use.
Even disabled as a module, such code can be called directly in some cases if an attacker knows the path to the module's directory.
I don't see a reason why this wouldn't be seen as a security issue and fixed accordingly. Or do you think it's a general, not fixable problem (by design)?
Or do you think it's a general
Not about the current code at all. To be honest, I avoid this kind of system-related stuff at the site level.
@findlabnet flawed security (or FUD of it) can be an argument against implementing any feature. There's plenty of use cases where we secure execution of many tasks in Drupal/Backdrop via various means (for example running cron requires a secret hash key, running the installer or update.php requires update_free_access
in settings.php to be set to TRUE
, etc.). I'm sure that security would be considered very carefully when implementing this.
Even disabled as a module, such code can be called directly in some cases if an attacker knows the path to the module's directory.
I really doubt that. If that were the case (being able to "run" code from disabled modules), then Drupal/Backdrop are in serious trouble.
During the recent Backdrop LIVE we had a demo of the demo module. https://backdropcms.org/project/demo
This contrib module provides a way to create a snapshot of the database and config files or a site and then restore them later. It occurred to me, that this MIGHT provide us with some code we could use to add backup functionality to core.
@quicksketch took a look at the code and neither gave a firm endorsement nor raised concerns about the code in this contrib module.
I'm wondering if anyone else might be interested in looking at the code in this demo module and see if it's something we MIGHT want to use.
In summary, the goal is to provide a way for people to create database and config snapshots when upgrading their sites. This feature may or may not include a "restore" feature. This functionality should definitely be optional with the ability to either disable it or leave it disabled by default.
NOTE: I think that this feature would be a nice PR win for Backdrop CMS. It's very much targeted at beginners.
The backup_migrate module can be used to also save the configuration files but this is a separate action requiring two steps: one to save the database and another to save the active configuration files. Also, restoring the configuration files currently has some issues, https://github.com/backdrop-contrib/backup_migrate/issues/93
On the other hand, the demo module creates a snapshot with both the database and the active config files in a single action and likewise the restore is a single action for both.
@izmeez - Yes, both the Backup and Migrate moduel and Demo module provide the functionality that is needed here and most regular backdrop developer have other tools to create and restore backups.
Our goal here is to make this easier for a site owner or site architect that is managing their own site. During every upgrade, we provide a warning that they should backup their site before doing the upgrade, but we provide no tool in core for this purpose. So we are basically saying, we highly recommend this step, but you will first have to go download and install a new module to do it.
We don't want to move ALL of Backup and Migrate into core, because it provides more functionality than is needed for the minimum use case. But, many users have requested that we provide at least some of this functionality in core for he most basic use case. It's currently 5 on our community wishlist (https://forum.backdropcms.org/feature-requests).
The task in this issue is to figure out:
1) Do we want this functionality in core at all (or are contrib solutions good enough)? 2) If so, what exactly should be in core and do either Backup and Migrate or the Demo module have some code that we can reuse in core to simply the process.
Personally, I would like to see core include (as an option) the ability to create a snapshot of the database and active config directly and the ability to restore it. I don't think we need any of the other many settings and features in Backdrop and Migrate module in core.
What do you think? Should we have this functionality in core and how much functionality do you think we should have in core (if any)?
I would like to be able to create snapshots before updating. It would make restoring the site to before the update much easier, in case of problems.
For every site I build I install the contrib module backup_migrate and I wonder why this is not a capability built in to core.
If it also included the backup of the active config json files it would be even more convenient.