# 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 March 28, 2017 still has an open critical issue that makes the module non-functional. The alpha 1 export process doesn't take UTF8 into consideration, which leads to a conversion of all non-ascii characters into ?. If a user is restoring from an alpha 1 backup, he will probably corrupt his database. The 8.x-4.x-dev as of January 2, 2017, appears to have fixed this problem according to Comment #55, so Drupal 8 users are advised to use the January 2, 2017, dev version until further progress is documented.

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 8.x-4.0-alpha1 version still has an open critical issue that leads to an irreversibly corrupted database after backup and restoring. The dev version as of January 2, 2017, has reportedly fixed this problem according to one user (Comment #55).

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.

couturier’s picture

I've heard of a new project, primary link: hedron.sh with more explanation here that could accomplish the process we need for a D8 backup_migrate module, but the problem is that Hedron too currently depends upon Composer. Testing is actively going forward in 2017 with Hedron, but it is for local dev only at the moment.

@DamienMcKenna based on what I've read about Composer, it is primarily used for local development, so users on shared hosting can simply upload the changes. Having a function like you described for backups from the GUI would be great and helpful to many D8 users! I wonder if this function would be useful for backup_migrate only or if it could also be applied to other modules, as you said:

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.

muranod’s picture

@Jeff Burnz - thank you. I agree with the difficulty using Composer. I've spent many days just getting it installed on two localhost machines, and then managed to hose one of my sites with it. I'm not a programmer; I'm just someone trying to set up a decent website with a few capabilities beyond Wordpress. Every time I encounter a major issue, like having ? marks insterted throughout my D8 backup files, I swear I'm going to switch to WP and even created a site with it, but I would so much rather use Drupal.

muranod’s picture

UPDATE - I installed the dev version (backup_migrate 8.x-4.x-dev), edited some content and did a backup. This time I am able to open the backup in a text editor and see that the question marks have NOT replaced all the dashes, quotes, apostrophes and other symbols.

Unfortunately, I have to copy and paste every piece of content from the live Drupal 7 site into this site, but since it looks like it's going to work, I will keep at it.

Just seems that this is critical and while the B/M module is an alpha version that states there are some issues, it should be pointed out that this critical issue is a possibility to avoid this from happening to others. Some people may not even be aware of it until they mess up their site and have to actually restore a backup. The question marks could even go unnoticed at first.

Jeff Burnz’s picture

@muranod - have you tried migrating using D8's Migrate module, which is part of D8 core? I've never tried it but I think that would be something to try.

muranod’s picture

@Jeff Burnz I tried when I started this project, but there were so many caveats and it seemed difficult, and then I thought it might be a good idea to redesign and start the whole thing from scratch. Would have been nice if I could have just pulled out content types or specific nodes node/types. I'm 1/3 of the way there now, and if this works when I update the DEV site on my other computer, I'll be happy. Still, I hope there are similar pitfalls awaiting me down the road - at this point in time, I'd rather spend my time creating new content.

esolitos’s picture

@muranod From what I read it seems that you want to do something you can't do anyway: You wouldn't be able to restore a D7 database onto a D8 anyway, this would simply not work.

muranod’s picture

@esolitos, I knew I couldn't do that, thought it would be great if nodes could be exported and imported into D8.

My problem was with exporting a D8 database and having the data messed up because of character set issues, making a mess of any Drupal 8 backups. Looks like the dev. backup & migrate module might have solved this (just from looking at it in a text editor), though all earlier backups of the site all have the same messed up text.

I will report back when I finish fixing all the text, export and then re-import this database into another installation.

muranod’s picture

It worked using the dev backup and migrate module - backup_migrate 8.x-4.x-dev!

The content of one node was in Portuguese and even the accented characters came through.

The backup import into dev site number 2 took about 16 minutes or more, so I had to change my php.ini settings. Hoping this won't be a problem when I set up the live site. I will also try doing it directly via mysql.

Next thing to try - migrating the configuration.

Thanks everyone! If I hadn't tried the dev. version of the module, I might still be trying to fix this or setting up a Wordpress site.

couturier’s picture

@muranod Comment #50: Just seems that this is critical and while the B/M module is an alpha version that states there are some issues, it should be pointed out that this critical issue is a possibility to avoid this from happening to others. Some people may not even be aware of it until they mess up their site and have to actually restore a backup. The question marks could even go unnoticed at first.

This critical issue is already fully explained in the overview section of this thread. Should we also ask for it to be posted on the backup_migrate home and download pages to warn users who aren't taking time to read this overview?

couturier’s picture

Issue summary: View changes

Backup and Migrate 8.x-4.0-alpha1 has had nearly 1,000 downloads since early January 2017 when the dev version reportedly fixed the file corruption problem that still exists to this day in alpha 1. We need to at least upgrade the alpha version to the January 2, 2017, dev version which @muranod in Comment #55 said worked for him. Users who are relying on the alpha 1 version for their Drupal 8 sites will probably corrupt their databases if they attempt to restore from an alpha 1 backup.

It would be fantastic to see more work done on this module for users who don't want to rely on the alternative: a combination of Composer with Backup Database which has limited functionality compared to Backup and Migrate not to mention the issues with administering Composer, especially for users without full server access.

Summary: @ronan, may we have an updated alpha?