Anyone Ghosting their External Drive?

  • WELCOME TO THE NEW SERVER!

    If you are seeing this you are on our new server WELCOME HOME!

    While the new server is online Scott is still working on the backend including the cachine. But the site is usable while the work is being completes!

    Thank you for your patience and again WELCOME HOME!

    CLICK THE X IN THE TOP RIGHT CORNER OF THE BOX TO DISMISS THIS MESSAGE
Yeah, I have a WD 500 GB on the 722 and it works just fine. That's why I want to buy the same drive for the 622 but I need to transfer the shows on the old drive to the new drive and Ghost will speed up the process.
 
Yeah, I have a WD 500 GB on the 722 and it works just fine. That's why I want to buy the same drive for the 622 but I need to transfer the shows on the old drive to the new drive and Ghost will speed up the process.

WOW, good luck. Jot down the instructions when you have it all figured out and hope you share with us.
 
ok, speaking of this topic.... Have they gotten rid of the 'you can only move your drive 3 times' rule?

I have a 722 and 622... It would be nice to be able to share the recordings between them

But... I would just buy more hard drives for storage.... you can get them pretty cheap now...
 
ok, speaking of this topic.... Have they gotten rid of the 'you can only move your drive 3 times' rule?

I have a 722 and 622... It would be nice to be able to share the recordings between them

But... I would just buy more hard drives for storage.... you can get them pretty cheap now...

Haven't heard that they've fix the 3 rule yet.
 
I'm thinking of getting another EHD (WD 500 GB) and ghost the 320 GB into the new one. Will the 622 recognize the new EHD? and will it show the extra space? I don't see why this wouldn't work but just wanted to make sure.
Remember, we are talking Linux filesystems and encryption here. This would take lots of poking around to first find out how Dish has arranged the disk.

Is it an encrypted filesystem? If so, you're out of luck. Is it a normal Linux filesystem with an encrypted container? Again, you're out of luck because you won't be able to resize that container without the password/header information. Not to mention, you'd also have to know what application to use to access the container (this might even be Dish custom software - it would be stupid for them to have done that, but they might have).

The only chance for success that I can envision is if Dish is using a standard Linux filesystem, and encrypting individual files (not using a container file). Ghost might be able to handle that, or maybe not. You may have to do it on a Linux computer using dd, partition table editing, resize2fs (if it's an EXT2/3 filesystem), etc.

The other possible option is if Dish is incompetent and their "encryption" is not of the caliber that we normally talk about. Anything is theoretically possible if you're starting out with some poor implementation of copy protection by Dish. You may find things are easier than what I'm assuming above.
 
Remember, we are talking Linux filesystems and encryption here. This would take lots of poking around to first find out how Dish has arranged the disk.

Is it an encrypted filesystem? If so, you're out of luck. Is it a normal Linux filesystem with an encrypted container? Again, you're out of luck because you won't be able to resize that container without the password/header information. Not to mention, you'd also have to know what application to use to access the container (this might even be Dish custom software - it would be stupid for them to have done that, but they might have).

The only chance for success that I can envision is if Dish is using a standard Linux filesystem, and encrypting individual files (not using a container file). Ghost might be able to handle that, or maybe not. You may have to do it on a Linux computer using dd, partition table editing, resize2fs (if it's an EXT2/3 filesystem), etc.

The other possible option is if Dish is incompetent and their "encryption" is not of the caliber that we normally talk about. Anything is theoretically possible if you're starting out with some poor implementation of copy protection by Dish. You may find things are easier than what I'm assuming above.

Good luck RandallA!!
 
Thanks. I'll give it a shot this weekend, if it doesn't work I'll play around with the partitions on a Linux box I have here at work.
First, do a dd of the entire 320Gb disk to your new 500Gb disk. Partition table and all. The WHOLE disk.

Then plug that new 500Gb into your DVR to see if it works. Of course it would appear as a 320Gb disk at this point, but you want to test the basic copy before moving on to the resizing.

If you're not familiar with Linux/Unix, be sure and read the manpage for dd. Make POSITIVE SURE you understand the difference between "if=" and "of=". Do not mix these up!!! Before hitting <enter> to run the dd command, check, recheck, and rerecheck that you have "if=" and "of=" pointing to the correct devices. I'm not meaning to preach, but if you're not that familiar with Linux you might expect the dd command to confirm-prompt you with a Windows-like: "Are you REALLY sure you want to copy the blank 500 disk over the good 320 one, therefore obliterating whatever is on the 320?" That obliteration is what will happen if you mix up "if=" and "of=". dd won't warn you like Windows might.
 
First, do a dd of the entire 320Gb disk to your new 500Gb disk. Partition table and all. The WHOLE disk.

Then plug that new 500Gb into your DVR to see if it works. Of course it would appear as a 320Gb disk at this point, but you want to test the basic copy before moving on to the resizing.

If you're not familiar with Linux/Unix, be sure and read the manpage for dd. Make POSITIVE SURE you understand the difference between "if=" and "of=". Do not mix these up!!! Before hitting <enter> to run the dd command, check, recheck, and rerecheck that you have "if=" and "of=" pointing to the correct devices. I'm not meaning to preach, but if you're not that familiar with Linux you might expect the dd command to confirm-prompt you with a Windows-like: "Are you REALLY sure you want to copy the blank 500 disk over the good 320 one, therefore obliterating whatever is on the 320?" That obliteration is what will happen if you mix up "if=" and "of=". dd won't warn you like Windows might.


Thanks for the info. I'm planning on using Ghost first to image the 320GB disk to the 500 GB then plug it into the DVR to see if the data is there. Then I'll move to expanding the partition if possible.

I wonder if Partition Magic will do the trick, I'll test it this weekend. I also have Drive Image to play with this partition.
 
Last edited:
OK, seems to me you just overshooting here, haertig.

The EHD have normal EXT2/3 two partitions - first one is fixed size, have no encrypted containers ( would be nice of if you'll spend some of your time and find old threads regarding file system of the EHD, I wouldn't repeat it again ).
I have strong feeling that "3 strikes" counter stashed somewhere in files, not in unallocated sectors.
 
Well, heck, P. Smith. If it's that easy, why don't you just tell people to boot up a liveCD and copy files without further ado?
 
OK, seems to me you just overshooting here, haertig.
Possibly. Just trying to help. Sorry if that offended anyone. I don't have an external HD hooked up to my 722 so I can't check filesystem types, track0, etc., for myself.

The EHD have normal EXT2/3 two partitions - first one is fixed size, have no encrypted containers ( would be nice of if you'll spend some of your time and find old threads regarding file system of the EHD, I wouldn't repeat it again ).
It sounds like the first partition is of no great concern then (regarding copying it). Can you add any information about the second partition?

I haven't researched old posts because I'm not interested in doing this disk duping myself. Nor do I plan to pay Dish to authorize me to hook up an external to my 722 to test out theories and research. I can only offer speculation, theories, and decades of low-level computer experience to try to help. I am unable to be a guinea pig myself. Or more precisely, I am choosing not to be a guinea pig because I have no personal need to accomplish this procedure.

I have strong feeling that "3 strikes" counter stashed somewhere in files, not in unallocated sectors.
That makes sense if the three strike thing is on a per-file basis (per recorded event). I thought I had read it was on a per-disk basis. It could still be in some file even if per-disk, however. What I'm doing is speculating. I don't have the answer because I don't have an external hooked up to my 722. But I'm hoping speculating will trigger thoughts in others who can chime in and feed off of each other to help the OP (and others) who want to attempt this disk duping.
 
Sure, I could go with wider spectrum of suggestions utilizing my decades of SW development and IT jobs, but I prefer do that professionally and keep _focus_ on _relevant_ points instead of lecturing of each possible and non-possible aspects of the hobby. Sorry, but I should note your approach is totally ineffective especially in real job requirement and would cause you more trouble then acknowledge.
 
Remember, we are talking Linux filesystems and encryption here. This would take lots of poking around to first find out how Dish has arranged the disk.

Is it an encrypted filesystem? If so, you're out of luck. Is it a normal Linux filesystem with an encrypted container? Again, you're out of luck because you won't be able to resize that container without the password/header information. Not to mention, you'd also have to know what application to use to access the container (this might even be Dish custom software - it would be stupid for them to have done that, but they might have).

The only chance for success that I can envision is if Dish is using a standard Linux filesystem, and encrypting individual files (not using a container file). Ghost might be able to handle that, or maybe not. You may have to do it on a Linux computer using dd, partition table editing, resize2fs (if it's an EXT2/3 filesystem), etc.

The other possible option is if Dish is incompetent and their "encryption" is not of the caliber that we normally talk about. Anything is theoretically possible if you're starting out with some poor implementation of copy protection by Dish. You may find things are easier than what I'm assuming above.

Why? If you're doing a block level transfer this isn't a big deal. As long as ghost can take the blocks of a disk and write that to a file it shouldn't be an issue at all. These become just another file on a drive. The encrypted blocks are unchanged by ghost.

So then you restore that to another drive and Voila, you've copied it.

Expand it? Likely not. Keep it the same size and it very well might work.

Me, I haven't the time (or inclination) to validate it.

But to a program like Ghost, blocks are blocks.
 

Users Who Are Viewing This Thread (Total: 0, Members: 0, Guests: 0)

Who Read This Thread (Total Members: 1)

Latest posts