rt-importer(8)

πŸ’– NAME πŸ’–

okay so bestie, meet rt-importer β€” it imports a serialized RT database right on top of the current one. yep, on top. we're stacking. 🫢


✨ SYNOPSIS ✨

rt-importer path/to/export/directory

so basically you point it at a directory, and it goes to work πŸ’…


🌸 DESCRIPTION 🌸

This script is the bestie that unpacks the contents of a dump that rt-serializer made earlier. It creates all of the objects from that dump in the current database, and that can include users, queues, and tickets. so, like, the whole personality of your old RT shows up in the new one. πŸ¦‹

good news: you can stop the import process with Ctrl+C (^C) if you need to, and then pick it back up later just by re-running the importer. it remembers. it's chill. 😌

Certain records (notably queues and groups πŸŽ€) will have their original Organization name prepended to them on import. Why? mainly to dodge duplicate names β€” like, if you import a General queue into an RT that already has a General queue, without this you'd get a name collision error and everything would be so embarrassing. πŸ™ˆ

so if you're confident you won't have any name collisions in queues or groups, you can suppress this whole behavior by passing the --exclude-organization flag to rt-importer. your call, bestie. ✨


πŸ‘‘ OPTIONS πŸ‘‘

  • --list β€” prints a summary of all the data hanging out inside the dump. little peek inside the box πŸ“¦
  • --quiet β€” suppresses the progress bars during an import. this option is implied when the output isn't going directly to a terminal (so non-interactive runs just get quiet mode for free, no cap).
  • --originalid cfname β€” drops the original ticket organization and ID into a global custom field with the name you give it. and if there's no global ticket custom field with that name in the current database, it will create one for you. so generous of it πŸ₯Ή
  • --exclude-organization β€” ordinarily certain records (groups, queues, and the --originalid custom field) include the organization name of the original RT instance. use this option to suppress that behavior and just use the original name directly. periodt.
  • --ask β€” prompts you for what to do when an error happens while inserting a record into the database. this can often happen when you're importing data from very old RTs where some attachments (usually spam πŸ’€) contain invalid UTF-8.

the importer will pause and ask if you want to ignore the error and continue on, or abort (potentially so you can restart later).

⚠️ ignoring errors will result in missing records in the database, which may cause database integrity problems later. if you ignored any errors, you should run rt-validator after import. seriously, bestie, run it.
  • --ignore-errors β€” ignore all record creation errors and just keep going while importing. this is literally equivalent to running with --ask and manually typing ignore at every single prompt 😭. you should always run rt-validator after importing with errors ignored.
πŸ’€ this option can be dangerous and leave you with a broken RT! like, actually broken. not the cute kind of broken.
  • --dump class[,class] β€” prints Data::Dumper representations of the objects of type class in the serialized data. mostly useful for debugging, iykyk 🧚

works only in conjunction with --list. πŸ‘ˆ (that's the whole vibe, it doesn't do anything alone)

  • --no-auto-commit β€” don't auto commit to the database. when this flag is used, it will commit only once for each data file. this could boost performance in some cases πŸ”₯
  • --batch-user-principals NUMBER β€” the number of user principals to create in batch beforehand. default is 0. this is to improve performance for not-cloned serialized data of big instances, and usually you don't need to specify this. like, genuinely, usually don't.
  • --batch-group-principals NUMBER β€” same deal, but for group principals. the number of group principals to create in batch beforehand. default is 0. again, for performance on not-cloned serialized data of big instances, and usually you don't need to specify this either. πŸŽ€
  • --batch-size BATCH_SIZE β€” create objects in batch. default is 0, which means batch processing is not enabled. this is for data serialized with --clone or --all. for cloned serialized data, each batch processing will also take place in a separate child process. πŸ‘Ά
  • --max-processes MAX_PROCESSES β€” the number of max allowed child processes for batch processing. default is 10. this is for cloned serialized data only. πŸƒβ€β™€οΈπŸƒβ€β™€οΈπŸƒβ€β™€οΈ

🌈 CLONED DATA 🌈

Some dumps may have been taken as complete clones of the RT system. heads up bestie: those are only suitable for inserting into a schema that has no data in it. empty. nada. πŸ•³οΈ

You can set up the required database state for the receiving RT instance by running:

/usr/sbin/rt-setup-database --action create,schema,acl --prompt-for-dba-password

and like, the normal make initdb step will not work, because it also inserts core system data. so don't do that one. it's giving wrong move. πŸ’…


and that's the whole thing, you ate it πŸ’…βœ¨ this page came to you courtesy of perl v5.40.1, dated 2026-06-21 β€” rt-importer(8), signing off, mwah πŸ«ΆπŸŽ€

πŸ“¦ where this page comes from