Admin backup issues

[Djunity]

Hi All,

At the moment we are having major issue's with the admin backup function on one of or servers.

We have set up nightly backups of all user accounts and transport them true ftp to a external storage.

The ticket message in da says the backup was created succesfully but there is no file on the storage

Backup van gebruiker useraccount is voltooid. <0:07:13>

Only later in the backup procces im getting errors aka

Fout tijdens het backuppen van de database. database_twit
Fouten bij het uitvoeren van mysqldump: mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `tweets` at row: 136739


<5:10:28>
Fout bij inpakken van backupbestand reseller.admin.useraccount.tar.gz : /bin/tar: domains/domain.com/public_html/management/modules/_samples/html/assets/sample16.fla: File shrank by 49664 bytes; padding with zeros
/bin/tar: domains/domain.com/public_html/management/modules/_samples/html/assets/sample14.config.js: File shrank by 22 bytes; padding with zeros
/bin/tar: Error exit delayed from previous errors

Are these issue's connected is on the result of the other ??

We got a reseller where its own account does get created an only one user account is transported to the external storage im missing 3 user account backups from this user.

Is there any way we can track whats happening ?

 

[DirectAdmin Support]

Hello,

DA relies on return codes to determine if there are any errors.

1) In the first message, it states there were no errors... which means that both "tar" and the "ftp_upload.php" scripts returned a 0 exit status.
It's possible that the exit codes of the ftp_upload.php is wrong..
Check to see if there are any custom scripts... also check the ftp logs of the remote ftp box.
Related:
http://help.directadmin.com/item.php?id=111

There are a few different upload methods.

2) The 2nd message is not likely related to the first.
The connection was lost.. perhaps mysqld was restarted mid-backup.. or perhaps the timeout in the /etc/my.cnf is low .. not sure.

The 2nd part of the message would be due to files changing in size as the tar.gz is being created.
Usually the script/client deleting or re-saving the files often. Possiblye a temp/cache file (not sure).
If it's a common issue, you can tell tar to ignore those types of issues with this:
http://www.directadmin.com/features.php?id=792

extra_backup_option=--ignore-failed-read

John