Results 1 to 11 of 11

Thread: TrueCrypt & Carbonite

  1. #1
    Prof Wonmug
    Guest

    TrueCrypt & Carbonite

    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.

  2. #2
    Ari Silverstein
    Guest

    Re: TrueCrypt & Carbonite

    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

  3. #3
    Prof Wonmug
    Guest

    Re: TrueCrypt & Carbonite

    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.

  4. #4
    Ari Silverstein
    Guest

    Re: TrueCrypt & Carbonite

    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.

  5. #5
    Mark F
    Guest

    Re: TrueCrypt & Carbonite

    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.

  6. #6
    Prof Wonmug
    Guest

    Re: TrueCrypt & Carbonite

    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.

  7. #7
    Prof Wonmug
    Guest

    Re: TrueCrypt & Carbonite

    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.

  8. #8
    Ari Silverstein
    Guest

    Re: TrueCrypt & Carbonite

    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.

  9. #9
    Prof Wonmug
    Guest

    Re: TrueCrypt & Carbonite

    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.

  10. #10
    Mark F
    Guest

    Re: TrueCrypt & Carbonite

    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.


  11. #11
    Prof Wonmug
    Guest

    Re: TrueCrypt & Carbonite

    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

Similar Threads

  1. Truecrypt 7.0 Released
    By nemo_outis in forum alt.computer.security
    Replies: 0
    Last Post: 07-20-10, 12:33 PM
  2. How does whole-disk encryption work?
    By Prof Wonmug in forum alt.computer.security
    Replies: 16
    Last Post: 02-04-10, 08:15 AM
  3. Are passphrases allowed in TrueCrypt?
    By marck@eopq9.net in forum alt.computer.security
    Replies: 7
    Last Post: 01-10-10, 07:20 AM
  4. Truecrypt 6.3 Released
    By nemo_outis in forum alt.computer.security
    Replies: 0
    Last Post: 10-22-09, 12:43 AM
  5. carbonite
    By horsemen_ in forum General Discussion Board
    Replies: 3
    Last Post: 04-24-07, 07:24 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •