• 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!!

omexlu

Regular Pleskian
Hello,

Since the update yesterday to plesk 18.0.23 I noticed something:
Some of my incremental backups are significantly larger, otherwise always around 100MB now 21GB?

How can that be, is that normal, does anyone have that, or has there been a bug in plesk again?

It is definitely not normal :)

Thanks in advance.
 
It is probably not an increment that was created, but a full backup in that case. Could you provide a screenshot of the backup list page, please?
 
Hello,

But it is (see screenshot), this phenomenon has also only occurred since the last major update, otherwise it was always so between 100-150 MB with incremental.

Clearly no major changes or files have been changed or added to the web hosting.

I even opened the backup archive of today manually and there are files there that have been there for a long time :)

There is something wrong :)

VersionPlesk Obsidian v18.0.23_build1800200117.16 os_Debian 8.0
OSDebian 8.11
 

Attachments

  • screenshot.png
    screenshot.png
    49.2 KB · Views: 25
The backup done on January 22 contains errors. It may be incomplete. You must make sure to have a full backup with a green icon in front of it, otherwise the backup is not fully correct which can lead to any kind of error including severe errors that prevent restoration. My suggestion is this:
- Do a manual full backup and make sure that once this completes it is fully valid and has a green icon.
- Wait two days to watch what the auto-incremental backups of Plesk will do with that.
My expectation is that the incremental backups will work again when they are based on a fully valid full backup.
 
- The full backup from before has only 2 errors from 2! Image-files (forum) where the backup was made and never so much that 20GB had to be backed up again.
- That's the problem where I created in the other thread, since the function was disabled that the domain can be disabled before the backup process it is in my case practically impossible to get a valid fullbackup from a forum.
- Furthermore, the problem was not present before the current version, even if the fullbackup was not valid before, the incremental backup would still be done correctly afterwards.

The backup function of Plesk OB is not as it should be in many respects.

I'll watch the days, maybe there was something about the update but in my opinion there is a problem here somewhere.

Maybe @IgorG and his dev team should take a closer look :)

Always backingup 70GB is nerving
 
When minor errors occur in a backup, it is still marked as "green". It will still be a valid backup with some minor errors (single files that could not be accessed during backup etc.), but it will not be marked with a yellow exclamation mark. A backup with a yellow exclamation mark is invalid. It cannot be restored without errors. So before solving the case where the increment is too big, we should first figure out why the initial full backup is invalid.
 
This is also not correct in my case, there are only small errors and still the backup is marked as invalid, as you can see here are only a few small errors and pictures that could not be found at the time because they may have been deleted in the forum by a Cronjob (Full-Backup from 22th):

Even more I looked closed its only ONE image that was missed but includes thumbnail and so on, invalid because one file? That's a joke

Not all the data from /var/www/vhosts/XXX was backed up successfully: /usr/lib/plesk-9.0/sw-tar: httpdocs/wcf/attachments/83/132591-tiny-8354af74e32f7c47cf1a20f3e83929b1f37dfd63: Cannot stat: No such file or directory /usr/lib/plesk-9.0/sw-tar: httpdocs/wcf/attachments/83/132591-8354af74e32f7c47cf1a20f3e83929b1f37dfd63: Cannot stat: No such file or directory /usr/lib/plesk-9.0/sw-tar: httpdocs/wcf/attachments/83/132591-thumbnail-8354af74e32f7c47cf1a20f3e83929b1f37dfd63: Cannot stat: No such file or directory /usr/lib/plesk-9.0/sw-tar: Exiting with failure status due to previous errors
 
Is this the full error message that is displayed when you click on the backup name of the full backup?
 
Would it be possible to try a restore of that backup file (to a different machine for example)? I am asking, because when you start a restore
a) a warning might be displayed that gives more information that and why the restore will not be possible in full
b) after a restore you'll know more what the problem with the backup file is
Of course this should not be tested against the production machine.

Other from that I can only think of changed pathes, filenames or file dates why so many files are backed up to an increment. There is also a possibility that a major part of the size of the backup is caused by the database. Maybe you have configured the forum that the major data of the forum are stored to a database instead to the file system? In that case it will be necessary to backup the full database each time the backup runs. This could cause the very large increment. How big is the database?
 
First of all many thanks for your help and commitment :)

- Unfortunately I don't have a test instance so I could test this.

- Neither paths, files nor file date were changed.

- Nothing has been changed in the settings of the forum and everything is the same as it always worked except that Plesk has been updated to 23.

- Databases are completely backed up daily, even with incremental backups, there are no changes here that might interfere (about 400 MB daily).

- I've looked at the incremental backup of today and the size clearly comes from files (pictures for the most part) that are on the webhosting but which are older and have already been backed up in the full backup, so that they should not be backed up in the incremental backup.

I also checked and saw that the other webhostings are also affected by the problem, but there it is not so obvious because less storage space is needed and there all backups are valid, so I can rule out the valid one.

The only thing I did after updating Plesk yesterday was to delete the custom templates and replace with the current defaults and remove the powered by PleskLin and regenerate the confs. Don't think that this is related to the backup feature and will lead to this behavior.

This has to be observed tomorrow, if everything is still running then, there was somehow a problem or hiccup ☺️
 
There is an issue with the backup function where the backup creates a full backup each day while it is set to incremental. Maybe what you are experiencing is this bug in a different exposure.

I suggest to remove the backup job from the backup plan (while you leave your existing backups untouched), the re-create the backup job as you want it. It could solve that issue (it has on a test machine of mine).
 
What do you mean exactly, just deactivate > save, activate > save?
And leave all current backups as they are?

screenshot.png

Anyway, it's worth a try :)
 
All right, I will do this now for all webspaces and report tomorrow if it has improved.

If not, there must be another bug somewhere.

EDIT: Done, lets see tomorrow if it helps :) I will leave the backups as they are, they will be deleted after a week anyway and a new full backup will be created.
 
Last edited:
Morning,

It is now partially working, but I still have my doubts about, example a other webhosting both incremental backups have the +/- same size in sum as the fullbackup - that's not normal :)

I assume that there is a bug in the backup system somewhere and that this should be forwarded for investigation ( @IgorG ).

I have never ever this problem before v23.

Let's see how it looks like next week when a new fullbackup is created.
 
I assume that there is a bug in the backup system somewhere and that this should be forwarded for investigation ( @IgorG ).
 
From Onyx to Obsidian.

I have always updated Obsidian regularly with all the updates that were available (so exactly in that order from the changelog).
 
Back
Top