Hi! :)

You may have heard of http://drupal.org/project/demo already. I'm one of the maintainers.

I never really looked at Backup and Migrate module in-depth, 'cause it looked + felt too convoluted, and Demo tries to provide a small + sexy + focused API and base functionality only. It's also borrowing a bit of code from phpMyAdmin to keep all generated SQL dumps compatible to it.

However, I just had my first experience with this module, since it was installed on a site already. Given what I've seen there, I think that we are horribly duplicating efforts ;)

Although I guess there is a difference between the intended audiences of both modules:

- Backup+Migrate: Site administrators and users, to backup their sites and perhaps restore them occasionally in case of problems; focus on backup.

- Demo: Developers and site builders, to backup and intentionally reset their sites after performing test-drives; focus on clean restore.

But anyway, considering the low-level functionality behind both modules, I'd say that the requirements are almost the same.

Hence, I wanted to kick-start discussion about possibilities in terms of joining forces.

Aside from above considerations, another thought of mine was that both module names are quite eeeek ;), so anything remotely related to joining forces could possibly result in a new, proper, conceptually prepared project (name), which would then be co-maintained by experts in this domain.

Thoughts?

Comments

silverwing’s picture

silverwing commented

howsabout "Backup Snapshot" :)

I use backup and migrate on my sites because it does what I need it to do.

I never considered "Demonstration site (Sandbox / Snapshot)" simply because I don't have a demonstration site or sandbox.

It would be nice to see one module for this for D7 though. As a user, I can see the value in that.

Shai’s picture

Shai commented

One thing the two modules have in common is that they both of usable (mostly) D7 versions right now! I'm running both of them at a sandbox site I've set up: http://d7sandbox.net. Great job folks...

I'd happily be an early tester for any efforts at a combined module.

Shai

FreeFox’s picture

FreeFox commented

More maintainers on a project is (imho) better but more difficult to organize. Since both do nearly the same, efforts to combine shouldn't be that big ;)

If in Backup & Migrate there was an option to schedule a restore, that would be a nice first step. Also maybe the possibility to backup/restore database & files with 1 job and 1 schedule?

It's just my 2 cents ^^

Greetz
Jan

ronan’s picture

ronan commented

Hi there,

Thanks for writing this note and sorry it has taken me so long to get back.

I agree that we're certainly tackling the same problems and have much to gain by combining forces on this. Do you have any ideas on how that would be structured? Are you thinking we'd just combine the two modules into one (with a better name :)) and deprecate the other modules?

I've been aware of demo for some time too but haven't until quite recently thought of it as a duplication because of the difference in focus and intended audience, but as I've added features to this module and you've added features to Demo, the two have come closer and closer together. I suspect either one of us is just a few lines of code away from replicating the functionality of the other's module completely :)

I've stayed away from a scheduled restore option in Backup and Migrate in the past for a few reasons. Firstly the need seemed to be adequately covered by the demo module which was a much clearer and simpler way to set up a demo/sandbox type site. Secondly I've tried to keep the module as simple as possible (though I'm afraid that goal may have slipped away from me) and thirdly it seemed like a very dangerous option to keep around for the majority of users, especially new ones. Accidentally backing up your database is no big deal but accidentally restoring...

At any rate, let's talk about ways to move forward and pool efforts on these modules. Seems silly for both of us to be writing separate phpMyAdmin clones if we can find a sensible way to combine those efforts :)

traviscarden’s picture

traviscarden commented
Title: Join forces? » Join forces: Demonstration Site and Backup and Migrate?
Issue tags: +duplication of effort

Allow me to give this a little "bump". I agree with everything that's been said—these two modules are addressing extremely similar needs with a great deal of overlap, and the names could use improvement, for clarity and findability. Combining and deprecating seems like a wise direction to go.

A New Name

Both modules make a backup of the database (as opposed to the Backup module, for example, which includes the file system), so perhaps the name should indicate that. Both modules can restore that backup. Where you plan to restore or why (e.g. for migration or not) may be immaterial. Perhaps a name like "DB Backup and Restore" or just "DB Backup", with a system name of db_backup for brevity, would serve well. It clearly indicates the functionality and its scope without implying a specific use case.

Comparative Analysis

Each of these modules does a lot, and it seems like they're doing more all the time. Perhaps a comparative feature analysis is in order, to help identify duplication. I won't presume to undertake an exhaustive analysis, but here are a few things that stand out to me as a user.

I hope this issue gets some more attention. I think it's a great idea. (Thank you, @sun, for initiating.)

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Version: 6.x-2.x-dev » 7.x-2.x-dev
Priority: Minor » Normal
Issue tags: -duplication of effort

As stupid as it may sound, I believe the very first step is to come up with a solid module name and project name. Focus on the former, as it also implies to find a namespace that's still available. You can ping me on IRC for brainstorming.

I'm all for doing this merger, and might be able to work on the actual code. Related to that, I'd see the following key goals:

  • Clear and solid separation between API, UI, and add-on functionality, in separate (sub-)modules.
    • For example, Demo itself doesn't provide the reset functionality in the main module. It's in a separate demo_reset module (but same repo/project/package), which provides all bells and whistles for typical demonstration sites and can be improved on its own.
    • Scheduled backups are a use-case specific feature as well, so separate sub-module.
    • The main module is a pure API module, the core functionality for performing dumps, archives, and imports/restores.
    • The API functionality allows for many different UIs; provide a simple default one in a *_ui.module.
  • Use OO to implement API functionality for different storage systems.
  • Maximum compatibility with native/other tools.
  • D7+ only.
  • Leverage and extend as many Drupal core APIs as possible.

Especially critical issues like #772678: Database default collation is not respected (which I'm not sure whether BaM already caters for) are the topmost reason for why it simply doesn't make sense to duplicate efforts. That issue alone took months to debug and resolve, and adapting Demo module for it wasn't particularly easy as well... So what I'm after on a higher level is kind of a "storage tool squad", centralizing and sharing knowledge, reviews, and expertise.

The only "requirements" I'd have are the Best practices for co-maintaining projects.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

I've just contacted the owner of http://drupal.org/project/snapshot to ask whether he/she would be willing to give away that project/namespace, as most of its functionality is contained in Drush itself, and I think that would be one of the most ideal project names.

However, pretty please post better suggestions if you have some ;)

patoshi’s picture

patoshi commented

how about: save point!

just throwing out ideas.. ;)

traviscarden’s picture

traviscarden commented

I think "backup" will probably be an important keyword for findability for the module. I just have a hunch that the vast majority of users will use it primarily as a backup solution. If you're considering repurposing a namespace, sun, Backup might actually be one to consider. It's succinct and obvious, and it's abandoned, with only 224 reported 5.x installs. The only drawback, as I see it, is that the name "Backup" doesn't encompass the demonstration site functionality... but you could always use the backup project name and a longer project name, like "Backup/Snapshot", or whatever seemed appropriate.

traviscarden’s picture

traviscarden commented

Anyone given this any more thought?

eMPee584’s picture

eMPee584 commented

.."Site Backup"? "Safe Haven"? "Data Vault"? "Foo Bar"?
...happy new year folks! C:

shaiss’s picture

shaiss commented

What happend here? Did this effort die or continued elsewere? This is very exciting as I'm a B&M user but don't see how B&M backs up my files/modules ect. If my host dies and I have a B&M backup, I still have to reinstall my d7 site, install all modules, then restore my backup from B&M. sounds to convuluted where as Demo creates one file that can easily be reused with the demo profile to setup the new site.

izmeez’s picture

izmeez commented

Backup_migrate and demo have one significant difference. The demo reset restores the database over writing any changes that have occurred since the snapshot was taken and removing any new tables. Whereas, backup_migrate restore does not get rid of any new tables that were created since the backup. This makes backup_migrate unsuitable for testing purposes.

couturier’s picture

couturier commented
Status: Active » Closed (outdated)