Support » Plugin: BackWPup - WordPress Backup Plugin » Backup File Creation naming issue

  • Resolved nextstep


    I am getting different archive names:

    Archive name: backwpup_2do3dry135_%Y-%m-%d_%H-%i-%s

    however it says…

    Note: In order for backup file tracking to work, the archive name must begin with backwpup_ubpy9ffnl_.

    and this is the preview…

    Preview: backwpup_2do3dry135_2017-10-03_11-56-47.tar.gz

    Each time I adjust the requested backup file name ie _ubpy9ffnl_’ the other two change when I save it.

    I have attempted to reinstall the plugin, including ‘sweeping’ the database and resetting options in Settings. The first instance occurred on 28/9/17

    What needs to be done so that I get the same names for files?
    Is there a “complete” reset option?

Viewing 14 replies - 1 through 14 (of 14 total)
  • Plugin Support duongcuong96


    We have a problem issue with how BackWPUp displays the file name to user. This issue will be fixed very soon in the next release.
    Currently, you don’t need to worry about this, BackWPUp still functions really fine 🙂
    Hope that helps 🙂

    Plugin Support duongcuong96


    We just finished the fix today.

    But we’d really appreciate if you could test it out. Please download the beta here:

    Let us know how it works for you.
    Thank you very munch!


    Thanks for getting on to this.
    I first deactivated and deleted the plugin via admin on two blogs.

    I downloaded your beta file. I then uploaded the file, installed and activated it. It deleted the 2 jobs that I had. And when I set about re-creating them I noticed this from the General Screen:

    Backup File Creation

    Archive name (is “blank” but contains this greyed out text) %Y-%m-%d_%H-%i-%s_%hash%

    Note: In order for backup file tracking to work, %hash% must be included anywhere in the archive name.


    When I saved it it does this…

    Backup File Creation

    Archive name %hash%

    Note: In order for backup file tracking to work, %hash% must be included anywhere in the archive name.


    (It’s late here and I thought you might want to see this first. I’m off to bed soon, I’ll have another shot tomorrow – if that helps, Thanks again)

    Hi guys,

    I didn’t test this beta but I just wanted to highlight here for other users that even if this bug doesn’t prevent the plugin from running fine it prevents the backup archives from being deleted, if for instance you have set it up to keep only XX archives.

    And you might end up with a bunch of old archives that might create issues on shared/limited storage hosting account!

    The same happened recently with another version of this plugin and I had to manually delete old archives from all my clients’ sites at different hosting accounts + at remote storage locations…

    • This reply was modified 3 years, 1 month ago by John.
    Plugin Author Brandon Olivares


    @nextstep99, can you please test again? I’ve just committed some changes that should fix the issues you were seeing.

    @dsl225, no, I personally ensured that all old formats from 3.4.0 and later will be deleted appropriately. I had some leftover ones from a while ago to test with, and all were handled fine with the fix that was posted here.

    Again here’s the link:

    @cocreation sorry if my post was not clear enough but I stated that “I didn’t test this beta” so what I was meaning was that the problem with current published version is also this one (not deleting older version) because you stated this in your message:
    “Currently, you don’t need to worry about this, BackWPUp still functions really fine”

    BackWPup works really fine indeed but is not deleting old archives when running on latest plugin version.

    Plugin Author Brandon Olivares


    @dsl225, are you saying that 3.4.2 does not delete old backups prior to 3.4.2?

    If that is the case, 3.4.3 should fix this. I’d appreciate if you could test that so we know it is ready for release.

    Having the same problem and now it’s not deleting old backups. Will this also be fixed?

    Plugin Support duongcuong96


    We will release the new version very soon, in the meantime, could you please test it for us?
    thank you very much!
    The new version will fully backward compatibility with old version
    You can get the beta version here:

    • This reply was modified 3 years, 1 month ago by duongcuong96.

    I’ll give it a go and report back. Thanks. 🙂

    OK guys I just tested with beta version and I can confirm it deletes old archives, even those left over from previous version 3.4.2!

    For testing I kept 5 existing archives created with version 3.4.2 and prior. I then installed the beta and run with a schedule of 10 minutes and a setting to keep only 5 archives.

    All old archives were deleted and the plugin continued to create new ones and delete everything older than the latest 5.

    So yes, I think this beta version 3.4.3 seems to be ready. Thanks!

    @cocreation: yes, version 3.4.2 was (is) not deleting old archives from previous versions.


    Apologies for not getting back sooner, but I was called out away from my PC.

    I am still getting different file hash names for every job run. I have a moderately busy site so I save the database hourly because of comments by guests. Until the 28/9 my file name was…

    backwpup_1b889d02_(date & time varies)

    Now every single file since then has a random hash eg…

    backwpup_qjlprfcoy_(date & time)
    backwpup_28bupmlrsy_(date & time)
    backwpup_jj1rcdgxu_(date & Time)

    Is this to be the ‘new format?

    If so, why not just do away with the automated hash and allow users to create a file name ‘hash’ that makes sense to the user,


    Before the consistent hash identified a site (even if it was not obvious), but now with dozens of random hashes it cannot be attributed to a specific site.

    Anyway thanks for your plugin, it is most useful.

    Cheers, Dave

    Plugin Author Brandon Olivares


    Hi @nextstep99,

    As explained above, this was changed for security reasons.

    You’re of course free to add whatever you want to the filename. But the hash will be added somewhere.

    Actually it’s only partially random. It is also encoded with the actual job hash. It’s base32 encoded along with 2 random bytes to prevent unauthorized users from guessing what the backup file might be.

    So it’s not superfluous at all, and the functionality is working as expected.

    Is there any specific problem you have with it, or simply cosmetic?

    The update fixes the file deletion problem, but I really don’t like the new file naming convention. I’d like to be able to have the backups sorted by date (per the date in the file name) inside my Dropbox folder, but that can’t happen anymore because the hashes are random.

    Maybe you could have those hashes set at the end of the file name instead of the front? That way, you could still have random hashes but because the start of the file names would have the date in them, that would keep them sorted in a meaningful order.

Viewing 14 replies - 1 through 14 (of 14 total)
  • The topic ‘Backup File Creation naming issue’ is closed to new replies.