• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Issue Incremental Backup size increases

Schlaubi

New Pleskian
We discovered that plesk backups are continuously increasing and consuming more and more diskspace despite the domain content rarely changes (ignoring ~30mb MariaDB). Plesk's "Backup Manager" shows an increase of ~330mb of two incremental backups within 2 days. These diffs are shown in comp_Inc1_Inc2.jpg (left Day1, right Day2). It seems like non domain content is getting included multiple times. Purple entries are new entries, black are equal ones.
We looked a bit deeper into backup_ext_nodejs_*.tgz. Incremental backup from Day2 (right) includes the almost same backup_ext_nodejs_*.tgz from Day1 again. backup_ext_nodejs_Day2.jpg shows a hex compare with almost no diff of the Day1 tgz compared to Day2 tgz.

It looks like a bug, where the same content is included repeatedly leading to increased backup sizes. We would expect only small incremental backups. Can anyone confirm that behavior? Is there an option to exclude all these "binary backups" in incremental backups?

Environment
OS: Ubuntu 18.04.5 LTS, Plesk Obsidian 18.0.39
We have the same behavior on our fallback server (Ubuntu 20) with no user traffic or content change at all. Automatic Plesk updates are disabled.
 

Attachments

  • comp_Inc1_Inc2.jpg
    comp_Inc1_Inc2.jpg
    636.6 KB · Views: 20
  • backup_ext_nodejs_Day2.jpg
    backup_ext_nodejs_Day2.jpg
    310.6 KB · Views: 17
The database is included in full in every backup, even if it is an increment. So if your database size grows, backup size grows. The log files are included unless you checked the "do not include log files" checkbox. Log files tend to grow, and so does a backup where log files are included. A single bit change in any file will trigger inclusion of that file in an increment. Finally, I can see only a very minor increase in backup size, practically neglectible.
 
Thanks for your answer. It's expected, that DB and log changes lead to increases backfiles. In the provided screenshot comp_Inc1_Inc2.jpg you can see, that incremental backup from Day2 (right) included twice the same file backup_ext_nodejs_*.tgz. All these files (purple ones) are included in every incremental backup despite they don't change.
That attached screenshot shows both backup_ext_nodejs_*.tgz from Day1 and Day2. CRC of both files is the same (green). 3 different bytes as shown in previous backup_ext_nodejs_Day2 seems to be the different changed date (red).
 

Attachments

  • backup_ext_nodejs_Day2_7zip.jpg
    backup_ext_nodejs_Day2_7zip.jpg
    133.1 KB · Views: 6
You rely on a checksum. Have you checked that all permissions and timestamps of all files in your tar files are the same?
 
As the first screenshot backup_ext_nodejs_Day2.jpg proofs both backup_ext_nodejs_*.tgz are nearly binary equal. These specific *.tgz files seem to contain several nodejs binaries from plesk. These files are maintained by Plesk itself. Permissions and timestampes of these files didn't change. Every daily incremental backup includes these files again.

That situation leads to increasing backup sizes (as seen in comp_Inc1_Inc2.jpg).
Full backup day0
backup_ext_nodejs_2111280005.tgz (170mb)

Incremental day1
backup_ext_nodejs_2111280005.tgz (170mb)
backup_ext_nodejs_2111280005_2111290005.tgz (+170mb)

Incremental day2
backup_ext_nodejs_2111280005.tgz (170mb)
backup_ext_nodejs_2111280005_2111290005.tgz (170mb)
backup_ext_nodejs_2111280005_2111300005.tgz (+170mb)

etc.
 
This probably needs and assessment by Plesk staff. It is thinkable that they include certain basic files in every backup for a reason. Maybe you can report this at Reports or submit a ticket to Plesk support?

It would certainly be nice to hear about the result here again.
 
Thanks for your suggestion. Due "Only users with 5 or more helpful posts are allowed to create a report there." it seems I'm sadly not allowed to report. Therefore, I hope Plesk staff check this post.

As an immediate workaround to protect my servers from running out of free disk space I had to drastically reduce backup creations. I'm not happy with that situation in a productional environment.
 
Back
Top