[backup_migrate] Backup and Migrate

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

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!

@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.

@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!

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.

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

More accurate status, the port needs work.

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.

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.

@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

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

@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)

@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.

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.

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

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.

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.

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

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.

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).

@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.

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

@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.

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

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

Doh. Sorry.

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.

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

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.

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).

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.

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.

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.

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.

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.

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.

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.

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?

@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.

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.

@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?

@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.

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.

@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.

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.

@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.

@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.

@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.

@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.

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.

@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?

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?

Hi all,

Once again I apologize for the lack of activity. I intend to cut another alpha release some time prior to DrupalCon.

There is a lot to get done and I'll prioritize critical bugs but beyond that is there any functionality I should be concentrating on? What would make people's lives easier in the interim?

Thanks again for all of the patience.

Ronan

Isn't this critical because of data loss when using 8.x-4x.0-alpha1? I think there should be 8.x-4.0-alpha2 without any new functionality, only fix to the file corruption problem.

I have installed Backup and Migrate : 8.x-4.0-alpha2. I tried to backup entire site, I get fatal error displaying, "Fatal error: Call to a member function create() on null in C:\xampp\htdocs\drupal-818\modules\backup_migrate\vendor\backupmigrate\core\src\Source\MySQLiSource.php on line 48"

A suggestion is appreciable.

Thanks.

Have you checked https://www.drupal.org/node/2732195 ?

Thanks for the response, ronan. Please note that the alpha 2 version is failing to work for some users. Please try committing the following patch: Fatal error: Call to a member function create() on a non-object in backup_migrate\vendor\backupmigrate\core\src\Source\MySQLiSource.php on line 48

I am keeping the status of this issue at critical as changed by tormi in comment #59. To date, nearly 1,000 new downloads of the error-producing alpha 2 version have occurred since April 4, 2017. In comment #58 ronan asked:

. . . Is there any functionality I should be concentrating on?

For now, a stable, working release with even the most basic functionality would be valuable! The only alternative module for D8 is dependent upon Composer which some of us either cannot or prefer not to use. Going forward, any backup module that is usable apart from Composer will be popular given the lack of alternatives.

Hi guys,

I tried to install it via composer, but got the following error:

$ composer require drupal/backup_migrate

Using version ^4.0@alpha for drupal/backup_migrate
./composer.json has been updated
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - drupal/backup_migrate 4.0.0-alpha1 requires backupmigrate/core dev-master -> no matching package found.
    - drupal/backup_migrate 4.0.0-alpha2 requires backupmigrate/core dev-master -> no matching package found.
    - Installation request for drupal/backup_migrate ^4.0@alpha -> satisfiable by drupal/backup_migrate[4.0.0-alpha2, 4.0.0-alpha1].

Potential causes:
 - A typo in the package name
 - The package is not available in a stable-enough version according to your minimum-stability setting
   see <https://getcomposer.org/doc/04-schema.md#minimum-stability> for more details.

Read <https://getcomposer.org/doc/articles/troubleshooting.md> for further common problems.

Could you make backupmigrate/core available for composer?

Thx a lot
Andreas

@Schoenef the best alternative module for creating backups in Drupal 8 is already dependent upon Composer, Backup Database, so I recommend you look into switching to it. Or you may want to follow this issue that has been created already here.

The alpha 2 version is working for me on my test site 8.3.0. But since the scheduled backups of the D7 version have saved our production site twice from damage I would never live without a fully supported D8 version. Relying on composer is also not an option for me.

The situation is looking good for Drupal 8 Backup and Migrate with the release of Alpha 2. It is basically functional now and working for most users.

Composer

The 8.x-4.x-alpha2 release still doesn't work with Composer, but a solution has been offered here. In previous comments, the Backup Database module which is already dependent upon Composer has been recommended as an alternative to users needing something compatible with Composer, but I opened an issue based on Comment #41 above that only the dev version of Backup Database appears to be working, not the currently recommended release. Several users of Backup and Migrate are still requesting that this module avoid becoming dependent on Composer in Drupal 8.

Major Open Issues

About 30 open issues are in the Backup and Migrate queue at the moment. Only a few of them critically affect some users, and these I have listed in the updated summary at the top of this page. Among those listed in the summary, the Fatal error when attempting to backup the entire site should be fixed as soon as possible. Also, PHP 7.1 in MAMP Pro breaks backup and UTF8 is not supported by the MySQL server should be addressed before the release of the next alpha if possible.

Port to Drupal 8 Complete?

It appears that the port of Backup and Migrate to Drupal 8 has two threads running, this primary one as well as an older Port Backup_Migrate to Drupal 8. I am recommending we close the older issue and concentrate the ongoing discussion about development and maintenance here since the Drupal 8 version is now usable with the Alpha 2 release.

Co-Maintainer Needed

A co-maintainer is still needed, even if only to commit patches for the next release, as about 8 patches are currently sitting in the queue.

Thanks ronan

Thanks for the Alpha 2 release, ronan!

On April 20, 2017, a fixed version of Backup Database -- the best alternative to Backup and Migrate and one that is already Composer-compatible -- was released after I contacted the maintainer directly with our concerns that his recommended version was failing but the dev worked. In addition to rolling out a new release, he also responded at this issue:

The dev version [of Backup Database] was almost a complete rewrite from the original 1.0 release. Because of this I wanted to give users enough time to download and test the dev release; ensuring no critical issues emerged before giving it a release tag. Looks like enough time has passed to catch any glaring issues =). Thanks for your support of this module! Will put together a roadmap issue in the coming weeks.

Please be sure to review the previous comment for actions that still need to be taken with Backup and Migrate.

Thanks to @szeidler and @Trobing for discovering that the first two issues in my previous list (Comment #66) are both solved by the same patch. I have therefore closed PHP 7.1 in MAMP Pro breaks backup as a duplicate of Fatal error when attempting to backup the entire site.

Also take note of an interesting comment from @szeidler about Composer in one of the Backup and Migrate issues:

This issue is related to the general discussion about the role of Composer for backup_migrate . . . . Currently the github hosted library is integrated into the codebase (in the vendor folder) and does not utilize Composer in a proper way.

Please note that a co-maintainer is still needed, even if only to commit patches for the next release. The known issues listed in the summary at the top of this page should be addressed through either better documentation on the module page or through committing patches prior to the next release. About 8 patches are still sitting in the queue ready to go.

Moved to "Active" since "Needs Work" is for issues to which a patch is attached as per Status settings of issues guidelines, and this issue contains only discussion.

As of late April 2017, ronan is making a huge effort to apply patches, fix bugs and address other issues in the queue. Thank you, ronan, and we are looking forward to Alpha 3 whenever it is ready. It sounds like it will be a fantastic release! Also note ronan's comment in this issue about the role of Composer in Backup and Migrate:

. . . I'm still undecided how I will handle this in the final release. The goal of this module is to be accessible to all users regardless of technical skill or server setup. I don't think the state of Composer in Drupal contrib currently supports this. The packaging is currently awkward because I'm building with Composer and deploying the artifact to Drupal.org. If this is causing issues for Composer users (it is) then I'll change this. But I don't foresee making Composer required to install until that process is accessible to all Drupal users.

This is great news for developers who wish to avoid Composer for various reasons including limited server access in some hosting environments.

For this project the status has the following meaning:

To track a project's D8 development, the issue statuses are used as follows:

Active = No D8 port started yet.
Needs work = D8 development has started but is not yet usable.
Needs review = Project has Alpha or Beta D8 releases available for testing.
Reviewed & tested by the community = Project has Release Candidate (RC) D8 release.
Fixed / Closed (fixed) = Project has stable D8 release.

The goal is to get 100% of the projects in the list to Fixed, as quickly as possible, to help enable widespread Drupal 8 adoption.

With an alpha release available that means status should be: Needs review

Hi,

Our company, Intellix, would be tempted to offer co-maintenance for this project with a view of getting a stable release out ASAP.

However there are a couple of issues that are not immediately clear to us. One of which being how would we be able to control and/or push changes to the vendor package which is hosted on github.

While we, sort of understand the reasoning behind hosting it on github and wrap it as a core package, some details from the author would help at this point. For example how would we be able to alter the core package or what's the upstream workflow for it ?

As a practical example, how would we go, say for example if we want to update the:

protected function _getSQLHeader() or the protected function _getSQLFooter()

The only practical way we've found is by extending the MySQLiSource class like:

class DrupalMySQLiSource extends MySQLiSource

duplicate the _getSQLHeader() and do the changes over there.

This however defeats the whole purpose of the vendor package and has the disadvantage of potentially sliding into bloatware territory.

These are real case examples we've encountered while trying to contribute. Looking at the github repo it appears that there are PR's dating back to last year.

Given we manage to get some light shed on this we're happy to co-maintain and contribute.

I hope this helps.

This issue is about porting the module to D8. The discussion here should be about the process, code details should be discussed in the project itself.

Thank you for offering your services, but it is the maintainer Ronan to decide on that.
Suggest to contact Ronan about co-maintainership on d.o. and github: https://www.drupal.org/user/72815/contact

For advice on how to code create an issue in the project itself or use the forum.

Hi and thank you for the pointers.

I think a big chunk of what we're actually asking is exactly about process. Nevertheless I'll take your advice and will contact Ronan direct.

For example how would we be able to alter the core package or what's the upstream workflow for it ?

These questions should be answered by Ronan and are considered to apply about this issue.

The examples you mention are considered code issues which should be placed in the issue queue of that project or the forum. Just because you run into them while doing a port doesn't mean they are port related. Also, even though they are related to process, doesn't mean they are related to this process.

The examples I've mentioned are solely for illustrating the questions that you're agreeing are related to the port :)

I do understand where you coming from and am not expecting Ronan to go into details about the code here.

Just because you run into them while doing a port doesn't mean they are port related.

I beg to differ on the above. Of course they are port related as the port depends on a library and we're trying to find out what's the best way of contributing towards that library.

There's an offer to help port this project ( as per #32 ) and there are some things we need ascertained before moving forward.
If this is not the right way of doing it then can you kindly provide us with clear instructions of what would be acceptable ?

Thank you

Alex Andrascu, this is great news that your company is interested in co-maintainership to help speed work toward a stable release. Many developers such as myself who anticipated a smooth transition to Drupal 8 have been held back by lack of a working backup module that is non-Composer dependent. The Backup and Migrate Alpha 2 release on April 4, 2017, is the first recommended version that is workable for most users, and developer Ronan Dowling (ronan) wrote about looking toward a "final release" as recently as April 30, 2017, at this issue.

Summary of co-maintainer need for Drupal 8 port

Ronan has re-appeared in the issues queue and done much code work in late April and early May 2017. However, Ronan himself requested a co-maintainer long ago, and help is still needed. He prefers developers who are familiar with PHP OOP best practices and test writing using PHPUnit. Please keep up your efforts to contact him and find a solution to your code contribution concerns. Ronan has referenced a lack of time as to why the Drupal 8 port has progressed slowly, and DamienMcKenna in Comment #32 only mentioned the need for a co-maintainer rather than volunteering, and expressed his regret in Comment #47 that his own efforts are directed to the Metatag module, thus he is unable to help out with coding for Backup and Migrate.

How to apply for co-maintainership

I have cross-posted some of your comments to the following issue which was created 6 months ago: Add a new maintainer. Please follow the issue to make sure you catch any responses that ronan may give you there, and as mentioned above, you may contact ronan directly through Drupal.org. If you are having trouble reaching him that way, you may also try his LinkedIn page, Twitter account or current employer's contact page at Pantheon. Thanks for your interest, and please keep working to find a solution for your concerns so your company will be able to assist.

I'm still using Version: 8.x-4.0-alpha1+11-dev and had to recover from a big mess I made of things yesterday. The restore wouldn't work from the module, but the backup that I made with it imported flawlessly via phpmyadmin. Because of character set issues I had in the past, I've been reluctant to upgrade and try a newer version until I feel confident enough with all of the other Drupal 8 bits that have been throwing me off.

Also, I am really grateful that I can use this module without adding Composer to the mix.

Hi everyone.

Thank you all for keeping this thread alive and helping push this module forward.

I feel like I owe you guys some background information. Apart from an increasingly demanding workload in my day job, I've been recovering from surgery since the beginning of the year and my ability to work on side-projects has been severely limited. I am doing a lot better now and intend to dedicate a few hours a night at least a few nights a week to getting this project back on track. I understand how important this module is to a lot of people and apologize again for the lack of momentum and especially for the lack of communication on my part.

A lot of people on this thread deserve my thanks and praise for submitting and testing patches but I want to specifically call out @couturier for the tireless work managing and grooming the issue queue and this issue. This effort is hugely valuable and very much appreciated.

Look for good things in the weeks and months to come.

Ronan

Hi,

I am a real new to Drupal 8, and I love it already.

Now I want to backup my entire site with this module here.
My site is a hosted site with limited access like e.g. SSH. But phpMyAdmin is available. That Composer is not needed anymore is very helpful indeed, thanks.

When I try to Backup with the option "Default Drupal Database" or "Entire site" it get an "UTF8 is not supported by the MySQL server" Error, but the server is definitely set to UTF-8 Unicode (utf8), i double checked that.

Any ideas?

Florian

Get well soon dude

Yes... be well and... thank's a million for your efforts!

@ronan, you've done a ton of work on fixing D8 issues and put out a development release in May, but we still have people out there waiting for the official recommended release that includes these fixes. Is there any way we could see another recommended release soon with the current fixes applied? For example, see this comment:

I think it is worth to create an Alpha3 version including the fixed composer installer.

My suggestion would be to actually make the next release a Beta or release candidate, considering how far the D8 module has come toward being stable. I know that some developers are hesitant to use anything but a stable release for production sites, so the sooner we can get to that point, the more widespread the adoption of Backup and Migrate will be for D8 sites going forward.

We've had offers for a substantial amount of help if you're needing assistance. That discussion is at the Add a new maintainer issue. Thanks for everything, @ronan!

An offer from an established Drupal development team to help bring this module to a production-ready status still stands. Ronan, will you please help with this or respond in some way? We are wondering if this project has been abandoned. More explanation here: Add a new maintainer

As of September 26, 2017, a new maintainer, Alex Andrascu, has been added by Ronan. Alex and his company Intellix have offered to help bring this module to a stable release. Daniel Pickering (@ikit-claw) has also offered to help with the port. Anyone else willing to help would be welcome! This post by Alex Andrascu explains some of what he plans to do with D8 Backup and Migrate going forward.

The new Backup and Migrate maintainer Alex Andrascu has opened a Roadmap issue to discuss the shortest path to a D8 stable release as well as points related to the maintenance of the D7 branch and the future of the D8 branch. He invites everyone to collaborate in this discussion. Here are excerpts from his final comment at Add a new maintainer:

. . . I would love to have you all involved even if it's just a little thought or equally a major feature request that you think it's worth discussing.

@ikit-claw, thank you for your offer to volunteer and we'd now love to take you up on it :)

First of all let's try an put together some sort of plan. I've opened a new ticket here #2912153: Roadmap and I would encourage all of you to collaborate on it.

. . . Anyone else willing to volunteer and help us scoping out the future of this module is more than welcome.

Thank you again to everyone involved or looking to get involved.

I got install 8.x-4.0-beta3 released 12 October 2017. During installation, I get following error.

The website encountered an unexpected error. Please try again later.

Drupal\Core\Entity\EntityStorageException: 'backup_migrate_schedule' entity with ID 'daily_schedule' already exists. in Drupal\Core\Entity\EntityStorageBase->doPreSave() (line 425 of core/lib/Drupal/Core/Entity/EntityStorageBase.php).
Drupal\Core\Entity\EntityStorageBase->save(Object) (Line: 259)
Drupal\Core\Config\Entity\ConfigEntityStorage->save(Object) (Line: 364)
Drupal\Core\Entity\Entity->save() (Line: 637)
Drupal\Core\Config\Entity\ConfigEntityBase->save() (Line: 330)
Drupal\Core\Config\ConfigInstaller->createConfiguration('', Array) (Line: 134)
Drupal\Core\Config\ConfigInstaller->installDefaultConfig('module', 'backup_migrate') (Line: 75)
Drupal\Core\ProxyClass\Config\ConfigInstaller->installDefaultConfig('module', 'backup_migrate') (Line: 248)
Drupal\Core\Extension\ModuleInstaller->install(Array, 1) (Line: 83)
Drupal\Core\ProxyClass\Extension\ModuleInstaller->install(Array) (Line: 448)
Drupal\system\Form\ModulesListForm->submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 585)
Drupal\Core\Form\FormBuilder->processForm('system_modules', Array, Object) (Line: 314)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 74)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 574)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
call_user_func_array(Object, Array) (Line: 144)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 64)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 656)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

@npcoder If you would open an issue for this we could try to troubleshoot for you. Many users have been able to install this new version without a problem, so it is possible that the solution might be something local for you.

Please note that this thread for the port to D8 is close to being closed as fixed due to the help of Alex Andrascu and his team who have put in many hours of work to push this project forward toward a stable release coming soon. Thanks to everyone who has contributed!

Now that the D8 version is on an RC, perhaps this comment should be removed from the project page:

> Drupal 8 Note: A ground-up rewrite is currently underway. Follow the progress at https://www.drupal.org/node/2607038#comment-10638286

Done.