Dump Era Metadata Safely with era_dump
You will finish with an XML dump of device-mapper era metadata, either on standard output or in a file, and a clear way to check whether the command really succeeded. The examples use era_dump 0.9.0 from the Ubuntu thin-provisioning-tools package version 0.9.0-2ubuntu5.1.
The route
Jump straight to the step you need, or tick off Done means at the end.
Allow about fifteen minutes for a straightforward export, longer if you need to identify the correct metadata volume. You need a shell, the thin-provisioning-tools package, and a metadata device or file that is not live. Reading a protected block device may require sudo, but the command itself does not normally need elevated privileges when the input is readable.
Safety boundary
Do not point this command at live era metadata. The installed manual explicitly says that live metadata cannot be processed. Stop the associated device-mapper workload cleanly and use the metadata device or offline copy supplied by your storage procedure.
1. Check the installed command
Start with read-only checks. This confirms the binary, package version and option syntax without opening a metadata device:
$ command -v era_dump
/usr/sbin/era_dump
$ dpkg-query -W -f='${Package} ${Version}\n' thin-provisioning-tools
thin-provisioning-tools 0.9.0-2ubuntu5.1
$ era_dump --version
0.9.0
$ era_dump --help
Usage: era_dump [options] {device|file}
Options:
{-h|--help}
{-o <xml file>}
{-V|--version}
{--repair}
{--logical}
The required positional argument is either a device or a file. The command writes XML to standard output unless you select another output file with -o.
Checkpoint
Confirm that the reported version matches the system you are documenting. The exact option set and diagnostics can vary between package releases.
2. Confirm the input is offline
Use the path from your storage inventory rather than guessing from a volume name. The manpage example uses /dev/vg/metadata, but that is only a placeholder for a real metadata device on the host:
$ METADATA='/dev/vg/metadata'
$ test -r "$METADATA" && printf 'readable: %s\n' "$METADATA"
readable: /dev/vg/metadata
The test command only checks that the current account can read the path. It does not establish that the metadata is offline or that it belongs to the expected pool. Check the device-mapper and thin-provisioning state using your normal maintenance procedure before running era_dump.
If the metadata is readable only by root, repeat the later command with sudo. Do not use sudo as a substitute for stopping the workload. Root access changes permissions, not the live or offline state of the metadata.
3. Write the XML to standard output
For a small inspection, dump the offline input directly. This is an ordinary command if the path is readable:
$ era_dump "$METADATA"
<era_metadata>
... XML emitted by the metadata dump ...
</era_metadata>
The element names and contents depend on the metadata. Do not treat the sample above as a promise about every release or metadata version. A successful command returns exit status 0; an error returns 1.
Capture the status immediately if the dump is part of a script:
$ era_dump "$METADATA" >/tmp/era-metadata.xml
$ status=$?
$ printf 'era_dump exit status: %s\n' "$status"
era_dump exit status: 0
$ test "$status" -eq 0
Keep the output path on a filesystem with enough free space. Standard output is useful for a pipe, but an unchecked pipeline can hide which command failed. Saving the status as shown gives the caller an unambiguous result.
4. Save the dump with era_dump
Use -o when you want the program to open the destination itself:
$ era_dump -o /tmp/era-metadata.xml "$METADATA"
$ printf 'exit status: %s\n' "$?"
exit status: 0
$ test -s /tmp/era-metadata.xml
$ head -n 5 /tmp/era-metadata.xml
Choose a destination you control and do not overwrite the only copy of an existing dump. The example uses /tmp for a temporary working file. Move or archive a verified result according to your retention policy, and remember that files in /tmp are not a durable backup.
When the dump will be consumed by another tool, XML standard output can be redirected instead:
$ era_dump "$METADATA" > era-metadata.xml
$ test -s era-metadata.xml
$ printf 'dump written: %s bytes\n' "$(wc -c < era-metadata.xml)"
Do not confuse a non-empty file with a valid or complete dump. The exit status is the first check. If the file is going to era_restore, validate it in a separate, controlled workflow before restoring anything.
5. Decide whether logical output is appropriate
The --logical option folds unprocessed write sets into the final era array. The installed manual says that this usually makes the XML simpler for further processing. It changes how the dump is represented, so use it when the next consumer expects the logical form:
$ era_dump --logical -o era-metadata-logical.xml "$METADATA"
$ printf 'exit status: %s\n' "$?"
exit status: 0
Keep an unmodified dump as well when you are investigating an incident or comparing metadata. That gives you a reference if a later processing step rejects the logical form. Do not add --logical merely to make a file smaller, and do not infer that it repairs damaged metadata.
6. Treat repair as a separate maintenance action
--repair asks era_dump to repair the metadata while dumping it. This is not a harmless display switch. Repair can affect the result you are collecting and may be inappropriate while another process can access the metadata.
Warning
Do not use --repair in a copy-and-paste diagnostic command. First take the approved backup or snapshot, confirm the metadata is offline, record the package version, and agree the repair with whoever owns the storage change. Preserve the original evidence where your incident or backup policy requires it.
If a repair is authorised, use an explicit output file and retain the exit status:
$ sudo era_dump --repair -o /var/tmp/era-repaired.xml /dev/vg/metadata
$ status=$?
$ printf 'repair dump exit status: %s\n' "$status"
repair dump exit status: 0
The sudo in this example is conditional. Use it only when the device or destination permissions demand it. A successful status does not replace your storage team's validation of the repaired metadata.
7. Diagnose the common failures
With no input path, the installed command returns status 1 and prints No input file provided. followed by its usage text. That means the positional argument is missing, not that the metadata is corrupt:
$ era_dump
No input file provided.
Usage: era_dump [options] {device|file}
...
$ printf 'exit status: %s\n' "$?"
exit status: 1
A bad path also returns a non-zero status. For example, on this installation era_dump /dev/null reports bad path and returns 1. Check the exact path, whether it is a metadata device or file, and whether the workload has really been stopped before retrying. Do not retry with --repair to make an input error disappear.
If the output file is absent or empty, inspect the destination directory and permissions, then rerun with a new destination. If the command reports an error after opening the input, preserve its diagnostic text and the original offline metadata for investigation.
Done means
- You confirmed the installed
era_dumpversion and option syntax. - You identified an offline era metadata device or file rather than a live target.
- You captured XML and checked exit status 0 and a non-empty result.
- You used
--logicalonly when the downstream consumer needs folded write sets. - You treated
--repairas an authorised maintenance operation with a recovery copy. - You kept temporary output separate from the durable archive or restore workflow.