- What are the system requirements for rCloud?
- How does rCloud work?
- How is rCloud service enabled?
- How do I access rCloud Management portal?
- How big is the host agent?
- How do I upload my server?
- How much bandwidth do I need to upload my server over the Internet and how long will the initial upload take?
- What kind of bandwidth do I need to perform daily uploads to the service?
· Windows Server 2003
· Windows Server 2003 R2
· Windows Server 2008
· Windows Server 2008 R2
· Windows SBS 2003
· Windows SBS 2008
· Windows SBS 2011
· Linux distributions approved for ESX by VMware
*rCloud supports both 32-bit and 64-bit versions of all four Windows Server releases listed above.
- Any application that runs on one of our supported operating systems
- Any application supported in a VMware ESX virtualized environment
With the simple installation of a host agent on the server, a full image of the server can be uploaded over the Internet or shipped on a disk where it is replicated to the rCloud secure data center. Incremental server image backups, or deltas, are then replicated automatically into rCloud on a daily basis. These images can be accessed through the rCloud web-based management portal, where they can be restored to run as virtual machines.
A user creates an account in the rCloud portal, then downloads and installs a small host agent on the server.
A web browser, Internet connection and secure logon are all that is needed to access rCloud.
The virtual host agent is under 1 GB and the physical host agent is 49 MB.
A server image can be uploaded to rCloud automatically over the Internet or shipped on a disk to rCloud.
How much bandwidth do I need to upload my server over the Internet, and how long will the initial upload take?
You will need enough bandwidth to upload a daily incremental backup to the rCloud in 23 hours. The actual amount of bandwidth will vary on a user-by-user basis, however, we recommend at least 1 Mbps upload speed.
The following table provides general guidelines for 200GB transfer speeds. For more precise information related to your base server size, please refer to this calculation tool.
|Available Internet Connection||Theoretical Min. Number of Days to Transfer 200GB at 80% Network Utilization|
|T1 (1.544Mbps)||16.4 Days|
|T3 (44.736Mbps)||14.4 Hours|
It depends on the size of the deltas, however we recommend 1Mbps, outside of business hours. Bandwidth usage can be throttled down during business hours through rCloud management portal.
- How is data protected when being transmitted?
- Where and how is the server image stored?
- Is rCloud in a SAS 70 Type II data center?
- What kind of security permissions are employed?
- Are audit trails provided?
Server data is encrypted using standard 256-bit Advanced Encryption Standard technology prior to being transmitted over the Internet.
Server images are securely stored as images in a Tier 3 grade co-location facility. The data center provides HID access, key card access only, entry and exit logs, surveillance and closed circuit monitoring with CCTV, monitoring via IP connection to remote NOC, and 24/7 on-premise security guard.
Yes. rCloud is deployed in a modern Tier 3 data center selected to meet or exceed SAS 70 Type II and HIPAA best practice requirements.
Server data can only be accessed with a secure logon and password authentication via the rCloud management portal.
- How are server images stored?
- How often are server images replicated to rCloud®?
- How is a server image restored?
- How is the integrity checked, tested, and reported?
- Can the service perform automatic test restores?
- How is server image recovery managed?
- Does rCloud support bare metal server recovery?
The server production environment is compressed, encrypted, and replicated to two SAS 70 Type II data centers.
Replication takes place daily.
rCloud reconciles the base image with the deltas to provide a full working copy of the server.
rCloud automatically boots all ESX images upon completion of each backup to ensure integrity. ShadowProtect™ images cannot be tested in the same way.
We recommend that our users perform a test restore of each server, regardless of the type, once a month to validate integrity.
Test restores are conducted manually.
A complete server image is available for restore in the event of disaster or failure.
For physical machines, bare metal server recovery is 100% automated.
- How does the rCloud® rapid recovery and failover service work?
- How does the rCloud failover work?
- How does a user connect to their server while in failover mode?
- Is failover manual or automated?
- How is failback performed?
- How does the rCloud Virtual Lab work?
- What functionality is provided through the rCloud web console?
- How is the networking environment configured?
Server images are replicated in a SAS 70 Type II data center. These images can be restored for use at any time, with deltas automatically uploaded to rCloud on a daily basis.
Users can use these images to provision and test Microsoft Windows servers and deploy them as virtual machines to either the client’s on-premise or cloud environment.
In the event of a disruption to the production server, users can restore the latest copy, or a specific point-in-time copy of the server as a virtual machine in the cloud. These images are completely restored to full system connectivity. The user can then failover their connections to that copy of their server and run from rCloud until the on-premise server is repaired. The user can also choose to download a copy of the server to another location.
For the recovery and failover service, we provide a single public IP address for each user running in failover mode on the platform. The user can then adjust DNS records and direct the client to connect to their servers via VPN or remote desktop services.
Users can access the copy of their production server via a VPN connection, or remote desktop services.
Failover must be initiated manually.
Failback can be achieved in a number of ways: Virtual machines/server images restored on the rCloud platform can be downloaded (or shipped) at any time in a VMware ESX 3.5 format.
The rCloud Virtual Lab provides a hosted lab environment that replicates the user's production server infrastructure in the cloud. Because an up-to-date copy of the production server is maintained in rCloud at all times, the lab allows users to provision servers, perform upgrades and migrations, test changes, and deploy patches against a virtual copy of the production server.
The rCloud web portal provides an administration console that allows users to access all the features of the service while being able to review the status of all virtual machines in a unified dashboard.
The rCloud platform automatically recreates the “native” IP environment around each restored machine. The IP address, subnet mask and gateway are all the same as the original network.
- Do you monitor and enforce compliance of software and operating system license usage?
- Does the rCloud® provide reporting? If so, does it include usage and activity? What type of views and formats?
- Does the rCloud® provide server performance monitoring?
- Can you run multiple instances of the same virtual machine configuration side by side?
- Can rCloud start, shut-down, suspend, snapshot, and share virtual machines individually or as a complete system?
- Does rCloud provide a configuration library of ISOs?
It is the user's responsibility to manage the software licenses.
Does rCloud provide reporting? If so, does it include usage and activity? What type of views and formats?
rCloud is actively gathering requirements to enhance our reporting capabilities. rCloud® currently provides detail on server image history, storage volumes, and lab usage.
No. Users monitor their servers and infrastructure and utilize the rCloud® to manage failure and restoral scenarios in near real-time.
Yes, in the virtual lab.
Can rCloud start, shut-down, suspend, snapshot, and share virtual machines individually or as a complete system?
The rCloud rCloud service can start and shut-down virtual machines, but does not snapshot or enable sharing.
Not at this time.