If you are interested in adding GCFOS technology to your application, please fill out the OEM Form.
What about sensitive or proprietary files?
Files are never transferred to GCFOS servers unless a unique file hash has been discovered on multiple client machines. Once identified as a common file candidate (and assumedly therefore not sensitive) the file will be processed normally based on the GCFOS common file definition.
What defines a GCFOS candidate file?
The calculated file hashes on a predefined number of client machines must be identical. If a file is determined to be common and already resides on the GCFOS server, then the file will be eliminated from the backup. Instead, a 24 byte locator record, along with Metadata, will be written to be used for any subsequent file retrieval. If the file does not reside on the GCFOS server, the software will invoke a transfer and continue to back up the file as normal. After this occurs, any new client file that generates an identical hash will not need to be transferred. Clients save time and resources since the same file will not be saved over and over again.
What is the restore throughput when restoring from GCFOS?
GCFOS can send files to a backup client typically faster than wire speed (because of compression). If a user has access to 50 MB internet access for example, then restores from GCFOS (cloud) will typically run around 10-12 MB/sec. Given that common files typically account for 30-40% of the total files backed up, the aggregate throughput rate will likely be much higher. For example, given a 30% common file selection rate, 50 MB internet access, and a normal throughput for restore of 80 MB/sec, the aggregate throughput rate will be ~60 MB/sec when restoring from a GCFOS enabled backup (a 25% speed decrease). Of course, the aggregate rate will be much higher given a faster internet connection.
Can the backup software still capture security and auditing information for common files stored in GCFOS?
This is straightforward and easily handled. As an example, UltraBac uses the standard Windows API to extract security and auditing information for files and stores it in the normal backup stream – only the main file-data stream is excluded from the backup. At restore time, the data from both sources is seamlessly merged to ensure that the restored file exactly matches the state of the file as it was when it was backed up.
What internet access is required for GCFOS to function?
The GCFOS servers listen on UltraBac's IANA-assigned port 1910 to listen for queries. The clients create ephemeral ports (at the discretion of the sockets provider) in order to create connections to the GCFOS server. From a firewall perspective, you must allow any port (or ephemeral ports only) outbound to connect to port 1910 (UltraBac can provide explicit IP addresses if necessary). You must then define an inbound rule from port 1910 back to either any port or the ephemeral ports.
What is the overhead to query GCFOS for files?
The first backup of a path will involve the calculation for all hashes for files encountered, as well as the query to the GCFOS server. The results will be cached, and therefore subsequent backups of the same path will be much faster. The overhead is very low, and any small overhead is easily compensated by the time and storage saved by eliminating thousands of common files in the backup.
For more, please visit our additional information page. To review the four ways that GCFOS can be deployed by Partners and OEMs, please visit the Redundant File Elimination overview page.