I have not completed testing -

This is a problem I have had more than once.

Linux Server. - I set the backup method to Tar > tar.gz., saved settings.

The paths to tar & gzip is known to be correct (default).

 [code][root@localhost /]# ls -l /bin/tar
-rwxr-xr-x. 1 root root 320968 Sep 26  2011 /bin/tar
[root@localhost /]# ls -l /usr/bin/gzip
lrwxrwxrwx. 1 root root 14 Sep 11  2013 /usr/bin/gzip -> ../../bin/gzip
[root@localhost /]# 

It seems random (although I have a new working (untested) theory.

Sometimes instead of Backup.pm creating a (backup_string).tar.gz file, it will instead create an uncompressed (backup_string).tar file.

EVERY time this happens two other things happen (as far as I can tell)

1. I will get a 504 Gateway Timeout error.

2. When I get back to AdminIndex > YaBB Backup, there will ONLY be an option to run a Full Backup, the Incremental Backup Option is not displayed. (this one I'm quite sure I know why) - Although YaBB shows the backup, YaBB does not actually KNOW it completed (as the session timed out) ONE issue psuedo-resolved. YaBB displays the backup because it enumerated the folder, and the backup fits a file pattern.

NOTE to all - IF you get a 504, DO NOT REFRESH - the URL is still the action-script URL, YaBB will run another backup.  

This just occurred on the Test Server. I do have a working theory on this, so no need to test until I 'trial balloon' my theory.

Hello

JonB wrote on Mar 19^th, 2014 at 11:14pm:

You must break the Server Timeout and split the Backup produce ....
Like this small free script (sorry it's a german script) take a look of the variable $durchlauf

lg XTC

OK I have done some extensive backup testing on both installations of 2.6.0 using the 1450 build.

Conclusions:

A. The Backup settings you save work as described, but there is a lot to know about how and what you are going to get as a result.

B. The Backup process itself works correctly almost 99% of the time. that should be read 'you will get a good backup as described' - although YOU may not know it at the time.  Just let it run in that window, and DO NOT CLOSE OR RELOAD the page the backup job is running on.  For YaBB Backup to work correctly, it must be able to continuously update the URL in that browser window, period.  As soon as you change the URL, the backup is toast. (I have a workaround for monitoring it)

C. Depending om the method chosen, the time required for a backup to run can differ in the 100's of percents. like up to 8 or 9 times as long from fastest to slowest. The size of the backups can differ almost 2 or 3x as well.

D. Whether the 'timing' script for the Backup Window itself works right, works half-assed or CGI-time-outs on you is a function of the browser used and how well it handles the Javascriplet that does that function. SO you may be 'in the know', 'poorly informed and curious', or 'in a freaking panic'.

E. THE WORKAROUD!
1.  Chose What to backup and the backup method - Make your choices, Save the settings.
2.  Click EITHER Run Full Backup OR Run Incremental Backup
3.  NO MATTER WHAT HAPPENS (OR DOESN'T) Leave it alone (see above).
4.  To Monitor the backup -
     -- Move your mouse up to 'Return to Admin Center'
     -- Right Click > Select Open in New Window or Open in New Tab
     -- Move to the new Window/Tab
     -- Click on YaBB Backup in the New Window
     -- You will see the current size of your new job that is running
     -- You CAN safely refresh this page to monitor the job..
     -- When the Backup stops growing, return to the original page.
     -- At the top you will see how many seconds the job took to run.
         (If you got a 504 Gateway Timeout - close the original window)
         (If you refresh the original window manually, you will likely create
           a new backup job.)

And that is it folks -


- where to click
- beta-backup-on-xeon
- beta-backup-on-HP