Remote NFS cpanel backups a good idea?

[sozotech]

I have some cPanel servers located in a data center in Fremont, CA with 100M uplink and an NFS server in a remote datacenter in LA also with a 100M uplink. My ping times between the two data centers is about 10ms and 6 hops away and generally I don't see any packet loss.

That being said, is it a bad idea to backup via NFS mounts to a server that is not on the local LAN? I guess my concern is NFS timing out or if there is a packet dropped along the way whether this is going to cause more problems than it saves?

I have tried doing FTP backups offsite but for some reason it seems like my backups never seem to completely backup all accounts but I have not been able to find the root cause so I figured NFS may perform better.

Best regards,
Eric

 

[ThinIce]

Provided you're using a modern NFS (NFS4) it is now designed to work over the internet. I'd be more worried about transmission security, with NFS it's very important to make sure no insecure options are in use.

https://access.redhat.com/site/docu...urity_Guide-Server_Security-Securing_NFS.html

NFSv2 and NFSv3 traditionally passed data insecurely. All versions of NFS now have the ability to authenticate (and optionally encrypt) ordinary file system operations using Kerberos. Under NFSv4 all operations can use Kerberos; under v2 or v3, file locking and mounting still do not use it.

To have a mini rant over this, I've always been amused (well, not at all really) that it's common to punt these things over the net in plain, the same goes for rsync unless it's being specifically used with the hostname options so it's working over ssh or the extra work has been done to tunnel rsync:// over ssl. I suppose it's down to the lan roots of these tools, but imo they could sure do with some versions that have internet ready defaults.

Are your backups compressed or incremental? For the former you might find SFTP with keys is straightforward and secure.

 

[sozotech]

Are your backups compressed or incremental? For the former you might find SFTP with keys is straightforward and secure.

I am running legacy compress backups that produce a username.tar.gz. I don't why ftp has been having issues. The backup logs just seems to stop short of backing up all accounts with no errors. I am not sure if it just because the backup window is so long that it just stops after a day of running or what.

Eric

 

[cPanelMichael]

I am running legacy compress backups that produce a username.tar.gz. I don't why ftp has been having issues. The backup logs just seems to stop short of backing up all accounts with no errors. I am not sure if it just because the backup window is so long that it just stops after a day of running or what.

Eric

Hello

Is there any reason you prefer to use the legacy backup system instead of the new backup system?

Thank you.

 

[sozotech]

Hello

Is there any reason you prefer to use the legacy backup system instead of the new backup system?

Honestly it is what I've always used and like just having the tar.gz files to be able to move around and restore. I've looked at the new system and I guess I must be missing what is the advantage of the new system is. How do you think the new backup system would improve this situation?

Thanks,
Eric

 

[cPanelMichael]

The new backup system is redesigned so it might be worth trying out to see if you experience any of the same problems that you face with the legacy backup system. In addition, several additional backup destination types are available (e.g. SFTP, WebDav).

Thank you.

 

[madsere]

Sorry to jump in so long after the thread was started, but I'm having related questions so I think it's relevant to continue this instead of starting a new.

Apart from security and stability, I don't think using NFS for backups is a particularly good idea, at least not directly by mounting /backup over NFS. It seems cpanel first copies all the files over the network to the NFS drive, once completed, everything is copied back again, compressed and then sent a third time back to the final backup zip file. Finally an md5sum is done on the file, which requires it to be sent forth and back, so, in other words an incredible amount of redundant network traffic. I guess the "additional destinations" option with "additional local directory" set to the NFS mount would work though.

The WHM backup page says "NOTE: Filesystem quotas are enabled. To prevent performance degradation, the system automatically disables quotas on non-root filesystems that contain a backup destination.". What does that really mean? So if I have a server with just one partition (such as a VPS server) enabling whm backups would disable the quota system?

If this is the case, a separate "cache partition" would be required just for the backups I guess, which leads to the next question: How big should that be? Does it need to be big enough to store a complete backup set, or is the system transferring the backups to the additional destination smart enough to copy files over per account as the backups are completed, so that the cache partition just needs to be big enough to store a backup of the largest account?

 

[cPanelMichael]

So if I have a server with just one partition (such as a VPS server) enabling whm backups would disable the quota system?

Hello

No, it won't disable quotas on the root filesystem (/) so quotas are not disabled in this case. That being said, it's a better idea to have a separate partition for backups if you plan to store them locally.

Thank you.