Creating a Backup Restore Utility for X68000 Hard Disk Partitions

The Sharp X68000 is remarkably durable, but its hard disks are among the least predictable parts of an aging system. SCSI drives develop bad sectors, compact flash replacements can fail without warning, and a corrupted partition table may make an otherwise healthy disk appear empty. A dependable backup is therefore more useful than a collection of copied files.

A practical restore utility for X68000 hard disk partitions should preserve the information that Human68k needs to boot, locate partitions, and read directory structures. It should also be simple enough to run from a floppy disk, a SCSI-attached emergency disk, or a modern host computer while connected to an imaging device.

The goal is not merely to duplicate files. It is to capture a recoverable representation of the disk, verify that representation, and restore it without silently changing sector order, partition boundaries, boot code, or filesystem metadata.

Define The Backup Target

The first design decision is the level at which the utility operates. A file-level backup copies directories and documents but may omit hidden system files, boot sectors, allocation information, timestamps, or special attributes used by Human68k software. It is convenient for everyday documents, but it is not sufficient for a complete system recovery.

A partition image records every sector in a selected partition, including unused areas. This approach preserves the filesystem exactly and makes restoration straightforward. A full-device image goes one step further by recording the entire SCSI or SASI target, including partition tables, boot areas, gaps between partitions, and any device-specific information outside the normal filesystem.

For most X68000 users, supporting both modes is worthwhile. The partition mode produces smaller archives and allows a single partition to be restored without disturbing others. The device mode is the safer option before replacing a drive, changing an emulator configuration, or experimenting with a modified partition layout.

The utility should also record descriptive metadata beside the image. Useful fields include the source device identifier, logical block size, total sector count, partition start and end sectors, Human68k version, date of capture, and checksum algorithm. These details prevent a valid image from being restored to an incompatible target by mistake.

Understand X68000 Storage

Classic X68000 systems may use SASI or SCSI storage, while later configurations commonly connect hard disks, magneto-optical devices, CompactFlash adapters, or SCSI2SD-style replacements. The operating system may see these devices through a low-level driver, but the utility must still account for differences in device capacity, sector numbering, and command support.

A restore program should never assume that every device behaves like a modern block disk. Some older units report capacity imperfectly, reject large transfer sizes, or become unreliable during long sequential operations. Reading and writing in moderate chunks, checking the returned byte count, and retrying failed operations are more robust than issuing one enormous request.

Partition boundaries deserve special attention. A partition image must begin at the exact logical block selected by the partition map and continue for the exact number of sectors assigned to it. Starting one sector early can overwrite partition metadata; ending one sector late can damage a neighboring volume. The program should display these boundaries before backup and require an explicit confirmation before restoration.

Device identity should be checked as well. SCSI ID, model string, reported capacity, and, where available, a serial number can be recorded in the image header. These checks do not eliminate every risk, but they make it harder to write a system image to the wrong target after booting an emergency environment.

Choose An Image Format

A useful image format should be transparent, streamable, and resistant to interruption. A simple binary layout can begin with a fixed signature, format version, header length, sector size, source capacity, partition information, compression mode, and checksums. The header should be followed by a sequence of data blocks rather than one opaque compressed stream.

Block-based storage has several advantages. The utility can display progress, verify each block as it is written, resume an interrupted backup, and skip blocks that have already been confirmed. A block size between 64 KiB and 1 MiB is generally practical, although the best value depends on memory, transfer reliability, and the target device.

Checksums should be calculated for the original uncompressed data. A fast CRC can detect common transfer errors, while a cryptographic digest such as SHA-256 provides stronger identity checking when images are moved between disks, computers, or archives. The header can contain a whole-image digest, but per-block checksums are especially useful when repairing or resuming a large backup.

Compression is optional rather than fundamental. Empty sectors and old software disks often compress well, but compression makes random access and partial recovery more complicated. A good first version should support an uncompressed, sector-accurate format and add compression only after backup, verification, and restoration are reliable.

Plan Safe Backup And Restore Operations

Backup should be read-only from the target’s perspective. Before opening the device, the utility can inspect its geometry and partition data, then present a summary for review. During imaging, it should avoid modifying access timestamps or attempting filesystem repairs. If a read fails, the program should record the sector range and error rather than substituting zeros without notice.

A damaged disk requires a controlled policy. Retrying a failed block several times may recover a marginal sector, but repeated aggressive reads can make a failing drive less stable. The image format should mark unreadable ranges explicitly, allowing the operator to decide whether to continue, replace the source, or restore only the healthy portions to a new disk.

Restoration must be more defensive than backup. The utility should verify that the destination is writable, large enough, and not the source device. It should show the destination identifier and expected overwrite range immediately before writing. A deliberate confirmation sequence, such as entering the target ID or image name, is preferable to a simple yes-or-no prompt.

A dry-run mode is valuable for testing. It can parse an image, compare its partition map with the destination, calculate the required space, and report whether the device supports the intended transfer size without writing anything. After restoration, the program should reread selected blocks, verify checksums, and optionally perform a complete pass over the restored image.

Backup method	Preserves boot and partition metadata	Handles individual file recovery	Best use	Main limitation
File copy under Human68k	Usually no	Yes	Documents and frequently changing files	May omit system attributes and boot data
Partition image	Yes, within the partition	Indirectly	Rebuilding one Human68k volume	Requires exact partition sizing
Full-device image	Yes, across the target	Indirectly	Complete migration or disaster recovery	Larger image and greater overwrite risk
Host-side sector dump	Yes, if the interface is correct	Indirectly	Archiving and offline analysis	Needs compatible hardware or adapter
Compressed block image	Yes, when implemented correctly	Indirectly	Saving storage space	More complex resume and random access

Build A Human68k-Friendly Workflow

A native Human68k version should be small, conservative, and usable from an emergency boot disk. The interface does not need elaborate graphics. A text menu with device selection, partition inspection, image creation, verification, and restoration is easier to maintain and more likely to work on systems with limited memory.

The program should avoid relying on the very disk it is trying to repair. A floppy-based startup environment is historically appropriate, but a floppy drive with a worn eject mechanism or damaged media can become another failure point; practical maintenance notes such as this floppy drive mechanism are part of the same preservation mindset. A bootable SCSI device or ROM-assisted environment can provide a useful alternative.

File naming also matters. Human68k users may move images through systems with different character encoding and filename restrictions, so metadata should use conservative names and plain text where possible. A companion manifest can document the original Japanese volume label, software version, and notes without making the binary image dependent on a particular display environment.

The utility should expose logs in a format that can be copied to another machine. A backup log might list each block, its checksum, retry count, and final status. For a successful image, a short summary is enough; for a failing drive, the error map becomes valuable evidence when deciding whether to attempt a second pass or replace the hardware.

Support Host-Based Recovery

A host-side companion expands the usefulness of the native program. A modern computer can store multiple disk images, calculate strong hashes quickly, inspect headers, split large files, and write an image through a compatible SCSI bridge or removable-media workflow. It can also provide a safer environment for analyzing a damaged image without repeatedly powering an aging X68000.

The host tool should understand the same format rather than inventing a separate archive. It can validate headers, list partitions, extract files when the Human68k filesystem parser is available, and convert between raw images and the structured block format. Keeping the raw sector data accessible is important because proprietary conversion layers can become unusable in the future.

Restoration through a host should include geometry warnings. A destination that is technically larger may still have a different usable layout, while a device with the same nominal capacity may expose fewer sectors. The program should distinguish between restoring a complete device image and restoring a partition image into a pre-created destination partition.

Emulator support is another useful path. An image can be mounted in an X68000 emulator for testing before it is committed to physical media. This makes it possible to verify that Human68k boots, applications launch, and directory names remain intact. Emulator success does not prove that a physical SCSI target will work, but it can catch image corruption before hardware is placed at risk.

Test Recovery Before Disaster

A backup is unproven until it has been restored somewhere. Testing can begin with image validation and a virtual machine or emulator, then proceed to a spare disk or removable storage device. The original source should remain untouched during the first restoration attempt, allowing comparison if the result is incomplete.

Test both ordinary and unusual content. Check files with Japanese names, deeply nested directories, executable programs, system utilities, zero-length files, large files, and files carrying special Human68k attributes. Compare directory listings and checksums where possible, but also launch representative software because a file-level comparison may not reveal a boot-sector or allocation-table problem.

Power interruption testing is useful for the utility itself. Interrupt a backup after several blocks and confirm that the image is clearly marked incomplete. Interrupt a restore on a disposable target and verify that the program refuses to describe the result as valid. Resume behavior should be explicit: either the tool continues from verified blocks or it starts a clean operation.

Document the recovery procedure in plain language. It should state which boot disk to use, how to identify the source and destination, where image files are stored, how to validate checksums, and how to respond to unreadable sectors. In a retrocomputing project, documentation is part of the backup because future operators may not remember the assumptions behind the code.

Recommended Implementation Practices

A first release should prioritize predictable behavior over a long feature list. The following practices keep the utility useful on original hardware while leaving room for later enhancements:

• Use fixed-width integer fields and an explicit byte order in the image header.
• Separate device discovery, sector transfer, image parsing, checksum validation, and user-interface code.
• Refuse restoration when the destination is smaller than the image’s required sector range.
• Record unreadable blocks instead of silently filling them with zeros.
• Provide raw-image export so the archive remains usable without the original utility.
• Include a versioned format specification and small test images with known checksums.

Error handling should be designed around recovery rather than concealment. Every failed command needs a visible status, and a retry should never erase the original error from the log. If the SCSI layer reports a sense code or equivalent diagnostic, preserve it in the log so hardware faults can be distinguished from filesystem problems.

The project can begin with a command-line utility and a minimal native frontend. Once the format has survived real backup and restore tests, features such as incremental snapshots, compression, file extraction, and graphical status displays can be added without changing the fundamental archive model.

A dependable backup restore utility gives the X68000 more than a safety net for one hard disk. It creates a reproducible record of software environments, custom configurations, and the physical arrangement that makes older systems distinctive. Publish the format, source code, test images, and recovery notes so other enthusiasts can validate the tool on their own machines and help preserve the platform’s working history.