Hi ,

Could you please clarify a bit your use case? Are you talking about a hybrid backup plan?
If so, the possible solution here could be splitting the hybrid job into two different backup plans: one pointing to local storage and another to cloud storage.
With the hybrid backup plan, there is no way to start the local backup before the software finishes to upload the data to cloud storage.

Sorry for the confusion. We aren't using hybrid backup plans. We have a cloud and a local plan running separate from each other.
I had presumed that a local and a cloud backup plan running on the same machine could not run at the same time. Am I wrong about that? I thought this because I had observed that if (for instance) the cloud backup plan was running while the local plan was scheduled to start, the local backup would quickly fail with the error message "Another disk image plan is running."

,

Thank you for the clarification.
Unfortunately, it is not possible to start an image-based backup plan if another image-based plan is running.
We are going to change that behavior in one of the future releases.
If you'd like, we can notify you once we change that.
Please send me your email address in the private message.

We too have some large images, so we have adopted the following approach:

• We do both Image and file backups.
• We exclude the data folders from the image backups to keep the images to a manageable size (The OS and App installs primarily)
• We run separate file data backup plans nightly - one to the local drive and another plan to the Cloud
• We run the Full image (with data excluded) to the Local drive each Saturday, with incremental image backups each weeknight.
• Once per month we run an image backup to the Cloud. If the image is still too large to get done in a weekend, we run a monthly incremental and periodically do the Full Image backups (over three day weekends usually)

This way, the actual data is backed up every day to both Cloud and Local drive, and the Local image is only a few days old in the worst case. For DR, having an up-to-one-month-old image is fine for our situation - we can apply any program/OS updates after recovery.
The key principle is that separating the OS and Apps image backups from the data backups allows you to run the data backups every night to both locations regardless of how often and for how long the Image backups run.

Steve,

So how many plans do you have created total and for what exactly? I think I understand you to say you have two file backup plans (one local, one cloud), two image plans (one local with full weekly backup, one cloud with fully monthly backup?)

I'm struggling right now with getting my client's data to the cloud. One of my client's has like 2TB of file data and with his internet connection its going to take almost ~30 days to upload. I can't have him not backup for 30 days.... I'll never be able to run a new full backup at that speed. Even uploading his image without data , roughly ~62GB, takes over a week. There's no way I can run a new full backup weekly, probably not even monthly.

Do you just tell people straight up they don't have the bandwidth for cloud backup, you have to increase it or stay local? Or is there something I'm missing here? It seems really straight forward, but I've never ran into this issue before.

What is the internet upload speed of your client? We require our clients to have at least 8 mbps upload speed in order for us to provide Image backups to the cloud. 8 mbps (1 MBps) translates to roughly 3GB of backup per hour so a 62GB upload could be done in ~20 hours. A client with 2TB of data and/or image Cloud backups cannot possibly be supported if they have DSL or a 3mbps upstream speed.
For one large client, it took us two weeks to finish the initial upload of 2TB to the Cloud over a 15mbps upstream connection, but after the initial upload was complete, the nightly block level file changes amounted to no more than 10GB or so, usually less.
We first setup a local flle backup to an external 5TB hard drive and that cranked along at 20MB per second - that runs every night so at least they were getting local backups during the two weeks that the cloud initial upload was running.
For this client we actually run two Cloud file/data backups in addition to the local backup each night. One Cloud Backup goes to Amazon One Zone IA, and the other goes to Google Nearline. We schedule them to run at different times each night, and they finish in 1-2 hours each.
Summary:

• To provide Disaster Recovery Images and to backup that much data, we would insist on at least 8mbps upstream.
• Once the client gets a faster connection, you should run the Local Backup of both the 2TB and the Image (minus data) and setup the File backup to run nightly. Schedule the Local Image backup to run, say, Mon - Thurs block level and a Full on Friday night.
• Start the 2TB Initial Cloud File backup ( at 1 MBps it will still take ~30 days to complete - at 2 MBps = ~15 days)
• Once the Initial 2TB upload is complete, schedule the File/Data Cloud Backup to run each night
• Run the (62 GB) Image backup to the Cloud. Start it on Saturday morning and it should complete easily before Monday morning.
• Setup the Monthly Cloud Image plan to run on the First Saturday of the month, and if you want, run weekly block level image backups on the other weekends.

Let me know how you make out with your client. I am happy to assist in designing your backup plans.
- Steve

Thank you all for the very helpful insight into this issue! We will look into this further.