Backing up hacked 6.2 killhdinitrd drive

[NoCalME]

I've done a good deal of searching, but I'm still confused on which switches I should use with mfstools in order to create a backup of my hacked 6.2 killhdinitrd drive that can be restored to another drive/DirecTiVo. I've seen threads where people mention mfstools can backup and restore a hacked drive with the correct paramaters, but they don't mention what those paramaters are?

I've tried the command line:
mfsbackup -f 4138 -6so /mnt/c/backup.mfs /dev/hdc
But from what I've read, I shouldn't use the -f 4138 switch? The image restores ok to another drive/DirecTiVo, but audio sync is messed up when shows are extracted. So I assume I'm not properly creating the backup image. When I restore the same backup hacked drive image to another drive but the same DirecTiVo, everything works perfectly. According to the Hinsdale guide, the proper command is mfsbackup -f 9999 -6so for a Series 2 DirecTiVo, but some have reported that -f 9999 should not be used on a drive that has been in service.

I found this thread (http://www.dealdatabase.com/forum/showthread.php?p=125707&highlight=mfsbackup+options#post125707) that lists the different switches one can use. So I'm thinking I should use mfsbackup -Taso? Or, would the usage of dd to make an exact copy be the better option?

**UPDATE**
Okay, a bit more searching uncovered a post by a veteran DDB'er that leads me to believe the commands I need to use to backup and restore my hacked drive are:
mfsbackup -Taso /mnt/c/backup.mfs /dev/hdc & mfsrestore -s 127 -xzpi /dev/hdc
I'll give this a run.

[PlainBill]

The proper commands depend on what you are trying to do. If you want to make a minimal size backup (without recordings), 'mfsbackup -l xx -6so /mnt/c/backup.mfs /dev/hdc' will work. See Jamie's post here (http://www.dealdatabase.com/forum/showpost.php?p=224111&postcount=2) for the proper value for xx. (If you want to guess, use something like 20).

To restore and expand the image to the full capacity of a drive, use 'mfsrestore -s 127 -xzpi /mnt/c/backup.mfs /dev/hdc'

You can use 'mfsbackup -Taso /mnt/c/backup.mfs /dev/hdc' only if you are backing up a new drive (no recordings), or a drive on which 'clear and delete everything' has just been run.

PlainBill

[NoCalME]

I should have stated in my post that my goal was to create a minimal size backup of my hacked drive that will fit on my 15 GB DOS drive. The hacked drive has no recordings on it, so the -l xx -6so switch you provided is just what the doctor ordered. The result was a 1351 MB backup image.

Appreciate the help.

[jjz]

Hopefully I'm not hijacking this thread but I have a similiar question-
I started with my stock HDVR2 drive (updated to 6.2) and replaced it with a 80g drive using this command:
mfsbackup -f 9999 -so - /dev/hdA (/dev/hdY) | mfsrestore -s 127 -xzpi - /dev/hdB

I then killhdinitrd the 80g drive using the PTVupgrade LBA48 4.01 with Enhancements disc and added several hacks- tivowebplus, elseed etc..

Now I would like to replace the 80g drive with a much larger drive- probably around 200g- In order to preserve all my hacks (I've only recorded one show to test out streaming to WMP- which works like a charm!!) I'm assuming I can't just repeat what I did above- instead do I need to use the -Tao switch i.e.
mfsbackup -Tao - /dev/hda | mfsrestore -s 127 -xzpi - /dev/hdb
thanks JZ

[AhoyMatey]

You're going to have to use the "s" option to shrink the volume on backup. You've already expanded once, so you can't expand again. Jamie has a way to expand more than once around here somewhere.

[eastwind]

Or you can use the original HDVR2 as a jumpinging off point and then dd the correct partitions from the 80GB drive (or just re-hack).

ew

[Gildor57]

Are the custom -l/-f options necessary for doing backups for later restoring to another drive?

I backed up my original HDVR2 way back when using the -f 9999 option. I then did an mfsrestore, expadned with all new drives. Basically, the standard Hinsdale approach. Worked fine, including hacks, extractions, etc.

The HDVR2 recently died with a bad motherboard, or (more likely) power supply. I acquired a replacement HDVR2, and put in two brand new drives (don't ask).

I mfsrestored and expanded the new drives from my original 3.1.1d image using the PTVUpgrade disk (free one). Booted up in the Tivo and let DirecTV load up 6.2 for me. Removed the drives, booted the PC, backed up, installed a killhdinitrd'ed 3.1.5 kernel, backed up, checked it out, installed some hacks, pulled and backed up again (I really need to research how to mfsbackup directly from the Tivo), and continued on. I had several DM's (Doh! moments) where I had to restore from one of the backups because I messed something up.

In all cases I never had any kind of problem (granted, the last few times I restored to the same drives I had backed up from). All of my backups are 1.3-1.4 GB in size. I didn't worry about saving recordings.

Thats why I ask about the custom option settings. Using the -f 9999 in mfsbackup option worked perfectly for me. Maybe its beacuse I was doing a "standard" upgrade/install hacks and not trying to save recordings?

[jjz]

So it looks like the way to go is to run:
1)run 'clear and delete everything' on the 80g drive and then
2)run mfsbackup -Taso - /dev/hda | mfsrestore -s 127 -xzpi - /dev/hdb

I'll give that a go- thanks for all the reponses

[PlainBill]

Are the custom -l/-f options necessary for doing backups for later restoring to another drive?

<SNIP>

Thats why I ask about the custom option settings. Using the -f 9999 in mfsbackup option worked perfectly for me. Maybe its beacuse I was doing a "standard" upgrade/install hacks and not trying to save recordings?
Generally, the standard -f 9999 (or better, -F19999) will work if you'e dealing with a new drive. It will often result in 'transparent backgrounds' on a drive that has been used for a while. Using -l 20 seems to work better, producing a smaller image without losing backgrounds, etc.

PlainBill

[Gildor57]

Generally, the standard -f 9999 (or better, -F19999) will work if you'e dealing with a new drive. It will often result in 'transparent backgrounds' on a drive that has been used for a while. Using -l 20 seems to work better, producing a smaller image without losing backgrounds, etc.

Ah. Thanks PlainBill. That explains it for me since in all instances I was using new drives.