TeraByte Unlimited

My workplace uses a cloud storage system from Box.com. There is an application called "Box Drive" that has my cloud storage location behave like a normal folder on my computer. It simulates being a subfolder within my User folder on drive C.

So far I am successfully using ImageWin to back up my D drive to the Box Drive folder (backup is about 1/2 done, then will come the validation, and hopefully the entire procedure will complete without error). Assuming this works successfully, I want to then back up my C drive the same way. But how do I prevent ImageWin from trying to backup the Box Drive folder (which pretends to be on C)? If I don't exclude it, I am assuming I would get into some sort of recursive loop that would result in an error. Any suggestions?

I think there is actually a physical copy in there so it would be like any
other folder which mean it would grow. Best if there could be another drive
or partition for those files. You could use /exlist but on restore it
would delete the items from the folder.

"Muad'Dib" wrote in message news:[email protected]...

My workplace uses a cloud storage system from Box.com. There is an
application called "Box Drive" that has my cloud storage location behave
like a normal folder on my computer. It simulates being a subfolder within
my User folder on drive C.

So far I am successfully using ImageWin to back up my D drive to the Box
Drive folder (backup is about 1/2 done, then will come the validation, and
hopefully the entire procedure will complete without error). Assuming this
works successfully, I want to then back up my C drive the same way. But how
do I prevent ImageWin from trying to backup the Box Drive folder (which
pretends to be on C)? If I don't exclude it, I am assuming I would get into
some sort of recursive loop that would result in an error. Any suggestions?

I don't have the option to change the "pretend" drive of the Box.com folder (unless there is a way to spoof it).

You mentioned "/exlist" but in my reading of the IFW doc, this couldn't apply (the explanation says: "The file must be ANSI text and located on the local file system." The ANSI requirement obviously doesn't apply to a TBI file, and it's not REALLY located on the local file system. Also, the beginning of the description of this option says "IMPORTANT NOTE: This option is used at your own risk. Please make sure to create standard backups of important data." Not something that encourages someone to experiment.

Oh well, I guess I'll have to try another program (or use an intermediate device).

BTW, backing up my drive D (about 450 GB) took about 7.5 hours for the actual backup portion (reasonable, given the known slowness of uploading to the cloud account). However, the validation (byte-for-byte) looks like it's going to take at least 60 hours (fortunately, the machine I'm testing this on is able to stay offline from users for that amount of time, so I'm letting it finish, just to see if it completes successfully). I was surprised at this discrepancy between backup time and validation time. Is this possibly due to my breaking the backup into multiple segments? Box.com has a max upload file size of 15GB, but for other reasons, I've gotten into the habit of creating 4 GB segments for files eventually stored in the cloud, which is what I did this time (resulting in 107 files). Is this large number of segments responsible for the very slow validation (in other words would 15 GB segments somewhat increase the validation speed?).


TeraByte Support wrote:
> I think there is actually a physical copy in there so it would be like any other folder which mean it would grow. Best if there could be another drive or partition for those files. You could use /exlist but on restore it would delete the items from the folder.

Muad'Dib wrote:
> I don't have the option to change the "pretend" drive of the Box.com folder
> (unless there is a way to spoof it).

I don't really understand this, but maybe use a junction?
>
> You mentioned "/exlist" but in my reading of the IFW doc, this couldn't
> apply (the explanation says: "The file must be ANSI text and located on the
> local file system."

I think that refers to the file which is a list of things to exclude.

right click system tray icon, click gear icon in upper right, preferences,
sync, "dropbox folder location" . Wait, but you said, "box", not sure
about that one.

as far as validate time, no, I'd think it be faster, epically since it would
be using the local copy. Could be a thrashing issue.

"Muad'Dib" wrote in message news:[email protected]...

I don't have the option to change the "pretend" drive of the Box.com folder
(unless there is a way to spoof it).

You mentioned "/exlist" but in my reading of the IFW doc, this couldn't
apply (the explanation says: "The file must be ANSI text and located on the
local file system." The ANSI requirement obviously doesn't apply to a TBI
file, and it's not REALLY located on the local file system. Also, the
beginning of the description of this option says "IMPORTANT NOTE: This
option is used at your own risk. Please make sure to create standard backups
of important data." Not something that encourages someone to experiment.

Oh well, I guess I'll have to try another program (or use an intermediate
device).

BTW, backing up my drive D (about 450 GB) took about 7.5 hours for the
actual backup portion (reasonable, given the known slowness of uploading to
the cloud account). However, the validation (byte-for-byte) looks like it's
going to take at least 60 hours (fortunately, the machine I'm testing this
on is able to stay offline from users for that amount of time, so I'm
letting it finish, just to see if it completes successfully). I was
surprised at this discrepancy between backup time and validation time. Is
this possibly due to my breaking the backup into multiple segments? Box.com
has a max upload file size of 15GB, but for other reasons, I've gotten into
the habit of creating 4 GB segments for files eventually stored in the
cloud, which is what I did this time (resulting in 107 files). Is this large
number of segments responsible for the very slow validation (in other words
would 15 GB segments somewhat increase the validation speed?).


TeraByte Support wrote:
> I think there is actually a physical copy in there so it would be like any
> other folder which mean it would grow. Best if there could be another
> drive or partition for those files. You could use /exlist but on restore
> it would delete the items from the folder.