# Summary

Back up and restore your Drupal MySQL database, code, and files or migrate a site between environments. However, beware that the 8.x-4.0-alpha1 version as of December 2016 still has an open critical issue that makes the module essentially non-functional. See Comment #31 for details. Another simpler backup module has a stable release for D8, Backup Database, but it depends upon the Composer module which may be problematic for some developers.

# Project URL

https://www.drupal.org/project/backup_migrate

# Where is the code?

A partially functional rewrite is available in the 8.x-4.x-dev branch.

# Estimated completion date

Jeff Burnz noted in Comment #39 on December 23, 2016, in response to discussion of work picking back up on this module, "Can't see that, this module is dead. No updates for 7 or 8 months, D8 now 1 year old. Intentions are all good, but the lack of progress or communication is quite profound given the sheer popularity of this module." One of the problems discussed in Comments #36 through #39 is that as szeidler said, "Also backup_migrate will at some point depend on Composer. It's already using a library approach (hosted on github), but is currently built-in in the official alpha release and repository. But I'm pretty sure it will switch to a Composer-based workflow . . . ." Comment #39 points out usage problems among both experienced and inexperienced users of Composer but argues for proceeding with completion of this module for D8 even if Composer is required because this module's functionality is so essential. A question to be discussed is whether the module can proceed without a Composer dependency in order to avoid limiting the ease of use and popularity of this module.

# Dependencies

None currently but may require Composer going forward; see previous point.

# Who's doing the port?

Work is being done to rewrite the module from the ground up by ronan. A co-maintainer has been requested. Volunteers are welcome, but 'feature missing' tickets are a bit premature.

# What help do they need?

Developers who are familiar with PHP OOP best practices and test writing using PHPUnit would be helpful to continue the rewrite. On December 17, 2016, Damien McKenna requested a co-maintainer to help with the current critical issue with this module.

# D8 roadmap

No meta issue
https://www.drupal.org/project/issues/backup_migrate?status=All&version=8.x

# Background and reference information

As of December 16, 2016, according to Comment #31, the green 8.x-4.0-alpha1 version (also dev) still has an open critical issue that leads to an irreversibly corrupted database after backup and restoring. The current export process doesn't take UTF8 into consideration, which leads to a conversion of all non-ascii characters into ?. If a user is trusting the alpha version and restoring from a backup created by this version, he will probably corrupt his database.

Comments

Les Lim created an issue. See original summary.

Liu Xin’s picture

Issue summary: View changes

The version can't be use ,because if you install this module, The entire site will crash, And you must remove all the files from the modules folder manualy!So don't try it after the author renew the version

Les Lim’s picture

Issue summary: View changes
Jorge82’s picture

I have tested "8.x-3.x-dev" in Drupal 8 rc3.

backup and migrate 8.x-.3x-dev

However, happens the same to @Xin-liu. The entire site crashed.

I had to enter in my folder server and deleted the folder of the module in the "general modules folder"

Later, it works correctly again.

At the moment, we have to do manual backups of the schema and the folders of drupal :(

Regards!

swim’s picture

@Jorge82

I wrote a very simple integration for the mysqldump-php library. Might help - https://www.drupal.org/project/backup_db. Please note this only provides database export functionality.

Jorge82’s picture

@swim

It is a good help.

I understand that only makes the "backup" for the sql table. Not for the "html/drupal"folder. Isn't it?

Thank you for the help!

Regards!

couturier’s picture

Issue summary: View changes
Priority: Major » Normal
Status: Needs work » Postponed (maintainer needs more info)

I've updated the issue to reflect that work no longer appears to be progressing with moving this module to D8. Developers who cannot back up D8 sites using the command line should try the currently maintained module for D8 mentioned by swim, Backup Database.

couturier’s picture

Issue summary: View changes
miniwebs2’s picture

Used in Drupal 8.0.0 - crashed the site.
Removed the entire module folder - site returned to normal.

Dave Reid’s picture

Status: Postponed (maintainer needs more info) » Needs work

More accurate status, the port needs work.

couturier’s picture

Issue summary: View changes

Thank you for the input, Dave Reid. I have adjusted the summary to reflect that this module is intended to be eventually updated for D8 despite the fact that 8.x dev is breaking sites as of the D8 official release in November 2015:

No work has apparently taken place from January 17, 2015, to November 20, 2015, so it is assumed that maintainers ronan and dgorton would appreciate helpers to step forward, as noted by Dave Reid who moved the status to "Needs Work" in November 2015.

Early adopters of D8 may want to use a similar module, Backup Database, which is currently maintained and usable for D8.

ronan’s picture

Assigned: Unassigned » ronan
Issue summary: View changes

I have created a new release: 8.x-4.x-dev (https://www.drupal.org/node/2629226) which represents the latest work on this port. I am undertaking a total rewrite of the module. The main functionality will be broken out into a separate library (https://github.com/backupmigrate/backup_migrate_core) with the Drupal module acting as a wrapper.

Work on this port has stalled out in the last few months due to lack of time but I'll be attempting to commit more time to it in the next month or so.

In the mean time 8.x-4.x is marginally functional. There are a lot of pieces not yet ported but database exporting sort of works. I'm really posting it more to show that SOME progress has been made. Hopefully the next month will bring a real dev release.

Sorry I let the ball drop so hard on this everyone! I intend to recover the fumble, punch it into the endzone and continue to torture this sports metaphor until it gives up.

mgifford’s picture

greta_drupal’s picture

@ronan,

This is a fantastic module and top of the list for many/most of us. I look forward to a D8 version. Thank you so much for your all your contributions. Do you need sponsorship or have a tip jar?

Tyme

webchick’s picture

Priority: Normal » Major

This is probably major given the impact on site builders.

Also, I wish Drupal.org had a "Like" button for the last sentence of #12. That literally made me LOL, ronan, thanks. :D

NickWilde’s picture

@Ronan: any updates? (if it is could really use someone working on x functionality I might be interested... I loved B&M for D7 and am missing it)

couturier’s picture

@nickwilde remember you can also use Backup Database which performs a similar function and is currently functional for D8. It works fine for simple sites and is in many cases more performant.

Q2U’s picture

Sorry I let the ball drop so hard on this everyone! I intend to recover the fumble, punch it into the endzone and continue to torture this sports metaphor until it gives up.

Get up, rub some dirt on it, and get back in the game ronan!

And thank you for all of your terrific work on BaM.

iampuma’s picture

Any chance in having the `drush bb` and such support in soon? Dev version is currently working fine.

Gerhard Roth’s picture

I installed the new alpha1 version today together with D8.1.1. It needs a backup source but the list is empty. So no backup is possible.

couturier’s picture

On May 17, 2016, I installed Backup and Migrate 8.x-4.0-alpha1 on a Drupal 8.1.1 installation and achieved a backup size similar to what I receive from the Drupal 7 Backup and Migrate version on a similar site. I have no easy way to check the contents of the backup, but I am assuming that it is functioning for me.

I'd previously commented that the Backup Database module is a good alternative, but that was before I realized that this module depends on Composer Manager which is soon to be deprecated and requires command line access. The special feature of Backup and Migrate is that it facilitates backups without command line access, so I do think we should continue to go forward with polishing this module for D8.

Bojan Zivanovic commented on May 3, 2016, at this Commerce blog post that a production-ready version of Commerce will be available, "Somewhere in May, depending on payments and translation/revisioning bugs we encounter in the upcoming two weeks." A number of Drupal developers I know are holding back D8 projects based on Commerce, so I think within weeks we could see an upsurge in interest in Backup and Migrate from site developers who need help with D8 backups.

bmunslow’s picture

While Backup and Migrate is ready, I use the amazing Drupal Console for quick and easy database dumps / restores, it's as simple as:

$ drupal database:dump [arguments] [options]

Ref: https://hechoendrupal.gitbooks.io/drupal-console/content/en/commands/database-dump.html

colan’s picture

I'd previously commented that the Backup Database module is a good alternative, but that was before I realized that this module depends on Composer Manager which is soon to be deprecated

I opened an issue for that at #2779103: Stop relying on deprecated Composer Manager.

[R]equires command line access. The special feature of Backup and Migrate is that it facilitates backups without command line access, so I do think we should continue to go forward with polishing this module for D8.

What do you mean by command-line access? Do you mean that it's not possible to export the DB from the Web UI without using the command line, or that it uses the command line in the back-end to do the work? The former would definitely be a problem, but not so much for the latter.

Jeff Burnz’s picture

A heap of my sites use Node Squirrel, for that reason I really want this module to be ported to D8 so we have very easy, reliable and automated backups for the masses (like me).

couturier’s picture

@colan

Do you mean that it's not possible to export the DB from the Web UI without using the command line, or that it uses the command line in the back-end to do the work?

It's been a while since I've looked at it, but I believe it was the former unless it has since been updated to allow backups from the UI since I last checked. Like @Jeff Burnz we need something easy for the masses. I've been using this current Backup and Migrate module for D8 without any problems.

andypost’s picture

Would be great to update install instructions for current state of composer integration

couturier’s picture

@andypost This module does not currently rely on Composer Manager. I have been using Backup and Migrate version 8.x-4.0-alpha1 as my only added module on a simple Drupal 8 site, and it works great.

DamienMcKenna’s picture

I confirmed that the current 8.x-4.x branch doesn't use Composer Manager so closed #2779103: Stop relying on deprecated Composer Manager.

colan’s picture

That's a Backup Database issue, not a Backup & Migrate one.

DamienMcKenna’s picture

Doh. Sorry.

szeidler’s picture

The currently promoted green 8.x-4.0-alpha1 version (also dev) has an open critical issue since almost half an year, that leads to a irreversibly corrupted database after backup and restoring. The current export process doesn't take UTF8 into consideration, which leads to a conversion of all non-ascii characters into ?.

Once an user is trusting the alpha status, taking an backup and restoring it, he will probably corrupt his database. As backup_migrate is especially popular for shared hosting and tendentially more unexperienced users, without possibility or knowledge about using terminal commands or other backup strategies, it's an even more critical issue.

DamienMcKenna’s picture

Maybe the module needs an extra comaintainer? Anyone have some time to help out with it?

couturier’s picture

Wow! Thanks for the warning, @szeidler. I had been assuming this one was working but had never tested it. So, this means I need to switch to the Backup Database module after all for now. Thank you! Yes, @DamienMcKenna, it would be nice to continue work with this module because the alternate Backup Database is designed for simple sites and doesn't have all the functionality of Backup and Migrate.

couturier’s picture

Issue summary: View changes
colan’s picture

it would be nice to continue work with this module because the alternate Backup Database is designed for simple sites and doesn't have all the functionality of Backup and Migrate.

Or we could just add the missing functionality to Backup Database and deprecate Backup and Migrate (for D8).

Olafski’s picture

I don't agree regarding Backup Database as an alternative: The installation of the module requires Composer which on some shared hostings is difficult to install, and not everyone is familiar to use it. It should be as simple as possible to make database backups because they are so important. So, I hope Backup and Migrate will not get deprecated but find a maintainer.

szeidler’s picture

I agree that Composer is hard for beginners. But I don't see the argument with Shared hosting. Ideally Composer shouldn't run on the production server at all. Or at the very maximum only for composer install using the composer.lock file.

Nothing prevents shared hosting users from using composer locally and pushing the vendor files and modules via git (if available), rsync or ftp to the production server. It's not a optimal workflow, but it would work.

Coming back to the topic: Also backup_migrate will at some point depend on Composer. It's already using a library approach (hosted on github), but is currently built-in in the official alpha release and repository. But I'm pretty sure it will switch to a composer-based workflow once there is progress on the module development again.

Olafski’s picture

You're right, using Composer locally might be an acceptable workaround for many users, but as you say, it's hard for beginners. (Off topic: I'd like to see a Composer managing tool in Drupal itself then. Don't know though if that is even possible.)

However, if Backup and Migrate will soon depend on Composer as well, I retract my Composer related objection to Backup Database. Can't judge the quality of the two modules though.

Jeff Burnz’s picture

once there is progress on the module development again

Can't see that, this module is dead. No updates for 7 or 8 months, D8 now 1 year old. Intentions are all good, but the lack of progress or communication is quite profound given the sheer popularity of this module.

Move ahead please, I personally despise Composer, and you will be killing any hope of it ever becoming a popular module, but we need working software, so please, add the features.

Composer is hard for beginners

It's pretty easy to install and use, the problems are when things go wrong, which is quite often. People shouldn't misunderstand the push back against Composer as purely one of beginners vs experienced, I am very experienced and I hate Composer will all my soul.

couturier’s picture

Issue summary: View changes

I updated the Issue Summary to reflect Comments #36 through #39. In response to Jeff Burnz in Comment #39, I would like to add that for entry-level developers such as myself who have limited server access, a Composer dependency would restrict my ability to use the Backup and Migrate module. Backups are definitely essential, so may we discuss any possible avenues for creating a backup functionality that works without Composer? I once needed a backup to restore a D7 site, and this module for D7 worked great without any dependencies. In Comment #37, szeidler says a Composer dependency is inevitable, and I don't understand his reasons but would like to ask if there are any other possible alternatives.

eigentor’s picture

As backup and migrate did not not work for me in its current version (errors on import) I gave the backup_database module a shot. https://www.drupal.org/project/backup_db
Once you got composer installed locally, running drupal-update is no magic. Oviously one does not even need the composer_manager module for that.
And man - once you run drupal-update it updates _a lot_ of Libraries in /vendor.

But it downloads the needed library for backup_db. After setting a private file system path in settings.php - appears to be required and clearing cache, it appears to work.

Some things to know about backup_db
- use the latest dev version, the stable one did not work for me
- There is no option to truncate cache tables and other data one does not need for a db backup like in Backup and migrate.
- It does not add a .sql file ending to the backup file

But - it appears to work.
For people who do not want to update all the vendor libraries in every drupal installation: you could do it once, and after that, copy the "ifsnop" directory, which contains the mysqldump Library. At least that should be working? Have not tried it.
-- Edit--
Justin copying over the ifsnop directory to another Drupal installation does not seem to work, since it obviously is written into some composer config files on installation with composer, and else is not recognized.

So for people not shying away from Composer this might be a solution for the time being.

colan’s picture

Yes, the dev version has a newer README with up-to-date Composer installation instructions.

I'd recommend adding the above issues to the queue so that they can be resolved.

couturier’s picture

If the only way to perform backups in D8 will be dependent on Composer, whether through backup_db or backup_migrate, then for all practical purposes we have just limited the use of Drupal, version 8 and beyond, to experts with full server access, have we not? Do any potential options exist for creating a D8 database backup using a single installed module operated through the UI?

DamienMcKenna’s picture

@couturier: I'm expecting someone to come up with a way around the absurdity that is Composer so that Drupal will still be feasible for e.g. shared hosts, please don't give up.

steeph’s picture

You can still do backups externally like it is common in other CMS as well. I love backup_migrate because it gives me the ability to create an extra backup with one click before I install or change something. But to be honest, if I can't use it on those shared hosting services where I can't use composer (which are a few), it wouldn't hurt me too much. In my view Drupal isn't for small sites on cheap shared hosts anymore, if it ever was. Needing composer is something that shouldn't surprise users too much. And you can still use Drupal without composer, so I don't see it as too big of a problem.

couturier’s picture

@steeph: In my view Drupal isn't for small sites on cheap shared hosts anymore, if it ever was. Needing composer is something that shouldn't surprise users too much.

In my view, Drupal is the most powerful and secure open source software available to startups like my own and is widely used by entry-level developers who are unable to budget for proprietary software and hired assistance. That is why Drupal is so popular among users at every level of experience; it's powerful, secure and affordable. The ability to backup the database even when using shared hosting that already provides automated, external backups is important as a safety measure. I once had to provide a file from backup_migrate to restore my D7 site because my host's backup was buried deep somewhere and would have taken a long time to find.

@DamienMcKenna: Would I be correct to guess that replacing Composer with something else, despite its current level of unpopular "absurdity," will take years?

DamienMcKenna’s picture

@couturier: What I'd love to see is a GUI for building a list of files to download and instructions on where to place them for a given set of modules, shouldn't take too much effort to build. Alas right now I'm focusing my own efforts on Metatag.