Aaru and the case for a preservation suite that covers the whole lifecycle
Aaru Data Preservation Suite
At a glance
- What is it?
- Aaru is a .NET 10 suite for digital media preservation that reads and writes dozens of disk image formats, dumps physical media over ATA, SCSI, USB, FireWire and SDHCI, recognises dozens of filesystems, and adds an archival format of its own. Its scale is its argument, and its cost is that the project is a 6.0 beta with a custom licence.
- Who is it for?
- Aaru suits an archivist or hobbyist who has optical discs, floppies or old hard drives and needs a single tool that can read the image, identify the filesystem and extract the contents, because the breadth of format support is the reason to use it rather than a general-purpose imaging tool.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
One tool for the whole arc from dumping to storage
Aaru is named after the Egyptian paradise where the righteous dwell eternally, and it presents itself as an all-in-one solution for digital media preservation and archival.
The scope is a workflow rather than a feature list. The project says it is designed to assist you through the entire workflow of digital media preservation, from the initial creation of disk images, commonly called dumping, all the way through long-term archival storage. A single tool that images a disc, understands what is on it, extracts the contents and records the metadata along the way removes the seams where preservation workflows usually leak.
The system requirements are brief. Aaru is created using .NET 10 and can be compiled with all the major IDEs, and to run it you require to use one of the stable releases or build it yourself. The usage section is equally brief, listing the executable and then telling you to read help.
The implementation is C#, the default branch is devel, and the project carries a custom licence alongside separate LICENSE.LGPL and LICENSE.MIT files, which is worth understanding before you build on it rather than after. The user documentation is hosted at aaru.app.
The release history shows a 6.0 line in beta: v6.0.0-alpha.19 from 2026-03-11, v6.0.0-beta.1 from 2026-07-15 and v6.0.0-beta.2 from 2026-10-08, with the last push to the repository on 2026-10-18.
Dumping covers the media you actually own
The media dumping section is organised by the kind of physical media, and the list is the argument for the tool.
Aaru can dump magnetic disks, which means floppy disks and hard drives. It handles optical discs, CDs, DVDs and Blu-rays. It handles magneto-optical discs, flash devices such as USB drives and SSDs, memory cards in SD and CF formats, and tapes in various formats.
The interface list is what makes this practical rather than theoretical. It works with drives connected via ATA, ATAPI, SCSI, USB, FireWire and SDHCI. Six bus types covers essentially every device you might own, from a USB stick to a SCSI-attached optical drive from the 1990s.
The hardware flexibility note is the important framing. The project says you do not need specialized hardware, that Aaru will always try to extract the most accurate archival-quality image from your media using whatever drive you have available, and that all parameters are fully customizable with sensible and battle-tested defaults.
That is a deliberate design choice for preservation work. The expensive part of a preservation lab is the hardware, and a tool that insists on a specific drive model excludes everyone without one. The cost of the flexibility is that the quality of a dump depends on the drive you have, and the project does not pretend otherwise.
Reading images: thirty-five formats, and the ones that matter
The list of readable image formats is long enough to be a reference in itself, and it is split across several eras of dumping software.
The Apple formats are prominent: A2R Disk Image 2.x and 3.x, Apple Disk Archival/Retrieval Tool, Apple II nibble images, Apple DiskCopy 4.2 and the Universal Disk Image Format. The emulation-era formats include HxCStream, Disk eXPress, Dave Dunfield IMD, and the CopyQM and Sydex CopyQM+ self-extracting disk format.
The compression formats are the ones that matter most in practice, because they are what modern dumping tools produce. MAME Compressed Hunks of Data, Expert Witness Format, DiscJuggler images, UltraISO, and the Alcohol 120% style descriptors. There is also the Apple ][ interleaved image, the X68k DIM format, and a batch of others.
What is striking is the spread. A2R 2.x and 3.x, BlindWrite 4 and BlindWrite 5 and 6 TOC files, HxCStream, MagicISO, PowerISO, Quasi88, UltraISO, WUX. A preservation tool that reads BlindWrite 6 alongside QCOW2 is signalling that it is written for archives rather than for the current decade.
The writing side is different and is arguably more conservative. It covers A2R 3.x, the Apple formats including UDIF, any 512 bytes per sector raw image, the QEMU formats with QCOW, QCOW2 and QED, VirtualBox VDI, VMware VMDK and COWD, and the sector by sector copies with the awkward sector sizes, which are 128, 256, 319 and 1024 bytes per sector.
The write list includes Aaru's own format, and the reason is in the design
Among the writable formats is Aaru Format, the project's own archival format, and the guide explains what it stores.
It stores all the data from your media, comprehensive metadata, and full audit information. That third item is what separates an archival format from an image format, and it is the point of the whole project.
An image format answers what the bits were. An archival format answers what the bits were, what was known about them at the time, and what was done to them. The audit information is what lets a future reader check that a dump was done properly and see which parameters produced it, which is exactly the record that a preservation workflow is supposed to produce and that a bare sector copy throws away.
The write list is otherwise respectable and practical. Aaru Format, the A2R 3.x format, DiskDupe, CopyTape, CisCopy, IBM SaveDskF, CDRDAO and CDRWin cue and bin sheets, and the various Apple interleaved and DiskCopy variants. It can also write a raw sector by sector copy, which is the archival baseline that any other format can be derived from.
Alongside that there is a separate feature for metadata sidecars in an open JSON format, described as containing all extractable information from any supported image format and intended for integration with external systems and third-party software. So the tool can speak the archival format for long-term storage and the open format for the tooling you use now.
Filesystems, partitions and archives are where the breadth really shows
The filesystem and partition support is the part that tells you this is a preservation tool rather than a disc ripper.
For partitions, the list covers MBR and GPT and EFI GUID Partition Table, the Amiga Rigid Disk Block, the Apple Partition Map, the Atari AHDI and ICDPro schemes, the Sony PlayStation 2 APA scheme, BSD disklabels, DEC disklabels, the DragonFly BSD 64-bit disklabel, the NeXT disklabel, the Plan 9 partition table, Rio Karma, the SGI volume header, the Sun disklabel, the UNIX VTOC and disklabel, and the XENIX partition table, plus the various slices and subpartitions that live inside an MBR.
That list reads like the partition table zoo of the 1980s and 1990s, which is exactly the population that needs a preservation tool. A modern operating system will not mount half of these, so the only way to get the data out is a tool that understands the layout itself.
The filesystem section is described as recognising dozens of filesystems and displaying detailed information about them, and for many of them extracting the complete contents, including all files, extended attributes and alternate data streams. The listed fully supported filesystems begin with the 3DO Opera file system, the Acer File System, the Acorn Advanced Disc Filing System and the Alexander Osipov DOS used by the Electronika BK-0011.
The archive support follows the same logic. ACE, AR, ARC, ARJ, ARJZ, Compact Pro, CPIO, DiskDoubler, Expert Witness Format, LARC, LHA, RAR, StuffIt and StuffIt X, TAR, the Xbox 360 Secure Transacted File System, ZIP and ZOO, and the Symbian Installation File. A preservation workflow that has to open what it just dumped needs the archive layer too.
The project structure tells you the scale of the thing
The repository tree is the clearest statement of how large this project is, and the naming is consistent enough to read as an architecture.
There are separate assemblies for the parts, each prefixed Aaru. Aaru.Core is the core, Aaru.Images handles image formats, Aaru.Filesystems handles filesystems, Aaru.Partitions handles partition schemes, Aaru.Devices handles the physical drives, Aaru.Decoders and Aaru.Decryption handle sector-level decoding and any decryption, Aaru.Archives handles archives, Aaru.Checksums handles verification, Aaru.Filters, Aaru.Generators, Aaru.Compression, Aaru.Database, Aaru.EntityFramework, Aaru.Dto for data transfer objects, Aaru.Helpers, Aaru.Localization, Aaru.Logging, Aaru.Settings, Aaru.CommonTypes, and Aaru.Generators.
The two interfaces are separate assemblies too, Aaru.Gui for the graphical interface and Aaru.Tui for a terminal one, with Aaru.Tests and Aaru.Tests.Devices beside them.
The build files are equally systematic. There is a solution file in two forms, Aaru.slnx and the DotSettings file, a Directory.Build.props, Directory.Build.targets, Directory.Packages.props for central package versions, a global.json pinning the SDK, and a pkg/ directory for packaging. There is also a build.sh, a codealike.json, and a release-checklist.md, and a Changelog.md.
The supporting files at the root are the part worth reading. AGENTS.md and GOVERNANCE.md and MAINTAINERS.md, a CONTRIBUTING.md, and a NEEDED.md alongside a Needed.fods file, which is a spreadsheet of media formats that are still needed, and a data/ directory for the format definitions. That NEEDED file is a good sign, because it means the maintainers track the gap between what is supported and what exists in the wild rather than leaving users to file issues one format at a time.
Where Aaru is the wrong choice
The first case is a person with a single optical disc and a modern operating system. Mounting an ISO or using a mainstream extractor takes minutes, and Aaru is a large suite with a large surface to learn.
The second is a project that needs a supported release. This is 6.0.0 beta 2, the development branch is devel rather than a release branch, and the licence situation is not clean. The repository carries a custom licence that GitHub cannot classify, next to separate LICENSE.LGPL and LICENSE.MIT files, and the copyright line reads Natalia Portillo. That combination is common in projects that want to impose additional terms on a tool built on licensed components, and it is a question for your own legal review rather than something to assume.
The third is a workflow that only needs checksums. Aaru has a whole Aaru.Checksums assembly and the ability to compare two dumps to verify integrity or find differences, but if verification is your only requirement, a checksum utility against a hash manifest is the smaller tool.
The fourth is an environment where you cannot install .NET 10. The project states the runtime requirement plainly, and while a self-contained build is possible, it is a build step rather than a download.
None of this makes the suite wrong. It is a large answer to a large problem, and the sizes are proportionate.
Editorial conclusion
Aaru suits an archivist or hobbyist who has optical discs, floppies or old hard drives and needs a single tool that can read the image, identify the filesystem and extract the contents, because the breadth of format support is the reason to use it rather than a general-purpose imaging tool. It does not suit a team that needs a stable supported release, since the current build is 6.0.0 beta 2, and it does not suit a project that needs to rely on a clear open source licence, because the repository carries a custom licence alongside LGPL and MIT files. Before you adopt it, check which of the format lists actually cover your media, and note that the last push was on 2026-10-18 with v6.0.0-beta.2 published on 2026-10-08.
Frequently asked questions
What is Aaru?
Aaru is a data preservation suite for digital media, created with .NET 10. It covers the whole workflow from creating disk images, commonly called dumping, through to long-term archival storage, with a graphical interface as well as a terminal one.
Which physical drives can Aaru dump?
Magnetic disks such as floppies and hard drives, optical discs including CDs, DVDs and Blu-rays, magneto-optical discs, flash devices and SSDs, memory cards in SD and CF formats, and tapes. It works over ATA, ATAPI, SCSI, USB, FireWire and SDHCI interfaces, and the project says you do not need specialised hardware.
What is AaruFormat and why does it exist?
It is the project's own archival format, and it stores all the data from the media, comprehensive metadata and full audit information. The audit record is the difference from an ordinary image format, because it documents the parameters and the conditions of the dump rather than only the bits.
Can Aaru identify and extract filesystems?
Yes. It recognises dozens of filesystems and displays detailed information about them, and for many of them it extracts the complete contents, including all files, extended attributes and alternate data streams. The partition layer covers MBR, GPT, Amiga RDB, Apple Partition Map, Sun disklabel, XENIX and many more, with slices and subpartitions inside an MBR.
What is the current release status of Aaru?
The current build is 6.0.0 beta 2, published on 2026-10-08, following 6.0.0 beta 1 in July 2026 and 6.0.0 alpha 19 in March. The last push to the repository was on 2026-10-18, the default branch is devel, and the project carries a custom licence alongside separate LGPL and MIT licence files.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/aaru-dps-aaru)Was this useful?