Viewing 15 replies - 1 through 15 (of 27 total)
  • Same problem. I had to go into each job AND click the schedule tab, then save to reset it, but would love to get an answer on how to fix this.

    Still having issue where plugin deactivates on its own. Not sure if it’s related.

    Thread Starter polybearsfootball

    (@polybearsfootball)

    Same fix for me. Select the Schefule Tab and save. But then as a test I manually started and cancelled a job and it reset. Strange.

    Thread Starter polybearsfootball

    (@polybearsfootball)

    I really hope someone answers this post soon. I have no backups unless I manually run them because every time they run they reset to December 31, 1969 at 5:00.

    Thread Starter polybearsfootball

    (@polybearsfootball)

    Could anyone suggest what might cause this? I’ve checked all I can think of with no solution. Googling it shows its not just me, since I found other related post. Please?

    Same thing for me. All my daily backups stopped working on May 26 (but my weekly backups have continued just fine). I just today discovered the 1969 “next run” date on the dailys, so I just resaved the schedule tab and we’ll see what happens. This behavior was identical on three different web sites running on different hosts. All were running WP v3.5.1 (until today, now v3.5.2) using BackWPup v3.0.12. I’m anxious to see what happens after tonight’s daily run.

    Thread Starter polybearsfootball

    (@polybearsfootball)

    I have the same specs, WP 3.5.2, and BackWPup 3.0.12. I found the post below, that is a generic discussion of PHP dates reseting to December 31, 1969, but while I understand that issue, I am unaware of where in the plugin code that could be an issue.

    https://stackoverflow.com/questions/2224097/prevent-php-date-from-defaulting-to-12-31-1969

    Anonymous User 6386592

    (@anonymized-6386592)

    I have the same problem and wrote about it in another support thread: https://www.ads-software.com/support/topic/jobs-sometimes-reschedule-to-1-jan-1970?replies=6#post-4403145

    1.1.1970 is used if there’s no valid date available. Having it on December 31, 1969 means some time zone calculation took place.

    Thread Starter polybearsfootball

    (@polybearsfootball)

    Hey CoffeMick,

    I’ve found a number of threads about this, and have seen the 19070 & 1969 dates various times. I realize there is a pro version that includes support, but this seems to be happening to enough people I wish the Dev would chime in. I looked through code to find any DATE calls he was doing and nothing jumped out at me. Might have to look deeper.

    Razz

    Same problem here. I tried to solve it using the start script provided by the plugin and running it with Cron. The script has this estructure:

    #!/bin/sh
    @$1php -c "/usr/selector/php.ini" -r "define( 'DOING_CRON', TRUE ); require '/blog/path/wp-load.php'; if( class_exists( 'BackWPup_Job' ) ) BackWPup_Job::start_cli( 1 );"

    But when I run it, get this error:

    /path/to/the/script/BackWPup_cmd_start_job_1.sh: line 2: @php: command not found

    Does anyone know how to fix it?

    Anonymous User 6386592

    (@anonymized-6386592)

    My 1 Jan 1970 problem was solved when updating to WordPress 3.6 release version. I was running 3.6 RCx before.

    Thread Starter polybearsfootball

    (@polybearsfootball)

    @CoffeeMick,

    No fix on my end yet. I’m on WP 3.6, and BackWPup version 3.0.13. I thought I had solved the issue after changing the compression type, but it still fails after 1 run. This issue seems so common, the Dev not chiming in wrong. I realize this is free, and there is a paid Pro version, but seriously, if you release a free version that has such issues at least address it. I might of paid if the Dev was responsive, as I often do to show support for good devs doing strong work. In fact I love paying for good products, but the “lite” versions are supposed to convince me to buy. It’s not like this problem is a “feature” you only get in the pro version, it’s the basic required operation. How the hell do I know the paid version actually works. The complete lack of interaction makes me not want to buy, but I hope the Dev reads this and decides to help. Un-likely.

    Razz

    Same here guys, we have the problem with resetting the schedule to December 31, 1969.
    Any suggestions how to solve that?

    Please can you test the beta on https://github.com/inpsyde/backwpup. I think i have fixed it there.

    Once installed beta, got the following error:
    Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in /absolute-path-in-host/wp-content/plugins/backwpup-master/inc/class-admin.php on line 314

    Happening to me too. My backups stopped back in August and I didn’t notice. Unfortunately, something broke my database around 3.7 or 3.7.1 update time and that’s when I realized I hadn’t been getting backups.

    Restored my database..set everything up again and after only 2 backups 2 of my jobs reset to December 31 1969.

    I’ll try the beta and let you know if it is fixed there…

Viewing 15 replies - 1 through 15 (of 27 total)
  • The topic ‘Backup Job Schedule Resets to 1969’ is closed to new replies.