Question Restoring single file from entire server FTP backup

[campsjos]

Recently I tried to restore a single file from a entire server backup saved in my own NAS drive through FTP and the server ran out of space. From 30% of disk usage to 100% and the file wasn't restored.

So my question is, the backup restoration needs to upload the entire backup and then uncompress it all in order to restore a single file/site/subscription/etc? If yes, then I have to keep always 2/3 of disk free, right?

It's a best choice to disable the entire server backup and manually schedule a subscription backup each time I create one? Would this overload the server resources if they are scheduled at (more or less) the same hour?

 

[campsjos]

Up

 

[Bitpalast]

So my question is, the backup restoration needs to upload the entire backup and then uncompress it all in order to restore a single file/site/subscription/etc? If yes, then I have to keep always 2/3 of disk free, right?

The entire backup file needs to be downloaded and unpacked. You must have at least enough space for that on the disk.

It's a best choice to disable the entire server backup and manually schedule a subscription backup each time I create one?

This will not save the general Plesk environment and installation settings, but only the subscription settings.

Would this overload the server resources if they are scheduled at (more or less) the same hour?

Yes. The load that a single backup puts on the server can be very high, for example when pigz is compressing data, because it utilizes all processor cores of the system and goes as fast as it can on them. It leaves CPU time for other processes, but not much. And further, when several backups run at the same time, sometimes the backup software gets confused and returns error messages for one or more that their data is corrupt (while it is not really). For that reason I recommend to run backups at different times.

 

[campsjos]

The entire backup file needs to be downloaded and unpacked. You must have at least enough space for that on the disk.


This will not save the general Plesk environment and installation settings, but only the subscription settings.


Yes. The load that a single backup puts on the server can be very high, for example when pigz is compressing data, because it utilizes all processor cores of the system and goes as fast as it can on them. It leaves CPU time for other processes, but not much. And further, when several backups run at the same time, sometimes the backup software gets confused and returns error messages for one or more that their data is corrupt (while it is not really). For that reason I recommend to run backups at different times.

Thanks for your response @Peter Debik .

It's very important for me to be able to restore a single subscription as fast as possible and I think that downloading and unpacking the entire server backup each time I need to restore a site (or a file!) is a waste of CPU and disk resources, and there's also a risk of system failure in case there isn't enough free space in the disk when the restoration begins...

I have 20 subscriptions at this moment and soon I will get some more. Some of them hosts several GB of data and others only few MB. I need daily backups for each subscription. If I schedule a backup task for each subscription from 12am and with 15 minutes of difference from one to another with the compression disabled that would be less error propitious, right?

I know that I can get the answers at all this questions just trying it in my server, but testing backups is slow and somehow dangerous and one don't always have the opportunity to talk with a Plesk Guru

 

[Bitpalast]

There are many "Gurus" on here, I just happen to be one of them.

Anyway, in many cases it is not problematic to overlap some backups, so maybe a 15 minute gap for single subscriptions is sufficient. If not, set it to 30 minutes instead.

The backup is in general quite reliable. There might be issues here and there in special cases, but overall at least in my company we'd never had a severe issue with it.

 

[campsjos]

Thank you @Peter Debik