This is on a 2009 Intel Quad, dual boot, BIOS machine, 8 GB RAM, plenty unallocated space on (2) WD 1 TB internal HDDs.

Accidentally deleted some apps prog files from /opt (/opt is a separate partition).
Severe back pain - should've stopped. Later reinstall the apps.

Went from a few deleted apps (not the partition), to NO valid partitions showing on /sda in Gparted or any tool. Of course, it won't boot.

Have NOT booted into Mint, after deleting the apps, so TestDisk quick scan finds all the "missing" partitions (I believe). TD is satisfied they're OK. At minimum, the partition table was damaged.

I've read TestDisk's manual & CGSecurity's TestDisk Step By Step - a few times. I used TD - yrs ago.
Have questions on order of steps, probably needed in partition recovery, fixing grub dual boot, (fix MBR on Windows?), & the few steps listed in TD guide, to "make Linux ext4 (dual) bootable."

Does the order of each part matter? Obviously it won't boot until partition table is "written, partitions are recovered." What about order of the other steps?

As for fixing dual boot, is Boot Repair Disk adequate or another, e.g. Super Grub2 Disk? TestDisk (TD) says it can "repair MBR" but don't know about this case.

I'll clone the HDD before making any changes.

Mint 20.1 installed on /sda HDD. DUAL BOOT - Grub 2.
Vista- installed on 2nd /sdb HDD; keep it only to run a few Win apps (no surfing).

The main Mint primary boot partition is first on /sda, then the extended LBA - with several Mint ext4 partitions in it.

There are 2 small NTFS storage partitions on the Linux /sda, AFTER the extended partition. TD also finds them.
Not sure if the non-boot NTFS partitions on same disk w/ Linux, creates any special recovery steps / issues?

Please let me know if I overlooked anything. Thanks.

I'm not sure how deleting apps from the /opt directory would render your Mint install unbootable. Did something else happen? I've only used TestDisk once so am not that familiar with it but I expect there is some reason for the steps being in the order they are.

If you have Vista on a separate drive from Mint then repairing booting for windows by installing windows code in the MBR of its drive and grub in the MBR of its drive should do the job. I don't know the capability of TestDisk in this.

One of those is likely the recovery partition for a windows install which was on that drive previously. Not sure how that would work if your vista install is now on another drive.

If boot repair you refer to is the software at the link below. it is designed to repair Linux boot problems. What it will do for windows is create a menuentry for windows but if any windows boot files are corrupted, they will not be repaired. If you use boot repair, I would suggest you choose the 2nd option described on the page using the ppa.

https://help.ubuntu.com/community/Boot-Repair

windows is on a different drive, if there are no windows created ntfs partitions on sda, you should be able to skip the section about recovery windows partitions boot sector. Is that what you are asking?

Obviously. "Severe back pain" wasn't an exaggeration. I don't know exactly what happened. At the time, I probably thought I knew what I was doing. After significant health events, it's not uncommon for people to have fuzzy memories.
I could guess, but since there's no "undo" button, it's no longer my focus. Normally, I don't push a button w/o a pretty good idea what it does. In my Zeppelin, "Dazed & Confused" state, in TD analyze / recover partitions, I'd guess I accidentally pressed "Write" (which re-writes partition table, based on partitions user has selected) when I meant to press Quit.

In my case, unless the ONLY thing that went wrong is the partition table (on /dev/sda) was removed / messed up, and that happening doesn't always mess up GRUB, it'll probably need repair. The Boot Repair Disk didn't appear to show the recommended changes before applying them (if so, not a big fan of that approach). They may be accessible before making them.

Some suggest just reinstalling GRUB2 (mine) or GRUB, to repair it, if damaged. Sound plausible.
If others have opinion on the easiest way to repair GRUB on a BIOS machine w/ messed up MBR partition table (read, works & doesn't waste more time), please share.

Good guess, but no. As said, they are
They were/ are (NTFS) backup (not of OS) & storage partitions from when Vista was used. Lots of family pics, vids, etc. Maybe some Windows files. It's possible the data could be moved. Since they're separate NTFS partitions, AFTER the extended partition - containing -only - logical ext4 partitions, AND past the extended partition, it might be possible to not select them during the 1st round of TD partition recover.

Since they're NTFS, on an otherwise ext4 HDD, will TestDisk have an issue restoring both file system types at the same time? Regardless of what the user guide may claim.

Since the HDD is mixed - ext4 & NTFS, will TD write an MBR / MSDOS type partition table (because of the NTFS partitions), regardless of TestDisk's Intel/pc designation?

Here https://en.wikipedia.org/wiki/Partition_type there are many origins of MBR (different IBM/pc compatible machines) than Intel. From what I can tell, "Intel/pc" is not a "Type" of partition table. It's one origin out of many, for an MBR Type Partition Table. Not an "Intel only" situation. It confuses lots of people.

Do you mean, "Windows OS created (or didn't) the NTFS partitions on /sda, vs. I created the 2 NTFS partitions, that may not need to recover the WINDOWS boot sector? Maybe - hopefully. But in dual boot, still need? to recover / repair anything to do with Linux booting, etc. Unless all that's damaged is partition tables on the Linux /sda.

I won't know if GRUB was messed up, until partitions - including boot, are recovered & machine is rebooted.
As to Boot Repair Disk (that's the one), their site says in part:

• Can recover access to Debian, Ubuntu, Mint, Fedora, OpenSuse, ArchLinux...
• Can recover access to any OS (Windows, MacOS, Linux..) if your PC contains Debian, Ubuntu, Mint, Fedora, OpenSuse, ArchLinux, or derivative.
• Can repair the boot when you have the "GRUB Recovery" error message

Says it "can" recover.... Can & will are not =. In my case, it didn't repair the boot for "GRUB Recovery" error, though it likely depends on what caused that error message.

Bootrepair is used for recovering a broken grub2 bootloader, not recovering partitions

Test disk will recreate the partition table found, but with out knowing what happened it is anybody guess. If the partitions are still in tack and haven't been written over, recreating the mbr partition table should allow for recovery of the partitions. Working on a clone of the drive would be the safest method using test disk.

Awful lot to plough through there - some suppositions are even correct.

Testdisk couldn't give a damn re NTFS vs ext? filesystems - it simply (?) looks for partition boundaries and suggests what it finds. Digging deeper usually turns up old previously deleted partitions (in my case anyway) - which doesn't help the situation. Only re-writing the partition table is typically non-destructive if nothing else is written to the disk. When I've had to use it I do nothing else to the disk (before or after) than recover the partitions then immediately run something like "lsblk -f" to see if the filesystems can be see as being at valid offsets into the (recovered) partition extents. Then fsck to see if they are at least consistent. Then mount them to see what the files look like, and maybe then a boot.
If you have to recover grub[2] that can be more or less the last thing - I usually do it from a chroot rather than supergrubdisk or similar. Although I have used that successfully too - many years ago.

As for MBR, that is a generic term, and testdisk will do the correct thing- all the MBR variants are historical and essentially irrelevant for Intel/AMD machines.

From experience, I once overwrote the beginning of my hardrive when attempting to put a iso onto a usb. I stopped the dd process when I realized what I did and the only damage was to the mbr partition table and the first partition on the drive, windows system partition. The windows recovery partition along with the linux partitions were not touched. I was able to recover all the partiitons except the windows system partition by using test disk to rewrite the partition table back to the mbr.

intle/pc is for msdos partition table.