A backup of system files not created

Wow, that's odd behavour from tar.

Please try running the following commands from the command line and let me know what the results are:

tar --version
uname -a

That will tell me more about what you're running on your system.

Thanks,

-- Doug

I got the same error. This happened when I tried to make a 'second' backup (first one went flawlessly). I am running ubuntu 6.10
tar (GNU tar) 1.15.91
Linux localhost 2.6.17-11-generic #2 SMP Tue Mar 13 23:32:38 UTC 2007 i686 GNU/Linux

Any workarounds?

I further describe the error I am getting:

If there is no backup files in my backup directory, everything goes fine. However if I try to perform a backup and there is a preexisting backup file I get the error:

<b>Database backed up successfully.</b>
    * tar: Error exit delayed from previous errors
    * backup_files(): Command 'tar cfz /tmp/backup-htdocs-vEGHEJ files imagenes includes misc modules Openads-2.0.11 profiles scripts sites themes tmp CHANGELOG.txt cron.php cron_curl.php example_mail.php index.php install.php INSTALL.mysql.txt INSTALL.pgsql.txt INSTALL.txt LICENSE.txt mail.php MAINTAINERS.txt robots.txt update.php UPGRADE.txt xmlrpc.php huesped26 p.php .htaccess apache2-default phpmyadmin backup backup/drupal-backup-db-20070423112255-631789384.sql.gz 2>&1' returned value: 2

But the backed-up file is incomplete:

Past backups that have been made:
Backup (click to download)	Size	Delete?
Backup from Apr 23rd, 2007 11:22:20	62644679 bytes	<i><<--First backup</i>
Backup from Apr 23rd, 2007 11:22:37	1083564 bytes	 <i><<--Second backup</i>

The 'workaround' is to delete any preexising backup and then perform a new backup.

Note that this is running the same system that I described in the above comment.

I've got the same set of errors. I'm using a dedicated server from pair networks. Is there a php.ini setting I could change?

I've got the same set of errors. I'm using a dedicated server from pair networks. Is there a php.ini setting I could change?

About the same error here...
I get a 'Database backed up successfully', but always an error on the files backup with -1 as returned value:
backup_files(): Command 'tar cfz [...]' returned value: -1

The default backup directory has been tried out, and different 'external' directories with full rights;
also no difference when I try in a freshly emptied backup directory...

I was getting the tar returned -1 error on the following system:
OpenSUSE 10.1
Apache 2.2.0
php 5.1.2
Drupal 5.1
backup 5.x-2.x-dev

I modified functions.inc.php line 216 like so:

//$cmd = "tar czf $backup_tmp $file_list 2>&1";
$cmd = "tar czf $backup_tmp $file_list";

and tar stopped returning -1. I'm GUESSING that the problem is the 2>&1 of tar in pclose.
I don't know enough about pclose to be sure.

This worked for me.

-jon

I modified functions.inc.php line 216 like so:
//$cmd = "tar czf $backup_tmp $file_list 2>&1";
$cmd = "tar czf $backup_tmp $file_list";

This modification also worked fine for me...
Thanks!

I have the same problem. In my installation the problem only happens if an old backup is present. This backup somehow has the permissions 000 (no one is allowed to rwx). If I change the permissions and delete the old backup, the next backup will be run fine. Could the error occur if tar tries to access the old backup files and does not have read permission?

My 2 cents
Ulrich

Thanks to all the folks who have been reporting on this problem.

I'm not ignoring it, I'm just waiting for input from different people before I make a change that may break things. :-)

-- Doug

I have the same problem. for me it doesn't matter however whether a backup has already been made or not. even when i create a new directory called "backup", chmod it to 777 and make sure nothing in it, the error will appear.

Also, the sql file in the backup is always empty ! The sql.gz is always 20B and the sql file itself is 0B

I'll tro to change that line like why_pengo said.

why_pengo's patch worked for me too in the sense that now all files from the webroot are put in the tar.gz and give me a good backup.

However, the sql file in sql.gz is still empty :(

Okay, I have added functionality to the 5.x-3.x-dev which makes the troublesome behavior optional. And, is it disabled by default! :-)

The release should appear sometime overnight. Please subscribe to http://drupal.org/node/151077 to be kept up to date of the latest info on this release.

Thanks,

-- Doug

Hi folks,

Thanks for being patient with me on this.

I have not yet nailed down the issue, but since so many folks have had issues when performing backups with a backup directory selected, I have modified the next major release of the backup module to include a warning on that option.

The only workaround I can suggest at this time would be to not perform backups in a directory other than the root directory. Sorry.

-- Doug