• Resolved mkj2

    (@mkj2)


    Hi,
    we love your plugin, but recently we have a lot of trouble. Today, I found that sometimes old archives are not deleted from the dropbox account. I’ve just tested it manually. The plugin is set to keep 6 archives. I triggered a backup manually. Now I have 7 archives in my account, which will, of course, soon exceed the storage limit. The error log doesn’t show any errors or warnings.

    The only difference to an instalation that is perfectly working: we don’t use a folder in the destination path. So, the destination path is empty. Again a bug? Please, let me be wrong. We had enough trouble with the new tracking feature. For weeks, the backups didn’t work. And then we had do delete all old archives manually.

Viewing 15 replies - 1 through 15 (of 15 total)
  • Hi @mkj2, are you using 3.4.1? We made sure that this functionality works properly. Is your archive name formatted with the proper prefix?

    Thread Starter mkj2

    (@mkj2)

    Hi,
    yes, I’m using 3.4.1 and WP 4.8 / PHP 7.0. The prefix is: backwpup_0878f702_daten_%Y-%m-%d_%H-%i-%s

    Seems to be fine, isn’t it?

    Yes, and all archives in your Dropbox are of the same format, and the same job? For instance, i see this is job #2, so it will only limit its own files. If you have a job #1 saving to the same folder, it will not delete those, but job #1 will.

    Thread Starter mkj2

    (@mkj2)

    Yes, they are of the same format. Here are two screenshots for the settings and the dropbob folder:

    You can see, that the number of archives is set to 2, but 4 archives are in the dropbox account.

    Hi @mkj2, just to narrow things down, can you try putting a folder name in and seeing if that works?

    Thread Starter mkj2

    (@mkj2)

    Unfortunately, that’s what I thought. If I put a folder name in the path input field everything works fine. This is REALLY bad. In a few days ALL dropbox accounts will exceed the 2 GB limit. So, again I have to delete the files AND have to put in a folder name for all installations. This means hours of (unpaid) work. Thanks for the prompt support, but this is really disapointing

    Hi @mkj2, not necessarily. I was simply asking that to help debug. I have tested this on my own system and am able to keep the folder name blank, while having the plugin still delete old files.

    Let me check into it more. If you want this to be fixed faster, you can also grant us temporary access to a user with the BackWPup Admin role, plus FTP access, You can email that to support [at] backwpup.com. That’s the fastest way to resolve this. But either way I will try to reproduce this, but so far have not been able to.

    Hi @mkj2,

    I’m testing this on my own personal system and am not seeing these problems. I emptied the folder, and set the maximum files to 1. Then I ran the job twice.

    First run: https://www.dropbox.com/s/henhd5uy81zqolm/Screenshot%202017-07-14%2010.52.30.png?dl=0

    Second run: https://www.dropbox.com/s/k4x8f46gcorgjzr/Screenshot%202017-07-14%2010.53.15.png?dl=0

    So it seems something else is going on with your system we have to figure out.

    As I said above, we can investigate faster if granted access to your specific system. You can email support [at] backwpup.com to send login credentials.

    If you’re familiar enough with code to debug, I’d insert this line above line 313 of inc/class-destination-dropbox.php to help debug:

    $job_object->log( count( $backupfilelist ) . ' backups found' );

    That’ll tell if it is detecting all the backups that are in your folder.

    Thread Starter mkj2

    (@mkj2)

    Hallo,
    thanks a bunch for the great support. I inserted the debug code. The log says: “0 backups found”, which is wrong, of course, since 6 backups are in the dropbox account. The other job (that uses a folder in the upload path) counts correctly 3 backups. We have this problem with all installations where we don’t use a folder name. It is not specific for this single installation.

    Thanks @mkj2 for that information. That does help.

    A few other questions:

    1. Are all sites which aren’t working properly on the same host/server?
    2. Is your inc/class-destination-dropbox.php exactly the same as the one found here? https://github.com/inpsyde/backwpup/blob/master/inc/class-destination-dropbox.php

    Thread Starter mkj2

    (@mkj2)

    Yes, all sites are on the same server and have a very similar configuration. I’ve just deleted all old backups and renewed the dropbox authentification. Voilà, now it’s working. So something seems to be wrong in this constellation:

    – new backwpup tracking system
    – no folder name in the upload path
    – existing authentificaton.

    This is small comfort, since I will have to get new authentification codes und probably have to delete the old archives. That’s a lot of work.

    Hi @mkj2, very interesting. I will look into this further to see if there could be a good reason for that and a way to work around it. I’m glad it is working for you though.

    Thread Starter mkj2

    (@mkj2)

    Well, I wouldn’t call this a “working” solution. This will take hours of (unpaid) work. And it doesn’t make sense to renew an authentification that is indeed working fine.

    Hi @mkj2, I understand your frustration. I have offered you the option of giving us temporary access so we can directly debug on your system. This is a very hard bug to investigate since it relies on having an old authentication from before the upgrade, or at least it seems so.

    If you give access, this should be fixed within a day or so.

    You can email support [at] backwpup.com with the information if you’d like to do this.

    Hi @mkj2, if I’m not mistaken, I think we fixed this in support, so I’ll mark this as resolved. Let me know if there are any outstanding issues.

Viewing 15 replies - 1 through 15 (of 15 total)
  • The topic ‘Old archives are not deleted’ is closed to new replies.