Lets say I have access to almost any platform/peripheral and a bluescsi v2. SCSI ones are the challenge really. What would be the optimal setup to have the best success? I was thinking an early or mid PPC tower. But I do have an old world g3 as well, scsi cards, and drive enclosures. How would you do it? Any software preference?
I have a couple hundred drives I need to archive. SCSI and IDE. What would be your ideal setup to accomplish this?
- Thread starter shu82
- Start date
For the SCSI drives you can use the BlueSCSI v2 in Initiator Mode. It'll copy the disks once you connect the drive to it without the need of a Mac.
That was my first thought to do. But, I was wondering if a direct install into a working old world tower would still be the preferred method. Then I also have a sata card with an ssd. I was wondering if going that far would cause complications vs staying on the scsi chain.
@shu82 and @chrisrueckert, FYI, initiator mode was originally implemented for ZuluSCSI, which is where BlueSCSI got said initiator mode support from.
See the second line of https://github.com/BlueSCSI/BlueSCSI-v2/blob/main/src/BlueSCSI_initiator.cpp#L2C3-L2C65, where it clearly states:
Code:
This file is originally part of ZuluSCSI adopted for BlueSCSIThe SCSI initiator mode code exists because Rabbit Hole Computing developed and tested it, and was a basic feature of ZuluSCSI RP2040 when it was announced in March of 2023. The BlueSCSI team then added hardware support to a later hardware revision of BlueSCSI V2, which was released in ~September of 2023, five months after we chose to make it publicly available under an open source license.
ZuluSCSI Blaster (Ultra SCSI), ZuluSCSI Wide, and ZuluSCSI RP2040 Compact all support initiator mode, and have from day one.
It's also worth noting that the BlueSCSI V2 firmware was shamelessly forked form ZuluSCSI firmware, and began life as a wholesale search-and-replace. It does not represent an original work at the time of the fork. Other than BlueSCSI Toolbox, which was ported over from BlueSCSI V1, the initial firmware development of BlueSCSI V2 was done by Rabbit Hole Computing. Their primary contribution was to design a work-alike Pico-based board, instead of using an integrated/laid-down RP2040 microcontroller.
Rabbit Hole Computing then released ZuluSCSI Pico OSHW in October of 2023 under a "true" open-source license, the CERN Open Hardware License, which did not restrict commercial use/sale.
Eleven months later, on or around September 9th, 2024, the BlueSCSI team announced they were re-releasing their hardware designs under the exact same CERN OHL-S license, instead of the previously used Creative Commons Non-commercial license. This is a clear pattern of behavior, which continues with the recent release of BlueSCSI Ultra/Ultra Wide, which is similarly derived from firmware written by Rabbit Hole Computing, for ZuluSCSI.
It's pretty clear who is paying for and doing the actual hard work.
So Shu82 had two options. Great!
Yeah, but their clone is cheaper and in stock more often for US buyers.
The market follows the best value item
The least expensive ZuluSCSI, ZuluSCSI Compact RP2040, supports initiator mode and is $45, available from us directly in the US, and we have plenty in stock.
No, it's not "in stock more often for US buyers" but you can keep believing whatever you want to believe.
My bad, I think I'd actually taken a look at one of the foreign ZuluSCSI resellers and made some assumptions...
Not that I agree with the BlueSCSI people
If I had to image a lot of hard disks I'd setup an old PC with a pci motherboard and an Adaptec SCSI cards and collect a few extra adaptec SCSI cards just in case one of them dies.
You can copy practically anything under Linux using dd and dd-rescue.
Then when you have the drive images you can work about whats actually on them at a later date.
It's probably worth imaging each drive twice, compare the images and make sure they are identical. Any that give different checksums after each read should be set aside for more advanced data recovery.
Once you have this set up, you can just let it run while you do other stuff and feed it a new drive every time it finishes the last one.
With a couple hundred drives to archive, surely there are many of those drives with several duplicate files. Also, there's probably no point to archive system folders and programs that require installers. How many copies of Simple Text do you want archived?
What is needed is a massive drive with a single folder for the items to be placed initially. As the items of each of the drives to be archived are added to the single folder, simply don't allow the copy of duplicates. There are disk cataloguing applications to assist that prevent the copy of duplicate items or write an Apple Script.
What is needed is a massive drive with a single folder for the items to be placed initially. As the items of each of the drives to be archived are added to the single folder, simply don't allow the copy of duplicates. There are disk cataloguing applications to assist that prevent the copy of duplicate items or write an Apple Script.
Last edited:
I’d no doubt use what I have, with would be either a beige G3 (native IDE and SCSI), or an early G4 with a PCI SCSI card. Long cabling would allow a reasonably workmanlike setup.
Similar threads
