Questions
Last updated
Last updated
Canister supports a wide range of LTO configurations from a variety of vendors. For most Macs, SAS-based units tend to be connected via a Thunderbolt, while PCs and Mac Pro's come with the option to install a PCIe HBA directly into the host system's motherboard.
LTO Drives: LTO-5 to LTO-9 by IBM, Quantum and HP.
Important: different drive vendors cannot be used at the same time.
HBAs: most ATTO and Areca models.
Highpoint RocketRaid controllers are not suitable for tape usage.
Thunderbolt/SAS LTO solutions by Symply, OWC, MagStor, mLogic and more.
Ethernet LTO solutions by Symply & MagStor (from Canister 24.1).
Milage may vary with Fibre Channel-based drives. Canister does not detect which driver your FC device requires - you'll have to find that out yourself.
Canister supports macOS 10.15 Catalina and newer. Both Intel and Apple silicon are supported.
While legacy downloads are available for older macOS versions, note that legacy means unsupported - if you run into issues, your best bet is to upgrade your OS. Also, your legacy OS might not work with the latest LTFS version - be sure to source a version that works with your OS from the LTO vendor.
You can use the latest Canister, available here.
All generations from LTO-5 and up are supported. As Canister works with LTFS, LTO-4 and older are not supported.
Yes - as of version 21.1, Canister is natively compatible with Apple silicon. You can update Canister in-app, or download the latest release here.
You have a legacy license key suitable for Canister 20.1 (download) and older. This version received support until Dec 31 2020, and does not support macOS 11 Big Sur or newer.
To upgrade a legacy Canister license 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 app was end-of-life'd and replaced with Canister.
The mTape app is no longer supported nor available for download. It does not work on Big Sur or newer macOS versions, nor on Windows. The mTape app uses a license provider that is no longer in business, so we can not help with deactivations.
Every existing mTape licensee can reach out for a crossgrade discount to Canister.
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 to ensure there's room for data overflow.
Yes, as of Canister for Mac 23.1 it's possible to rename tapes without formatting. Changing a tape's serial is not possible without a format.
It's the same thing. People tend to refer to formatting when a tape is new and erasing when a tape is used but needs to be wiped clean. The process itself is identical.
No, this takes several hours and is not required to reuse a tape. If required, a long wipe can be initiated using this Terminal command:
mkltfs -d 0 --long-wipe -f
By default, LTFS, and therefore Canister, will stop to sync the Tape Index every 5 mins. This provides a balance between safety and speed. If you prefer to sync only on unmount, this behavior can be manually overridden using the steps below.
Run the Terminal command below, then remount the tape:
defaults write nl.syncfactory.Canister.Mac OverrideMountCommandArguments "-o sync_type=unmount -f"
IBM have advised us that this is normal. Your drive's onboard computer works hard to ensure the read/write heads stay “on track”. Sometimes that means adjusting the tape tension to take up slack. Bottom line: as long as there are no error codes on the SCD, it’s situation normal. Until LTO drives landed on the Desktop, nobody noticed their foibles - now they do 🙂
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, and it's why Canister only supports LTFS.
Yes, and vice versa. If a tape was made with LTFS, it's fully useable on both macOS and Windows, with and without Canister.
Yes, since the release of 23.1 Canister supports Collections: any combination of files and folders (a Collection) can be dragged from Finder into the Source dropzone to be archived to tape. Canister 24.1 adds Pick & Mix, which allows you to update a Collection with more folders and files.
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.
Next, zip and move the Canister directory to your new system. This includes all Catalogs and Transfer Logs.
In Finder, navigate to ~/Library/Application Support/, zip the Canister directory and move it to your new system.
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.
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. There's no need or usefulness to loading your cleaning cartridge in any other case.
When Canister launches, it automatically checks for updates and retrieves an updated list of LTO- related dependencies from Hedge's file servers.
Some opsec teams get scared when they encounter macOS's 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:
Canister also reaches out to our license and crash handling providers, which are documented in the section.
