TrueCrypt & Carbonite

[Prof Wonmug]

I recently installed TrueCrypt and have been experimenting with it. I
have discovered a couple of by-products or using it with a backup
system like Carbonite, which I use.

1. While the drive is mounted, the files are in the clear to all
programs running on the machine. Before I realized this, Carbonite,
which backs up continuously, had backed up all of the supposedly
encrypted files on my test volume. With Carbonite, I am able to
designate a volume to be excluded from backup, but I must do this
explicitly. This may not be a problem for some people.

2. If the TrueCrypt file is very large (gigabytes), Carbonite excludes
it from backup by default. I can override this, but I have to
explicitly do it. This is one of the drawbacks of these
all-you-can-eat backup systems. They play games to keep you from
eating too much.

3. If you change anything on the TrueCrypt volume, the file gets
modified and must be completely backed up again -- even if only a few
bytes actually changed. If the file is in the GB range, that could
take days to back up every time it changes.

I don't know any way around any of these.

[Ari Silverstein]

On Sun, 19 Sep 2010 12:57:20 -0700, Prof Wonmug wrote:

> I recently installed TrueCrypt and have been experimenting with it. I
> have discovered a couple of by-products or using it with a backup
> system like Carbonite, which I use.
>
> 1. While the drive is mounted, the files are in the clear to all
> programs running on the machine. Before I realized this, Carbonite,
> which backs up continuously, had backed up all of the supposedly
> encrypted files on my test volume. With Carbonite, I am able to
> designate a volume to be excluded from backup, but I must do this
> explicitly. This may not be a problem for some people.
>
> 2. If the TrueCrypt file is very large (gigabytes), Carbonite excludes
> it from backup by default. I can override this, but I have to
> explicitly do it. This is one of the drawbacks of these
> all-you-can-eat backup systems. They play games to keep you from
> eating too much.
>
> 3. If you change anything on the TrueCrypt volume, the file gets
> modified and must be completely backed up again -- even if only a few
> bytes actually changed. If the file is in the GB range, that could
> take days to back up every time it changes.
>
> I don't know any way around any of these.

If you don't need Truecrypt's plausible deniability (how many do?)
turn off the "Date Modified" attribute on the file. When the
attribute is changed as you open up-close your file, Carbonite
sees backs it up.
--
http://tr.im/1fa3

[Prof Wonmug]

On Sun, 19 Sep 2010 17:10:30 -0400, Ari Silverstein
<AriSilverstein@yahoo.com> wrote:

>On Sun, 19 Sep 2010 12:57:20 -0700, Prof Wonmug wrote:
>
>> I recently installed TrueCrypt and have been experimenting with it. I
>> have discovered a couple of by-products or using it with a backup
>> system like Carbonite, which I use.
>>
>> 1. While the drive is mounted, the files are in the clear to all
>> programs running on the machine. Before I realized this, Carbonite,
>> which backs up continuously, had backed up all of the supposedly
>> encrypted files on my test volume. With Carbonite, I am able to
>> designate a volume to be excluded from backup, but I must do this
>> explicitly. This may not be a problem for some people.
>>
>> 2. If the TrueCrypt file is very large (gigabytes), Carbonite excludes
>> it from backup by default. I can override this, but I have to
>> explicitly do it. This is one of the drawbacks of these
>> all-you-can-eat backup systems. They play games to keep you from
>> eating too much.
>>
>> 3. If you change anything on the TrueCrypt volume, the file gets
>> modified and must be completely backed up again -- even if only a few
>> bytes actually changed. If the file is in the GB range, that could
>> take days to back up every time it changes.
>>
>> I don't know any way around any of these.
>
>If you don't need Truecrypt's plausible deniability (how many do?)
>turn off the "Date Modified" attribute on the file. When the
>attribute is changed as you open up-close your file, Carbonite
>sees backs it up.

I don't understand.

a. How does plausible deniability relate to this? I thought it meant
using a hidden volume, instead of a file.

b. Do you mean resetting the "Modified" attribute of the TrueCrypt
file so that Carbonite will not know that the file has changed and not
back it up again?

First of all, I don't want to fool Carbonite into not backing it up. I
want the file backed up. I just wish there were a way to avoid sending
10 GB of data across the Internet when only a few MB changed.

Secondly, I don't think that will work. I'm pretty sure that Carbonite
compares the file date with the file date in its database. If it's
different, it schedyled it for backup. I justr did a little test. I
created a small text file in the TrueCrypt folder. Carbonite put a
little yellow dot on the file icon indicating that it is scheduled for
backup. I told Carbonite to back it up immediately, which it did. It
then turned the yellow dot green. I then reset the modified attribute
checkbox and edited the file. Carbonite noticed the change and changed
the dot back to yellow. I check the file attributes and the modified
checkbox was still unchecked.

[Ari Silverstein]

On Mon, 20 Sep 2010 10:08:07 -0700, Prof Wonmug wrote:

> On Sun, 19 Sep 2010 17:10:30 -0400, Ari Silverstein
> <AriSilverstein@yahoo.com> wrote:
>
>>On Sun, 19 Sep 2010 12:57:20 -0700, Prof Wonmug wrote:
>>
>>> I recently installed TrueCrypt and have been experimenting with it. I
>>> have discovered a couple of by-products or using it with a backup
>>> system like Carbonite, which I use.
>>>
>>> 1. While the drive is mounted, the files are in the clear to all
>>> programs running on the machine. Before I realized this, Carbonite,
>>> which backs up continuously, had backed up all of the supposedly
>>> encrypted files on my test volume. With Carbonite, I am able to
>>> designate a volume to be excluded from backup, but I must do this
>>> explicitly. This may not be a problem for some people.
>>>
>>> 2. If the TrueCrypt file is very large (gigabytes), Carbonite excludes
>>> it from backup by default. I can override this, but I have to
>>> explicitly do it. This is one of the drawbacks of these
>>> all-you-can-eat backup systems. They play games to keep you from
>>> eating too much.
>>>
>>> 3. If you change anything on the TrueCrypt volume, the file gets
>>> modified and must be completely backed up again -- even if only a few
>>> bytes actually changed. If the file is in the GB range, that could
>>> take days to back up every time it changes.
>>>
>>> I don't know any way around any of these.
>>
>>If you don't need Truecrypt's plausible deniability (how many do?)
>>turn off the "Date Modified" attribute on the file. When the
>>attribute is changed as you open up-close your file, Carbonite
>>sees backs it up.
>
> I don't understand.
>
> a. How does plausible deniability relate to this? I thought it meant
> using a hidden volume, instead of a file.

Both and more.

> b. Do you mean resetting the "Modified" attribute of the TrueCrypt
> file so that Carbonite will not know that the file has changed and not
> back it up again?

The opposite.

> First of all, I don't want to fool Carbonite into not backing it up.

Then live with what you have. Replicating information only increases
your chances of having that information found and uncovered. Backing
up online exposes you to discovery without any possible knowledge that
you have been compromised.

[Mark F]

On Sun, 19 Sep 2010 12:57:20 -0700, Prof Wonmug <wonmug@moo.gov>
wrote:

> I recently installed TrueCrypt and have been experimenting with it. I
> have discovered a couple of by-products or using it with a backup
> system like Carbonite, which I use.
>
> 1. While the drive is mounted, the files are in the clear to all
> programs running on the machine. Before I realized this, Carbonite,
> which backs up continuously, had backed up all of the supposedly
> encrypted files on my test volume. With Carbonite, I am able to
> designate a volume to be excluded from backup, but I must do this
> explicitly. This may not be a problem for some people.
>
> 2. If the TrueCrypt file is very large (gigabytes), Carbonite excludes
> it from backup by default. I can override this, but I have to
> explicitly do it. This is one of the drawbacks of these
> all-you-can-eat backup systems. They play games to keep you from
> eating too much.
>
> 3. If you change anything on the TrueCrypt volume, the file gets
> modified and must be completely backed up again -- even if only a few
> bytes actually changed. If the file is in the GB range, that could
> take days to back up every time it changes.
Crash Plan (and perhaps other products) do a better job of handling
large files: they only backup the parts that have changed.

Crash Plan seems to scan the entire file for changes and only backs up
the changed data, reducing the time needed for your backup to
complete. I think it also saves storage space for them at storage
side, which in the case of Crash Plan can be their central side, a
local or LAN disk of yours, or a "friend"s disk.

I have Crash Plan for backups of TrueCrypt volumes and for VMware
virtual disks (I put my big TrueCrypt volumes "inside" of VMware
virtual disks so that I can have multi-part container files.
Unfortunately the modified date changes for each of the 2GB VMware
container files when a volume is mounted, Crash Plan has to scan
all of the 2GB containers, rather than just the ones that actually
got changed while the virtual disk was mounted.) Crash Plan scans
at just about full disk speed, so a 2GB file takes about 20 seconds to
scan. Things would be impractical for me with a 300GB virtual disk
that I typically only change a few small files on each time I mount,
but I use Crash Plan for a bunch of 2, 4, and 8GB TrueCrypt files.
>
> I don't know any way around any of these.
Like I say, use Crash Plan - it only transmits the changed data and
much faster than Carbonite anyhow.

[Prof Wonmug]

On Mon, 20 Sep 2010 15:37:49 -0400, Ari Silverstein
<AriSilverstein@yahoo.com> wrote:

>On Mon, 20 Sep 2010 10:08:07 -0700, Prof Wonmug wrote:
>
>> On Sun, 19 Sep 2010 17:10:30 -0400, Ari Silverstein
>> <AriSilverstein@yahoo.com> wrote:
>>
>>>On Sun, 19 Sep 2010 12:57:20 -0700, Prof Wonmug wrote:
>>>
>>>> I recently installed TrueCrypt and have been experimenting with it. I
>>>> have discovered a couple of by-products or using it with a backup
>>>> system like Carbonite, which I use.
>>>>
>>>> 1. While the drive is mounted, the files are in the clear to all
>>>> programs running on the machine. Before I realized this, Carbonite,
>>>> which backs up continuously, had backed up all of the supposedly
>>>> encrypted files on my test volume. With Carbonite, I am able to
>>>> designate a volume to be excluded from backup, but I must do this
>>>> explicitly. This may not be a problem for some people.
>>>>
>>>> 2. If the TrueCrypt file is very large (gigabytes), Carbonite excludes
>>>> it from backup by default. I can override this, but I have to
>>>> explicitly do it. This is one of the drawbacks of these
>>>> all-you-can-eat backup systems. They play games to keep you from
>>>> eating too much.
>>>>
>>>> 3. If you change anything on the TrueCrypt volume, the file gets
>>>> modified and must be completely backed up again -- even if only a few
>>>> bytes actually changed. If the file is in the GB range, that could
>>>> take days to back up every time it changes.
>>>>
>>>> I don't know any way around any of these.
>>>
>>>If you don't need Truecrypt's plausible deniability (how many do?)
>>>turn off the "Date Modified" attribute on the file. When the
>>>attribute is changed as you open up-close your file, Carbonite
>>>sees backs it up.
>>
>> I don't understand.
>>
>> a. How does plausible deniability relate to this? I thought it meant
>> using a hidden volume, instead of a file.
>
>Both and more.

Well, that certainly clears that up.

>> b. Do you mean resetting the "Modified" attribute of the TrueCrypt
>> file so that Carbonite will not know that the file has changed and not
>> back it up again?
>
>The opposite.

?

>> First of all, I don't want to fool Carbonite into not backing it up.
>
>Then live with what you have. Replicating information only increases
>your chances of having that information found and uncovered. Backing
>up online exposes you to discovery without any possible knowledge that
>you have been compromised.

Ah, one of the grassy knoll types. Now I understand. Thanks.

[Prof Wonmug]

On Mon, 20 Sep 2010 15:58:08 -0400, Mark F <mark53916@gmail.com>
wrote:

>On Sun, 19 Sep 2010 12:57:20 -0700, Prof Wonmug <wonmug@moo.gov>
>wrote:
>
>> I recently installed TrueCrypt and have been experimenting with it. I
>> have discovered a couple of by-products or using it with a backup
>> system like Carbonite, which I use.
>>
>> 1. While the drive is mounted, the files are in the clear to all
>> programs running on the machine. Before I realized this, Carbonite,
>> which backs up continuously, had backed up all of the supposedly
>> encrypted files on my test volume. With Carbonite, I am able to
>> designate a volume to be excluded from backup, but I must do this
>> explicitly. This may not be a problem for some people.
>>
>> 2. If the TrueCrypt file is very large (gigabytes), Carbonite excludes
>> it from backup by default. I can override this, but I have to
>> explicitly do it. This is one of the drawbacks of these
>> all-you-can-eat backup systems. They play games to keep you from
>> eating too much.
>>
>> 3. If you change anything on the TrueCrypt volume, the file gets
>> modified and must be completely backed up again -- even if only a few
>> bytes actually changed. If the file is in the GB range, that could
>> take days to back up every time it changes.
>Crash Plan (and perhaps other products) do a better job of handling
>large files: they only backup the parts that have changed.
>
>Crash Plan seems to scan the entire file for changes and only backs up
>the changed data, reducing the time needed for your backup to
>complete. I think it also saves storage space for them at storage
>side, which in the case of Crash Plan can be their central side, a
>local or LAN disk of yours, or a "friend"s disk.
>
>I have Crash Plan for backups of TrueCrypt volumes and for VMware
>virtual disks (I put my big TrueCrypt volumes "inside" of VMware
>virtual disks so that I can have multi-part container files.
>Unfortunately the modified date changes for each of the 2GB VMware
>container files when a volume is mounted, Crash Plan has to scan
>all of the 2GB containers, rather than just the ones that actually
>got changed while the virtual disk was mounted.) Crash Plan scans
>at just about full disk speed, so a 2GB file takes about 20 seconds to
>scan. Things would be impractical for me with a 300GB virtual disk
>that I typically only change a few small files on each time I mount,
>but I use Crash Plan for a bunch of 2, 4, and 8GB TrueCrypt files.
>>
>> I don't know any way around any of these.
>Like I say, use Crash Plan - it only transmits the changed data and
>much faster than Carbonite anyhow.

How does it know what changed? By doing a binary compare?

Have you tried it with a TrueCrypt file? I don't know for sure, but I
would imagine that a TrueCrypt file might have extensive changes if
even only 1% of the unencrypted data changed.

If I get a minute, I might run a binary compare after changing one
file in a 100 file repository.

I looked at the CrashPlan website. I found it a lot more muddled than
Carbonite. A lot of options that are not clearly explained. Carbonite
may not be perfect, but it is what it says in the ads: Backup. Simple.

I may try CrashPlan if I get time, but my initial impression was only
average.

[Ari Silverstein]

On Mon, 20 Sep 2010 13:55:49 -0700, Prof Wonmug wrote:

> How does it know what changed? By doing a binary compare?

Why do you care as long as it bups it?

> Have you tried it with a TrueCrypt file? I don't know for sure, but I
> would imagine that a TrueCrypt file might have extensive changes if
> even only 1% of the unencrypted data changed.

Can you not read and troll at the same time? Mark said "I have Crash
Plan for backups of TrueCrypt volumes".

> If I get a minute, I might run a binary compare after changing one
> file in a 100 file repository.

Take that minute off your Usenet time.

> I looked at the CrashPlan website. I found it a lot more muddled than
> Carbonite. A lot of options that are not clearly explained. Carbonite
> may not be perfect, but it is what it says in the ads: Backup. Simple.

Why not a floppy disk? Simple. Backup.

> I may try CrashPlan if I get time, but my initial impression was only
> average.

You are working from a diminished mental state, not surprised.
--
Passwords, people, they are not just for game shows. If you refuse to
make the effort to remember a few long, diverse passwords, then don't
scream at me when your FICO is 496 and your bank accounts are zeroed
out.

[Prof Wonmug]

On Mon, 20 Sep 2010 22:39:19 -0400, Ari Silverstein
<AriSilverstein@yahoo.com> wrote:

>On Mon, 20 Sep 2010 13:55:49 -0700, Prof Wonmug wrote:
>
>> How does it know what changed? By doing a binary compare?
>
>Why do you care as long as it bups it?
>
>> Have you tried it with a TrueCrypt file? I don't know for sure, but I
>> would imagine that a TrueCrypt file might have extensive changes if
>> even only 1% of the unencrypted data changed.
>
>Can you not read and troll at the same time? Mark said "I have Crash
>Plan for backups of TrueCrypt volumes".
>
>> If I get a minute, I might run a binary compare after changing one
>> file in a 100 file repository.
>
>Take that minute off your Usenet time.
>
>> I looked at the CrashPlan website. I found it a lot more muddled than
>> Carbonite. A lot of options that are not clearly explained. Carbonite
>> may not be perfect, but it is what it says in the ads: Backup. Simple.
>
>Why not a floppy disk? Simple. Backup.
>
>> I may try CrashPlan if I get time, but my initial impression was only
>> average.
>
>You are working from a diminished mental state, not surprised.

Whoa. I forgot that you brassy knoll types are kinda sensitive. Bye.

[Mark F]

On Mon, 20 Sep 2010 13:55:49 -0700, Prof Wonmug <wonmug@moo.gov>
wrote:

> On Mon, 20 Sep 2010 15:58:08 -0400, Mark F <mark53916@gmail.com>
> wrote:
>
> >On Sun, 19 Sep 2010 12:57:20 -0700, Prof Wonmug <wonmug@moo.gov>
> >wrote:
> >
> >> I recently installed TrueCrypt and have been experimenting with it. I
> >> have discovered a couple of by-products or using it with a backup
> >> system like Carbonite, which I use.
> >>
> >> 1. While the drive is mounted, the files are in the clear to all
> >> programs running on the machine. Before I realized this, Carbonite,
> >> which backs up continuously, had backed up all of the supposedly
> >> encrypted files on my test volume. With Carbonite, I am able to
> >> designate a volume to be excluded from backup, but I must do this
> >> explicitly. This may not be a problem for some people.
> >>
> >> 2. If the TrueCrypt file is very large (gigabytes), Carbonite excludes
> >> it from backup by default. I can override this, but I have to
> >> explicitly do it. This is one of the drawbacks of these
> >> all-you-can-eat backup systems. They play games to keep you from
> >> eating too much.
> >>
> >> 3. If you change anything on the TrueCrypt volume, the file gets
> >> modified and must be completely backed up again -- even if only a few
> >> bytes actually changed. If the file is in the GB range, that could
> >> take days to back up every time it changes.
> >Crash Plan (and perhaps other products) do a better job of handling
> >large files: they only backup the parts that have changed.
> >
> >Crash Plan seems to scan the entire file for changes and only backs up
> >the changed data, reducing the time needed for your backup to
> >complete. I think it also saves storage space for them at storage
> >side, which in the case of Crash Plan can be their central side, a
> >local or LAN disk of yours, or a "friend"s disk.
> >
> >I have Crash Plan for backups of TrueCrypt volumes and for VMware
> >virtual disks (I put my big TrueCrypt volumes "inside" of VMware
> >virtual disks so that I can have multi-part container files.
> >Unfortunately the modified date changes for each of the 2GB VMware
> >container files when a volume is mounted, Crash Plan has to scan
> >all of the 2GB containers, rather than just the ones that actually
> >got changed while the virtual disk was mounted.) Crash Plan scans
> >at just about full disk speed, so a 2GB file takes about 20 seconds to
> >scan. Things would be impractical for me with a 300GB virtual disk
> >that I typically only change a few small files on each time I mount,
> >but I use Crash Plan for a bunch of 2, 4, and 8GB TrueCrypt files.
> >>
> >> I don't know any way around any of these.
> >Like I say, use Crash Plan - it only transmits the changed data and
> >much faster than Carbonite anyhow.
>
> How does it know what changed? By doing a binary compare?
>
> Have you tried it with a TrueCrypt file? I don't know for sure, but I
> would imagine that a TrueCrypt file might have extensive changes if
> even only 1% of the unencrypted data changed.
Yes, I've tried with a TrueCrypt file and unencrypted VMware files.
CrashPlan seems to read the entire container file (or files in the
case of some VMware virtual disks.) I assume that CrashPlan keeps a
check sum of blocks (which might not match the disk block or sector
size) and transmits only the blocks for which the checksum changed.

By timing thing I can tell not much extra is transmitted. (Don't
defragment your virtual disks if you don't want a lot of backup
activity; defragmenting of the container files is fine.)

Scanning the disk at about 10MB/second (67Mbps per CrashPlan) on the
machine I am testing things on, no network transfers noticed. Using
about 25% CPU time (Pentium 4 2.4GHz) I think I have seen 50MB in the
past, but I can't get to that machine now. Test is being done on
Windows XP Professional. I'll try on a Windows 7 system when I get a
chance.) (I just noticed that the CrashPlan status window takes 13%
of the system and just sitting here in Agent takes 21%, so I'll have
to do the experiment differently on the other system.)
>
> If I get a minute, I might run a binary compare after changing one
> file in a 100 file repository.
>
> I looked at the CrashPlan website. I found it a lot more muddled than
> Carbonite. A lot of options that are not clearly explained. Carbonite
> may not be perfect, but it is what it says in the ads: Backup. Simple.
>
> I may try CrashPlan if I get time, but my initial impression was only
> average.

[Prof Wonmug]

On Tue, 21 Sep 2010 18:15:50 -0400, Mark F <mark53916@gmail.com>
wrote:

>On Mon, 20 Sep 2010 13:55:49 -0700, Prof Wonmug <wonmug@moo.gov>
>wrote:
>
>> On Mon, 20 Sep 2010 15:58:08 -0400, Mark F <mark53916@gmail.com>
>> wrote:
>>
>> >On Sun, 19 Sep 2010 12:57:20 -0700, Prof Wonmug <wonmug@moo.gov>
>> >wrote:
>> >
>> >> I recently installed TrueCrypt and have been experimenting with it. I
>> >> have discovered a couple of by-products or using it with a backup
>> >> system like Carbonite, which I use.
>> >>
>> >> 1. While the drive is mounted, the files are in the clear to all
>> >> programs running on the machine. Before I realized this, Carbonite,
>> >> which backs up continuously, had backed up all of the supposedly
>> >> encrypted files on my test volume. With Carbonite, I am able to
>> >> designate a volume to be excluded from backup, but I must do this
>> >> explicitly. This may not be a problem for some people.
>> >>
>> >> 2. If the TrueCrypt file is very large (gigabytes), Carbonite excludes
>> >> it from backup by default. I can override this, but I have to
>> >> explicitly do it. This is one of the drawbacks of these
>> >> all-you-can-eat backup systems. They play games to keep you from
>> >> eating too much.
>> >>
>> >> 3. If you change anything on the TrueCrypt volume, the file gets
>> >> modified and must be completely backed up again -- even if only a few
>> >> bytes actually changed. If the file is in the GB range, that could
>> >> take days to back up every time it changes.
>> >Crash Plan (and perhaps other products) do a better job of handling
>> >large files: they only backup the parts that have changed.
>> >
>> >Crash Plan seems to scan the entire file for changes and only backs up
>> >the changed data, reducing the time needed for your backup to
>> >complete. I think it also saves storage space for them at storage
>> >side, which in the case of Crash Plan can be their central side, a
>> >local or LAN disk of yours, or a "friend"s disk.
>> >
>> >I have Crash Plan for backups of TrueCrypt volumes and for VMware
>> >virtual disks (I put my big TrueCrypt volumes "inside" of VMware
>> >virtual disks so that I can have multi-part container files.
>> >Unfortunately the modified date changes for each of the 2GB VMware
>> >container files when a volume is mounted, Crash Plan has to scan
>> >all of the 2GB containers, rather than just the ones that actually
>> >got changed while the virtual disk was mounted.) Crash Plan scans
>> >at just about full disk speed, so a 2GB file takes about 20 seconds to
>> >scan. Things would be impractical for me with a 300GB virtual disk
>> >that I typically only change a few small files on each time I mount,
>> >but I use Crash Plan for a bunch of 2, 4, and 8GB TrueCrypt files.
>> >>
>> >> I don't know any way around any of these.
>> >Like I say, use Crash Plan - it only transmits the changed data and
>> >much faster than Carbonite anyhow.
>>
>> How does it know what changed? By doing a binary compare?
>>
>> Have you tried it with a TrueCrypt file? I don't know for sure, but I
>> would imagine that a TrueCrypt file might have extensive changes if
>> even only 1% of the unencrypted data changed.
>Yes, I've tried with a TrueCrypt file and unencrypted VMware files.
>CrashPlan seems to read the entire container file (or files in the
>case of some VMware virtual disks.) I assume that CrashPlan keeps a
>check sum of blocks (which might not match the disk block or sector
>size) and transmits only the blocks for which the checksum changed.

Keeping a checksum at the block level is creative.

>By timing thing I can tell not much extra is transmitted. (Don't
>defragment your virtual disks if you don't want a lot of backup
>activity; defragmenting of the container files is fine.)
>
>Scanning the disk at about 10MB/second (67Mbps per CrashPlan) on the
>machine I am testing things on, no network transfers noticed. Using
>about 25% CPU time (Pentium 4 2.4GHz) I think I have seen 50MB in the
>past, but I can't get to that machine now. Test is being done on
>Windows XP Professional. I'll try on a Windows 7 system when I get a
>chance.) (I just noticed that the CrashPlan status window takes 13%
>of the system and just sitting here in Agent takes 21%, so I'll have
>to do the experiment differently on the other system.)

I'll have to run some tests, myself.

Thanks