Disk space needed for full backup

[CGI1979]

Dear Plesk group,

how much local disk space is necessary for a full backup of 240 GB data to a remote ftp?
I have 314 GB free on my local disk, but this is still not enough.

The backup process is 100% after round about 4 hours, according to Backup Manager.
But there are still tar processes until the disk is full.

Thanks for you help,
Chris

 

[trialotto]

@Chris,

I presume that

a) the backup has been made, consuming 240 GB of the 314 GB of free disk space, leaving only 74 GB of free disk space,

b) the remainder (74 GB) is fully consumed by the FTP process, using some (significant) buffer to send the backup file to the remote FTP.

Naturally, one could consider to free some additional disk space and it seems to me that you should consider that anyway.

However, at the current moment, you only want to make a backup and store it on a remote FTP server, for which the following steps should suffice:

1 - login with SSH to the server in question,

2 - locate the backup file made by the backup process,

3 - copy the backup file with curl, the command should resemble: curl -u ftpuser:ftppass -T myfile.txt ftp://ftp.testserver.com

and that should do the trick.

It is adviceable to clean-up the server afterwards, given the fact that you do not have enough disk space on the server.

Hope the above helps.

Kind regards....

 

[CGI1979]

Thanks for your hint!

I implemented the ftp upload the way you recommended but I leave the backup on the local disk, which is overwritten the next day. That way the customers can use the full backup to restore even single files by themselves.

Nevertheless I am a bit disappointed Plesk cannot upload the backup directly without using that much additional disk space.
Next time I'll create disks that have 3x the size I need.

Thanks again.

 

[trialotto]

@Chris,

You should not be disappointed about Plesk.

In fact, Plesk uses a common backup and transfer procedure, involving archiving (tar format) and compression (gzip format).

In almost every scenario, it is the compression part of the whole process that requires the most (free) disk space.

In your case, one element adds to the extensive consumption of disk space: you apparently create a full backup.

It is very likely that you, when you split up the backup process and create ftp based backup on a domain-per-domain (or resellers-per-reseller, client-per-client basis etc.), will have enough free disk space in order to complete (remote ftp) backups for all domains. And even if the remaining 74 GB is not enough, one could create scheduled backup tasks, this in order to execute all backups sequentially and, as such, reduce the required free disk space even more.

In short, it is not always about hardware and disk sizes, it sometimes is more easy and efficient to rethink and streamline the total backup process.

In your case, it would be adviceable to split up backup processes in (separate) smaller ones.

Kind regards....

 

[CGI1979]

Thanks for your answer. The local backup now only takes about 135GB of space. I transfer the backup with a cronjob to the ftp.
Before the next backup starts I delete the contents of the backup folder.

As I said before, the customers can even restore from the full backup within their subscription.

For me this procedure works fine now!

 

[trialotto]

@Chris,

Nice to hear that you have found a procedure that works for you, without requiring adding additional disk space.

Note that, if you scripted the ftp transfer and consequent deletion of the backup, it is adviceable to add some lines of code to check that the backup has been fully transferred.

It can be the case that (unattended) ftp transfer is incomplete and/or erroneous, hence resulting in a comprised backup file (and that is not the intention).

Kind regards...