Questions
Canister requires macOS 10.13 High Sierra or newer.
All generations from LTO-5 and up are supported. As Canister works with LTFS, LTO-4 and older are not supported.
Canister supports all LTO drives that are connected through SAS, which tends to be all standalone desktop units. Those tend to use either Thunderbolt, SAS through a PCI card like ATTO, or SAS into a device that translates it to Thunderbolt like a or Sonnet with an ATTO card.
Fibre Channel drives are also supported, although Canister doesn't detect which driver your FC device requires - you'll have to find that out yourself.
Tape libraries are supported as far as they have drives connected through SAS, but Canister will not offer control of the tape robot, as of now.
Yes - as of version 21.1, Canister is natively compatible with Apple silicon (e.g. M1 Macs). You can update Canister in-app, or download the latest release here. To upgrade a legacy Canister license (starting with
id) to please reach out.The mLogic LTFS Utility was a light version of Canister 20.1 that used to be included with every mLogic purchase. With the changes Big Sur brought along, the mLogic app has been replaced by a full-blown Canister that's included with every mTape purchase since Winter 2020 - whether purchased through us, mLogic, or a mLogic reseller.
The mTape app is no longer supported nor available for download. It does not work on Big Sur, whether it's Intel or Apple silicon. Also, the mTape app uses a legacy license provider, so we can no longer help with deactivations.
Every existing mTape licensee can reach out to us for a discount to crossgrade to Canister, courtesy of mLogic.
The short answer is "no, LTFS does not support file deletions". The only way to remove data from a tape is to erase it.
The long answer: it's possible to remove files from the index partition (by accessing a tape with Finder or Terminal and deleting files) but this will only make them vanish from the index; it will not clear the space used by the deleted files. As rolling back a tape will make the deleted files available again, it's not a security mechanism either, so don't bother.
No need to, Canister already does this for you. Canister reserves 5% of a tape's size for the index and to make sure there's room for data overflow.
It's the same thing.
LTFS only allows a name and serial to be set for a tape when formatting.
Canister uses LTFS. The difference between TAR and LTFS is that LTFS is a file system. That means your OS already has the tools included to work with LTFS, which in turn means no vendor lock-in for you. With TAR, you're always relying on a vendor's app to work and will be in trouble if that vendor happens to go out of business. With LTFS, that will not happen.
Yes, if the Windows software is capable of working with LTFS, that works. A Windows version of Canister is in active development.
Yes, since the release of 23.1 Canister supports Collections: any combination of files and folders can be dragged from Finder into the source dropzone, to be archived to tape.
You can safely skip verification by clicking the
[X] next to a transfer when the copy part finishes. Disabling verification altogether can be done in the Preferences:
First of all, deactivate Canister in-app or through the online License Manager so you free up your license to be used on the new computer.
You also might want to move your Catalogs, Manifests, and log files too. In Finder, navigate to
~/Library/Application Support/Canister. Select the Transfer Logs, Warning Logs, Manifests, and Catalogs folders, right-click and Compress. When a tape cannot be mounted, LTFS will report if a Repair is needed. If the Repair process locates data on the tape's data partition that is not referenced in the index partition, it's added as "lost and found" data. This is raw data, and does not tell you any file names, so for most purposes it's quite useless. Only if you know what should be on that tape, and what is missing, you would be able to crossreference file sizes and rename the files in that folder through Terminal's
mv command.Yes, that's fine to do. You can also add Thunderbolt adapters to it without issue. If your source is also a Thunderbolt storage device try to use a separate Thunderbolt bus for that, to ensure optimal bus usage.
Yes, as long as they originate from the same LTO drive vendor (IBM, Quantum, HP) and thus use the same LTFS driver.
For example, if you have multiple LTO drives from different manufacturers that support LTO-8, and since LTO-8 cartridges are all made by IBM, as long as you use the same cartridge, you can use all of your LTO drives when doing simultaneous backups.
No. This approach is inherently error-prone and can undermine the integrity of what’s written to tape.
Instead, use an intermediate SSD or NVMe to retrieve the contents of a tape, then archive those contents to the next tape.
Every LTO drive is essentially a computer, and as such follows its own instructions and error handling. Most drives have a single-character display (SCD) to tell you how it's doing. It's behind a black see-through panel so you won't see it except when booting (a countdown shows) or when an error is stated.
Anytime there is a number or letter visible on the front of your LTO drive, the software is not able to communicate with the drive. Refer to this list of SCD error codes to find out how to resolve the issue at hand:
As these are hardware errors, get in touch with your vendor to sort out the issue if needed.
Orange
J on the display? You are trying to load a too new tape into an older generation LTO drive.If your machine shows a
C on its display, all you have to do is insert the cleaning cartridge supplied by the manufacturer. The cleaning process will begin automatically, and once complete, the tape will eject by itself. After that, you're good to go.Some opsec teams get scared when they encounter macOSs new requirement of reducing security when installing kernel extensions.
The short version: there's no way around it, as LTFS requires FUSE and you'll also need to install a kext for your HBA.
The long version (for your opsec team): it's not a bad thing at all actually, and not about more or less security. As named by Apple, “Reduced security” is a bit misleading, as it does not accurately describe what this kind of change actually represents.
- Despite the unfortunate wording of “Reduced security,” kexts do not reduce a system’s security. If improperly developed, a kext could only affect system stability and reliability, but not the system’s security.
- A given kext cannot be installed into the operating system unless it is approved and signed by Apple. It is not possible to run arbitrary code in the form of kext.
- As noted, LTFS uses a kext called macFUSE, which has been battle-tested for over 15 years and proven to be exceptionally reliable.
- Enabling kernel extensions simply brings the system on par with any x86-based (i.e. Intel) Mac system. You've been living with "reduced security" for decades already.
- After changing the setting, and installing FUSE (and likely a kext for your HBA as well), the setting can be changed back.
Does your IT department refuse to install macFUSE? Do they insist it requires System Integrity Protection to be disabled on your Mac? Do they say kernel extensions (i.e. KEXTs) are legacy, and there should be a system extension to replace them? Send them this:
System Integrity Protection (SIP) does not block kernel extensions (KEXTs) from running. Also, SIP is not related to whether LTO is working or not and, thus, should never be disabled.With Big Sur, Apple introduced system extensions as a replacement for kernel extensions. At this stage, those aren't mature enough to replace KEXTs, especially for those used by pro storage devices. If that were so, developers would've ported their KEXTs to system extensions today. Until system extensions are on par with KEXTs, this will be the status quo for the foreseeable future.
Also, Apple did not completely kill off KEXTs. Instead, with Apple silicon, they introduced Security Policies. The default setting prevents even Apple-authorized KEXTs from being installed out of the box. When installing a trusted KEXT like macFUSE, a Mac's Security Policy must be changed to allow signed kernel extensions to load. Changing that Security Policy is also required for every RAID controller and HBA that lives inside storage.
Modifying a Mac's Security Policy is straightforward. It takes one minute, and we documented the process in detail here:
Last modified 1mo ago