@JogoVogo
The statement
With the server backup, via ftps are supposed to be created incremental, but obviously full backups are created every day.
is to some extent correct, but also a bit out of context.
A full backup will use a lot of space - that is correct.
However, when using a full backup, the amount of space used by backups can be significantly reduced by using a limited number of backups to be stored.
For instance, in most scenario's, a value of 2 (read: number of full backups to be stored) is sufficient, no matter the frequency of backups.
On the other hand, any incremental backup is
1 - based upon one FULL backup, the original backup,
2 - augmented with incremental backups, including backups of files that have been present in the past and have since then been removed,
3 - consuming more resources when creating the backup : a lot of server resources (memory and temporary disk space) will be used,
and, as a result, the incremental backup option is usually associated with huge usage of disk space for backups - the "problems" will only become worse if you have more frequent (incremental) backups, if you have a longer retention period (of backup files) and if the backup strategy is not well-designed.
It is highly recommended to
A - make a distinction between server-wide and domain- or subscription-level based backups : the server-wide backup can be run on a monthly basis with a retention of 2 backups (read: 2 backups to be stored), if (and only if) another backup strategy is in place for domains and subscriptions,
B - use domain- or subscription-level backups and make a distinction between "dynamic" and "static" domains / subscriptions : the not frequently changing (read: "static") subscriptions can be associated with a (non-incremental) backup on a non-frequent basis (for instance, once per week) and a low retention (for instance, 2 to 3 backups to store), whereas frequently changing (read: "dynamic") or "important" subscriptions should be associated with at least a daily (non-incremental) backup and a high retention (for instance, 3 to 7 backups to store),
C - always make a local backup : when confronted with problems, the local backup is more easy to restore and it is faster to restore,
D - always make a (second) external backup : when confronted with server-wide problems, one can still get the backups from the external storage,
E - consider the usage of cloud based storage : most modern cloud based storage platform have the option to create backups and snapshots with the cloud, hence making it completely unnecessary to configure retention settings within or with Plesk, since that can be done automatically in the cloud,
F - consider the usage of "simple solutions" : rsync alone can be just as efficient as Plesk native backup and rsync with a simple bash script (read: to find all of the changed files) can mimick the incremental backup .......... and it is faster, since the (server resource intensive) process of Plesk backup (with compression and/or encryption and/or slow connections to external storage) can be a tad slow from time to time.
In summary, Plesk has an excellent backup tool, but it has to be configured properly, in order to prevent any unpleasant surprises.
Nevertheless, proper configuration also requires a good backup strategy - including or excluding alternatives for Plesk managed backups.
In my opinion, you should tweak your Plesk managed backup settings a bit in order to prevent the unevitable overload caused by incremental backups.
I hope that the above helps a bit!
Kind regards....
Facebook
Twitter
