Edward Ned Harvey wrote: > Ummm... Maybe I'm misunderstanding what you're saying, because the way I > got it, you're not making any sense. You're saying to do sector-by-sector, > but you're also saying Acronis knows which blocks are unused and will skip > them. > > The point of the "sector by sector" option is to tell Acronis, "I don't want > you to think about or care about NTFS or anything. Eliminate all your > intelligence, and simply copy every byte from the device." This means "I > want you to backup unused space," and it means "Even if there's an unknown > filesystem in there, which is not NTFS or anything you recognize, back it up > anyway, every single byte." > > Normally a sector-by-sector backup is only done for unknown filesystems, or > filesystems which are suspected of corruption, or if you have some reason > you think there's valuable information stored in the unused space. For > example, if a virus did a quick format on your hard drive ... All the data > still exists, but the filesystem is gone so you can't access any of it. So > then you would want some utility to scan all the bits, saying "these blocks > look like they might be a jpg image ... and these blocks look like they > might be a word doc ..." and so on, attempting to reconstruct your deleted > files. If you're paranoid, you might do a sector-by-sector backup of the > disk before you allow any utility in the world to start reading from it or > working on it.
Sorry, you are right... I was getting a couple of options mixed up. http://www.acronis.com/backup-recovery/comparison.html I am really talking about the "Block level image backup", not the "Sector-by-sector backup". I used to be a developer at a small company (that went under), that made an appliance that was used for the target for the backup files. We had automation to encrypt and transfer the .tib files to a secured datacenter as a DR service for the SMB market. We had a client side piece that was a wrapper around Acronis. Since this was designed for DR with bare metal restore, we used block level backups. >> hrm... I guess baring finding a copy utility that understands sparse >> files, >> you would be left with the restore partition option. >> >> Have you tried robocopy to copy from the mounted .tib? (I haven't tried >> it.) > > There are plenty of copy utilities that recognize sparse files. You can "cp > --sparse=always" or something like that ... and you can "tar cf - somefile | > (cd /destination ; tar xf - --sparse)" and various other incantations ... > > Yes, I tried this. Again, "ask me how I know." :-( At one point, I did in > fact restore a 50G file that was supposed to be sparse, just to get one tiny > txt file out of it. It only took overnight. > > However, when you mount a TIB file, it does not become a drive letter. You > can't browse there with cygwin, or winzip, or any other application. The > TIB mounter is a Windows Explorer extension, so only WE is able to browse > through the image to grab things out. WE is the weak point here ... Simply > dragging and dropping a file is your only option, and that doesn't do > sparse. > Ya, I haven't messed with this side much. Though now there are utilities that will convert .tib into virtual drives. (.vhd, .vmdk,...) -- END OF LINE --MCP _______________________________________________ Tech mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
