the list size is not the logfile size. It is the size of the backup archive.
that wasn’t my issue — the issue (stated as the thread topic) is that it is not actually deleting the old logs first — it is keeping the oldest and just the single most recent. also, that most recent one is unlike those old ones — it is very short, is classified as “log only,” and contains no detail (as shown). the old ones have lots of detail and were classified as “DB Files.”
here’s one of the old logs:
2013/03/05 03:14.48: [INFO]: BackWPup version 2.1.17; WordPress version 3.5.1; Copyright © 2013 Inpsyde GmbH Author: Daniel Hüsken
2013/03/05 03:14.48: [INFO]: BackWPup comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions.
2013/03/05 03:14.48: [INFO]: BackWPup job: 1. daily auto 3am; DB+FILE
2013/03/05 03:14.48: [INFO]: BackWPup cron: 0 3 * * *; Wed, 6 Mar 2013 @ 03:00
2013/03/05 03:14.48: [INFO]: BackWPup job started by cron
2013/03/05 03:14.48: [INFO]: PHP ver.: 5.3.8; apache2handler; WINNT
2013/03/05 03:14.48: [INFO]: MySQL ver.: 5.5.28
2013/03/05 03:14.48: [INFO]: curl ver.: 7.21.7; OpenSSL/0.9.8r
2013/03/05 03:14.48: [INFO]: Temp folder is: C:/[...]
2013/03/05 03:14.48: [INFO]: Backup file is: C:/[...]
2013/03/05 03:14.48: 1. try for database dump...
2013/03/05 03:14.48: Dump database table "wp_commentmeta"
2013/03/05 03:14.48: Dump database table "wp_comments"
2013/03/05 03:14.48: Dump database table "wp_jp_advancedrss_cache"
2013/03/05 03:14.48: Dump database table "wp_jp_advancedrss_templates"
2013/03/05 03:14.48: Dump database table "wp_links"
2013/03/05 03:14.48: Dump database table "wp_options"
2013/03/05 03:14.49: Dump database table "wp_postmeta"
2013/03/05 03:14.49: Dump database table "wp_posts"
2013/03/05 03:14.49: Dump database table "wp_subscribe2"
2013/03/05 03:14.49: Dump database table "wp_term_relationships"
2013/03/05 03:14.49: Dump database table "wp_term_taxonomy"
2013/03/05 03:14.49: Dump database table "wp_terms"
2013/03/05 03:14.49: Dump database table "wp_uam_accessgroup_to_object"
2013/03/05 03:14.49: Dump database table "wp_uam_accessgroups"
2013/03/05 03:14.49: Dump database table "wp_usermeta"
2013/03/05 03:14.49: Dump database table "wp_users"
2013/03/05 03:14.49: Database dump done!
2013/03/05 03:14.49: Add database dump "wordpress.sql" with 3.6 MB to backup file list
2013/03/05 03:14.49: 1. try for make list of files to backup....
2013/03/05 03:14.54: 2946 files with 96.2 MB to backup
2013/03/05 03:14.54: 1. try to create backup zip (PclZip) archive...
2013/03/05 03:15.27: Backup zip archive create done
2013/03/05 03:15.27: Archive size is 58.48 MB
2013/03/05 03:15.27: One old log deleted
2013/03/05 03:15.27: Job done in 40 sec.
[Moderator Note: Please post log files between backticks or use the code button.]
Found and fixed for next release.
i upgraded a couple times since you said it was fixed (now at 3.1.1) and the behavior is exactly the same. i no longer see a caption that says oldest logs will be deleted first, did you “fix” this by just deleting that caption? or do i need to manually delete my 49 old logs before the fix will work?
also, just noticed that on the “backups” page, i have 606 items. i like everything to be on one page, so that’s fine with me. but it says there are 31 pages of items — each page shows all 606. under “screen options” it is set to show only 20 at a time, seems to be confused…
Can you send me some screenshots? Mail it to d dot huesken at inpsyde dot com
ok, i mailed you.
for the public record:
now it looks like my logs have been working correctly since feb 21, i
must not have gotten the upgrade earlier than that, even though i
thought i had. thanks for the fix!
i sent screenshots showing the pagination issue of the backups that
i mentioned. all 31 pages have all 612 items, even though it’s
supposed to be paginating every 20. (minor issue — i actually prefer
having them all on one page).
-e
The pagination bug is fixed in the next release thanks @eflister
