CodeGuard’s systems perform at 99.9% levels, which means that roughly 1 out of 1,000 websites encounters an issue on a daily basis. Hosting providers perform maintenance on servers, customers change FTP login credentials, and IP whitelisting settings for database connections can change, based upon hosting provider server admin activity. These are common behaviors and not cause for concern, as CodeGuard determines the root cause for the lack of connectivity, and emails the customer so they can remediate.
CodeGuard relies upon industry best practices to protect customers’ data. All backups and passwords are encrypted, secure connections (SFTP/SSH/SSL) are utilized if possible, and annual vulnerability testing is conducted by an independent agency. To-date, there has not been a data breach or successful hack or attack upon CodeGuard.
CodeGuard was started in 2010, inspired by problems faced by small business owners. Technology angel investors and venture capitalists funded CodeGuard in the early stages and the company is now profitably growing – so there is no need to worry about your backups going anywhere!
Backups are stored on Amazon Web Services Simple Storage System, known as S3. S3 boasts object durability levels of 99.999999999%, achieved by storing redundant copies of data across multiple geographies and facilities. S3 is not the cheapest alternative for data storage, but it is one of the most reliable.
Our data stored on Amazon Web Services (AWS) is stored utilizing Server Side Encryption (SSE). AWS handles key management and key protection for us, with one of the strongest block ciphers available, 256-bit Advanced Encryption Standard (AES-256).
Two different types of passwords are stored on our system – customer account passwords to log into CodeGuard, and passwords for customer server credentials (FTP/SFTP, MySQL). The customer account passwords are stored with a one-way salted hash. At rest, these passwords reside in Amazon’s Relational Database Service (RDS). Customer server credential passwords are stored in RDS with RSA 2048-bit key encryption.
All file content is retrieved for the first backup using the “get” command over FTP or SFTP. Disk I/O is utilized as each file is retrieved and transferred to our servers. CPU and memory needs are minimal.
Subsequent backups are differential and do not entail transferring all content. This is achieved by utilizing the “ls – list” command and examining the metadata for each file: name, size, timestamp, file type, permissions, and last modified date. If any of these have changed, or a new file has been added, we will transfer the changed or added file to our servers. If a file has been deleted, we take note and adjust our repository accordingly. Since only changed file content is transferred, the vast majority of subsequent backups cause minimal memory, CPU, and I/O server needs.
When a customer seeks to restore a previous version of their website, the first thing CodeGuard does is to check the live website to see what content is on it. This enables us to quickly push (or pull) the differences to or from your site. For instance, you might experience a hack that changes your .htaccess file and nothing else. Rather than reload your entire site, CodeGuard would simply replace the infected .htaccess file with your old clean copy.