Posted by jbc on August 11, 2007 at 9:02am
Jump to:
| Project: | backup |
| Version: | 5.x-3.0 |
| Component: | User interface |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
backup_files(): Command 'tar cfz /tmp/backup-htdocs-ij2lDk index.html includes themes scripts profiles sites misc modules .htaccess index.php update.php install.php cron.php xmlrpc.php INSTALL.mysql.txt MAINTAINERS.txt CHANGELOG.txt LICENSE.txt php.ini files images UPGRADE.txt INSTALL.txt robots.txt INSTALL.pgsql.txt favicon.ico firestats updates backup garland_favicon.ico drupal-backup-db-20070811095558-191434866.sql.gz ' returned value: 2
In spite of this error message, it also reports Database backed up successfully.
Comments
#1
I receive the same messages. There is an sql backup created, but not an all files tar file.
#2
The message is not helpful, because all 'tar' is returning is "Something went wrong"
Search a little http://drupal.org/node/144588
Some reasons people have found include:
- File already exists
- No permission to create file
- Recursive bundle (saving target inside the source directory structure)
- No permission to 'touch' file date (Win32)
What you must do is Copy that full command and run it from shell (as web user if possible) - see if you can actually see the error message that tar is hitting.
#3
Backup has worked very quick with me, but not very thorough. It looks like the database was dumped, but no files. I got a message in red where several files were mentioned, and also a link to the site for when 'you see red', but it is like someone asking you: Do you like fish? And then points to the ocean.
#4
This happens because it tries to backup files that aren't readable. The backup module temporarily chmod's the files from a previous run (presumably) so it doesn't include the older archives in a new archive. Eg:
www-data@host:/usr/share$ ls -l drupal-5.7/sites/host/files/backups/total 3540
---------- 1 www-data www-data 2270034 2008-04-03 19:35 drupal-backup-db-20080403150747-932232237.sql
---------- 1 www-data www-data 38415 2008-04-05 11:42 drupal-backup-db-20080405104201-799469769.sql.gz
---------- 1 www-data www-data 38688 2008-04-06 02:08 drupal-backup-db-20080406010818-883937904.sql.gz
---------- 1 www-data www-data 38842 2008-04-06 02:24 drupal-backup-db-20080406012451-905465726.sql.gz
-rw------- 1 www-data www-data 38898 2008-04-06 02:32 drupal-backup-db-20080406013237-741629493.sql.gz
Here is the code in question (in functions.inc.php):
<?php
//
// We might get errors reading older backups, because I had to set their
// permissions to 000 to keep them from being included in this backup
// when the directory where the backups are being written is not the same
// as Drupal's root directory.
//
// So, if any returned lines have the names of errors in them, we can just
// ignore those lines.
//
while ($line = fgets($fp)) {
if (!backup_is_backup($line)) {
form_set_error("", $line);
}
}
$retval = pclose($fp);
if ($retval != 0) {
$error = "Command '$cmd' returned value: $retval";
return($error);
}
?>
I'm fairly certain this used to work, or at least fail silently, so there may have been some change in tar's behaviour. I am using Ubuntu gutsy with tar 1.18-2ubuntu1
The archive is still created correctly in /tmp but doesn't get renamed and moved into the backup destination dir.
As a temporary workaround, you can simply comment the return line like so:
<?phpif ($retval != 0) {
$error = "Command '$cmd' returned value: $retval";
//return($error);
}
?>
#5
Changing title so it's useful!
#6
I have two Drupal installs for the same client that are very similar... similar modules, theme, etc. I get this error on one site, but not the other. The site I get the error on is hosted by GoDaddy (yay for domains, boo for hosting) and the other is a more vanilla "CPanel" type.
Since the error I get is on the GoDaddy host, I am wondering if its a permissions problem or maybe there is something weird with the config?
Not sure if this helps, but its more info!
regards,
Ron
Custom Drupal Websites
#7
I started having this problem when I moved my drupal installation from a subdirectory to the main directory of my website. I use godaddy as well, and it looks like the problem is with permissions on a particular folder in the main web directory. I excluded the 'stats' folder from the backup by changing line 137 in functions.inc.php from
<?phpif ($file == "." || $file == "..") {
?>
to
<?phpif ($file == "." || $file == ".." || $file == "stats") {
?>
I also added additional folder restrictions to this list so my test sites located in other sub directories are not included in the backup, either...
#8
resolved by version update