Plesk 12.5 backup functionality

[Chris1]

Has the backup manager in 12.5 been improved so that it doesn't use 2x used disk space on the Plesk server when performing a full server backup to FTP repository?

Currently in 12.0 it is really bad. For example if you are using 100GB, the backup process itself takes up another 100GB, making total usage during that time 200GB. It should perform the full backup on a per domain basis.

 

[abdi]

Hello Chris,
Advice on the logic ...

As I understand, for full server backups the full server has to be backed up, the backup file compressed and then moved to the remote server (if you enabled remote backups) and then deleted thereafter.

How else would it backup your server without first keeping a copy locally on the server?

 

[Chris1]

I found this in the release notes as a resolved problem.

"Backing up data to the FTP repository required a local backup to be created first. Backup failed if there was not sufficient disk space for the local backup."

Does this mean it doesn't require a local backup first anymore?

 

[abdi]

Since files transferred to remote FTP servers are compressed, there's no way such can happen without a temporary backup file.

 

[Chris1]

Hmm instead of using an FTP repository, I might be better off mounting another drive at the backup directory.

 

[abdi]

Well, that could work especially if you set-up a RAID kind of configuration such that both HDDs are syncing each other.
Or if you are copying files directly to the backup drive, but if you need to first compress them before moving them, still you might need storage for the temporary file (although you can change the temp folder path, perhaps to the second HDD).

 

[abdi]

I should say that in this generation, almost everything is possible ...
It's the time it takes and worthiness that helps us determine the path to take ...

 

[trialotto]

@Chris1,

you stated

I found this in the release notes as a resolved problem.

"Backing up data to the FTP repository required a local backup to be created first. Backup failed if there was not sufficient disk space for the local backup."

Does this mean it doesn't require a local backup first anymore?

and, in essence, the answer to your question is: no, not really.

In Plesk 12.5 (preview version), the backup process is intended to be incremental.

This reduces the need for a (temporary) usage of disk space, in order to create the compressed backup file.

Hence, why the "not really" in my "answer"?

I certainly hope that Plesk developers do allow for some usage of (local) disk space, in order to have a full and proper transfer of files, in case of remote (FTP) backup.

I did not investigate the matter yet, but I am pretty sure that a "fallback" copy is created, that can be resumed if the transfer to a remote server fails for some reason (and note that it should be a copy, since the files/directories to be copied can change due to normal Plesk processes, running simultaneously with a backup process).

Kind regards....

 

[Chris1]

No worries, thank you for your replies.

 

[pleskpanel]

Adding a somewhat irrelevant but perhaps related comment to this thread it would be great if the final release of 12.5 would include multiple backup rules! http://plesk.uservoice.com/forums/1...3703858-multiple-backup-rules-or-more-options

 

[trialotto]

Adding a somewhat irrelevant but perhaps related comment to this thread it would be great if the final release of 12.5 would include multiple backup rules! http://plesk.uservoice.com/forums/1...3703858-multiple-backup-rules-or-more-options

With some "crontab fiddling", this is already possible.

There are many ways to schedule (cron) tasks, with the possibility to have a (custom, in a sense "advanced") backup task scheduled.

However, I would not recommend "multiple" backup rules, since this could result in various errors (for instance, simultaneously running backup processes) and/or result in extensive usage of disk space and cpu AND, more important, it is not really necessary.

To illustrate the lack of necessity, consider backup settings that allow daily backups, with at most 3 copies in the (local or remote) backup directory.

In essence, this type of scheduled back up task takes care of daily backups and, as such, also backups at a monthly interval (as taken from the illustration in your link).

In short, a "multiple" backup rules would be a double and unnecessary rule.

However, consider the same scenario, but now with a requirement to retain (for example) monthly backups (as taken/derived from the illustration in your link).

Again, no necessity for "multiple" backup rules would exist, when considering the option to create a separate (scheduled) backup task for storing backups on a remote (FTP) backup directory (and note that this is "good practice", i.e. a remote location for backups that should be retained).

In fact, the backup settings also apply to the remote (FTP) backup directory, implying that backups are created monthly AND retained during 3 months, given the number of copies.

In conclusion, it is often more practical to fiddle with backup settings, just make smart use of the option in Plesk to separately set scheduled backup tasks for both local and remote backups.

Nevertheless, it would be nice to have more control over backup settings, any additional option in backup settings would be much appreciated, to that I do agree.

Kind regards.....

 

[pleskpanel]

While there are certainly cases to be made for not running multiple simultaneous server-level backups at once, it would be nice to be able to set different schedules via the GUI without the use of cron tasks (which is how we have to go about it now) even if you don't intend to overlap them in any way:

- Monday-Saturday server backups in local server repository (only retain latest three)
- Sunday - weekly backup to remote repository (only retain latest three)
- 1s Saturday morning of each month backup to remote repository (only retain latest two)