# Backup/Restore from/to 750GB - not enough space?



## AbMagFab (Feb 5, 2001)

So I have a 750GB Seagate ES drive, and it's too noisy so I want to replace it with a 750GB DB35 drive.

I popped both in my PC, ran the backup | restore, and after scanning the source drive it told me that my destination drive wasn't big enough?

I know there are slight differences in drive sizes, but from a Seagate to a Seagate?

I ran:
backup -qTao - /dev/sda | restore -s 128 -r 4 -xzpi - /dev/sdb


I restored a clean image to the new drive just to make sure it works, and it does (and reports the same hours on the Tivo), but I'd really like to keep all my old recordings.

Anyone have a solution/workaround to this?


----------



## HomeUser (Jan 12, 2003)

use cat /proc/partitions both drive sizes in sectors will be about the top line in the output hopefully the new drive is the same or slightly larger if not you might be able to trim the swap partition a little.

Oh and remove the 'x' from the restore side you can only expand once.

Another problem if you are using the standard LBA48 MFSTools2 boot CD from WeaKnees or PTVUpgrade the -s 128 can not be larger then -s 127


----------



## AbMagFab (Feb 5, 2001)

I'm using mfslive, so that should be okay?

For cat /proc/partitions, do I do literally just that, do I need to mount a parition on each drive first, or something else? Never seen /proc/partitions, so just asking (and can't get back to my computer for a couple hours).

Dumb question - to trim the swap partition, I just reduce the 128 number, right?


----------



## HomeUser (Jan 12, 2003)

Yes from the Linux prompt type cat /proc/partitions then press enter, no you do not need to mount anything.

The values for the swap partition greater then 127 is reported to be fixed in MFSLive. Reducing the value will free up space for the other partitions it would be helpful to know the actual size of the drives and the swap partition size on the old drive you do not want to make the swap too small.


----------



## spike2k5 (Feb 21, 2006)

AbMagFab said:


> So I have a 750GB Seagate ES drive, and it's too noisy so I want to replace it with a 750GB DB35 drive.
> 
> I ran:
> backup -qTao - /dev/sda | restore -s 128 -r 4 -xzpi - /dev/sdb
> ...


First, you are copying from 750Gb to 750GB so you don't need "x" option

backup -qTao - /dev/sda | restore -s 128 -r 4 -zpi - /dev/sdb

Also, if you used older mfstools to expand to 750GB, there was a alternate partition shrink bug and mfslive cd corrects that so you don't have enough space on the new 750GB.

Also, if you used -s 127 to expand your old 750GB, you won't be able to use -s 128 becuase you don't have enough space on the new 750GB drive.

Check # of sectors on the old and new. Make sure new one is the same size or bigger.

Most likely, you will need to use the old mfstools to copy or use dd (bit by bit copy)


----------



## AbMagFab (Feb 5, 2001)

Weird... Looks like just removing the X fixed this.

Yes, I'm using mfslive now, and yes, I used an older mfstools before. 

Is there anything "bad" I'm bringing over by doing this? Would I be better off in the long term just starting over with an mfslive prepared disk? Or does the mfslive backup/restore clean up the old partition shrink bug?

Also, it looks like it's going to take about 5 hours to complete. Does that sound about right? Running on a Core2Duo 2.4 with 4GB of memory, using mfslive.


----------



## spike2k5 (Feb 21, 2006)

AbMagFab said:


> Weird... Looks like just removing the X fixed this.
> 
> Yes, I'm using mfslive now, and yes, I used an older mfstools before.
> 
> ...


If you copy over, you might have alternate partition shrinkage, depending on which partition was active at the moment.

Other than that you should be ok.

after it's done (4 hr sounds right)
try

pdisk -l /dev/sdb

where l is lower case L

if partition 4 and 7 are 256MB you are good.
If one of them is 128MB you have a shinkage bug.


----------



## AbMagFab (Feb 5, 2001)

My source drive is 128/256 (I did a partition check before the copy that's still on the screen). Does this mean my destination will be also? Is there any fix for this?

I'd rather stop the copy now if it's just going to propogate a bug. What's the implication of the partition shrink bug?


----------



## HomeUser (Jan 12, 2003)

I think MFSLIve fixes that the problem is if there is the extra 128M on the destination drive.

did you notice if there was a difference the total drive size (top numbers)?


----------



## AbMagFab (Feb 5, 2001)

Top number was identical on both drives. And I restored a clean S3 image to the new drive to test it (before learning not to use x above), and it was 256/256 for those partitions prior to the copy.

About 90 minutes left until the copy is done, then I can test.

So what's the long term effect of the 128MB shrunk partition?


----------



## spike2k5 (Feb 21, 2006)

AbMagFab said:


> So what's the long term effect of the 128MB shrunk partition?


It's ok for now but if tivoapp gets any bigger or if tivo adds more stuff to the root partition, you might have problem.

mfslive beta fixes that problem but your 750GB might not have enough room to expand the root to 256MB.

So I guess you are stuck with it unless you start fresh do truncated backup | restore.


----------

