Hi. I've been using backup and migrate on a drupal 6 site for a couple years. I am now currently developing a drupal 7 ubercart site and I'm having problems getting it to work.

I'm simply trying to backup the database to my local computer.

1) Go to admin/config/system/backup_migrate
2) Backup from [default database] to [download] using [default settings], click "Backup Now"
3) Browser status shows "waiting for mysite.com....".
4) Page reloads, but no dialog box appears allowing for the file to be saved. Seemingly nothing happens.

I tried the advanced backup page with same result. I uninstalled version 7.x-2.7 and installed the latest dev version. No luck.

There are no error messages either on the screen or in any logs.

I don't seem to be having any problems backing up the database directly from phpmyadmin.

Any idea what might possibly be causing this or any advice on steps I can take to troubleshoot?

Comments

totocol’s picture

I seem to be experiencing same issue since migrating to this version. Also no logs to troubleshoot if something is going on - scheduled backups seems to be working well

callumm’s picture

I thought I would chime in because of the recent-ness of the latest comment. I installed the module at version 2.7 and everything was working fine as of August 08, but a week later, after few changes and none related to the module, the Dropbox backup is not working, page simply reloads. If backup to download it does work.

ronan’s picture

Issue summary: View changes
Status: Active » Postponed (maintainer needs more info)

Is this still happening in the latest version?

Gyver06’s picture

Yes for me, latest version does change nothing unfortunately.

bdyerstewart’s picture

I think I'm having the same problem - seems to be related to file size and php version.

I am in the process of moving a site to a new server and so, have the same site on different servers, with different urls pointing to them. On the new server, the backup seems to be in progress (rotating icon in FF tab) but stops sooner than expected and doesn't deliver the backup anywhere (have tried download, onsite destination and remote ftp). On the old server backup runs and delivers. There's no error message on the new server that I can find (nothing in Drupal, nothing in the server's error logs)

The old server is running php 5.3.27; the new server is running 5.4.22. The backup is fairly large - 40M. If I set up a profile that takes a single table or small set of tables, it backs up and delivers the backup with no problem.

Thinking that it might be a difference in configuration (timeouts, etc), I adjusted the php.ini and my.cnf files on the new server to match the old server and re-started the new server, but the same problem ensued.

I tried a large backup from a different site on the new server and have the same problem.

I tried the dev version and get the same problem.

Could there be some issue with php 5.4.22, a different configuration variable or something in code?

bdyerstewart’s picture

Would commenters 1 through 4 identify what version of php their running? Does backing up a single table work? Thanks

ihagerm’s picture

My situation was almost identical to #5 (no errors were thrown, etc) and I'm running PHP 5.4.26. I was able to resolve the issue by truncating the watchdog and the event_log tables which had grown quite large (db size went from about 60MB to 3MB).

JMH’s picture

I recently moved to a new server and have the site up and running with no errors.

However I have a similar issue, I have a specific account with backup permissions.

This account mirrors the behavior describe above, page cycles but nothing happens.

I logged in as the root drupal admin. Then went to Configuration>Media>File Systems checked the private and temp locations, which were correct. I saved anyway to confirm.

Tried the backup and it worked. I didn't change any settings, only pressed save in the file systems page. I then logged in as the backup only account and it works.

I will keep monitoring it to see if this stops again but hope this helps.

bdyerstewart’s picture

ihagerm, it's definitely related to size. I exclude cache table data, watchdog, etc but have lots of nodes and content that I need backed up and it fails if the size is too large. The db (with data excluded) that I'm trying to back up is about 45MB.

JMH, I tried what you describe in #8 but it made no change for me.

johntang’s picture

The same with this issue, no errors, no log, I'm using Nginx server, I was tried to chmod 777 for temp folder, private folder still no effect, just waiting page.... schedule still not working. I'm use latest version of BM.

bdyerstewart’s picture

johntang

What version of php are you running and how big is the backup (if you create it from phpadmin, e.g.)?

Trying to see if it's related to PHP 5.4

Thanks

xaris.tsimpouris’s picture

I have php 5.3 but I a experiencing the same thing. Neither download, nor email seems to get the job done.
It is not tie related issue, at least for me, as page refreshes just fine with no errors and with classic message like "Default Database backed up successfully to *************** in destination ************* in 39670.56 ms. (, , )"

I am using version 7.x-2.8

Update: Moving to version 7.x-3.0 corrected the problem

muranod’s picture

I just started having this problem. I made a successful backup on 7/14, but can no longer make one. I tried to make one before updating my modules and core today, but it would not work. I am running php 5.3.28. Should I upgrade that, and if so, how do I do that on the live server? Running 7x2-8 of the module.

Trying 7.x-3.0 now. *SUCCESS*

That fixed the problem, but I'm wondering why the "Available updates" page did not show version 7.x-3.0 as being available?

BTW, xaris.tsimpouris, thanks for posting the update. It saved me a lot of time.

mehrdad zadehebrahim’s picture

After defining private file system directory, It stopped working for me - I dont know why, but the older version works fine.

couturier’s picture

Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

Newer versions of the module have resolved this issue.