Backup Performance Issue (pigz on NFS partition) - Part II

[phoenixweb]

Dear all,


since my previous thread:
http://forums.cpanel.net/f49/peformance-issue-gzipping-nfs-partition-351812.html#post1419391


The backup module has been improved: cPanel introduced the "another location" destination in backup.
This is fine because i can ask to cpanel to zip all the files localy and only, in a second moment transfer the tarbal on the NFS remote partition.
The system can also delete all backup file localy at the end of process.

Really Good, then I can finally said that my problem with the NFS call flood is finally over.

BUT...

The problem is that RESTORE FEATURE only works with the current backup location.
This means that i'm not able to:

- show backup to my customer in their cPanel Backup selection
- restore from the WHM without move the tarball back in the directory.

This is weird.
It's like I'm using the wrong directory for backup and restore.
I think that backup behaviour is still wrong and that should be possible to:

1) select a working directory to execute localy the backups [only local directory accepted]
2) select a directory to store the backups used also to restore (which can be mount from remote partition)

Which is different from the actual solution:

1) select a directory where execute, store and restore account (all!)
2) select many alternative location to store (but not to restore account)

Backup should be executed ONLY on local filesystem to preserve performance.
cPanel should consider to fix this.

 

[Infopro]

What about this setting in Backup Configuration?

Retain backups in the default backup directory.

This option will keep backups in the default local backup directory even after the backups have been transferred to another destination.

If this option is not selected, backups will be deleted after being moved to another destination.

 

[phoenixweb]

What about this setting in Backup Configuration?

????
How can this be usefull to solve this problem?

I can repeat it quickly:

PROBLEM: Backup on a remote directory (if you have 50 servers) create a NFS overflooding calls
FIX: Make backups only on local filesystem THEN move it.

1) backup locally [ok]
2) transfer backups on remote directory [ok]
3) restore from that remote directory [not possible]

The problem here is that while you are fixing by creating alternative location to store backup, then you cannot restore anymore from that directory.

The problem of the overflooding NFS call must fixed before in the process.
Backups should be create localy always and indipendently of backup configuration directory.
The main backup configuration directory should become the final ending point for backups not used during the backup (while is gunzipping the archive).

 

[Infopro]

Are there any existing Feature Requests that you know of on this topic?

I don't have 50 servers so don't feel your pain here, I'm sorry. My point was:

1) backup locally [ok]
2) transfer backups on remote directory [ok]
3) restore from that remote directory [not possible]

4) backup locally is still there, I enabled that option. [YES!]
5) restore from local backup as needed when a user deletes public_html to fix wordpress issue. [easy peazy]
6) remote directory is safe for disaster recovery in case of death by fire on local server when users wordpress gets compromised. [there goes my weekend]

 

[phoenixweb]

I already delete the local backups and i know how to restore theme.
Thanks anyway.

The point is that cPanel users cannot see anymore backups on the server if I move theme out of the main backup directory.
I do this only to create the backup without use NFS partitions but this should be handled by a Temporary Directory in the cPanel process and not by the configurator.

 

[WebDomain.com]

I'll second here the request of phoenixweb.
It should be possible to mount the nfs directory on demand to allow the customers restoring themselves their account.