Whether or not the data is "safe" after a power loss can greatly depends on what filesystem you use. Generally speaking, most filesystems will not go corrupt from power loss alone assuming the drive is working properly, has no firmware bugs and doesn't die as a result of the crash (ie if you have a power surge or something).
If you use ext2, fat32 or exfat, you can potentially lose all or part of the filesystem in certain cases, and some files that were being modified in certain circumstances can disappear and only fsck can potentially recover them in lost+found after a power loss. These filesystems overwrite their metadata in place and employ no methods to provide resilience on power loss on their own. While you should always unmount filesystems in all cases, it's especially important to properly unmount these ones before removing the drives.
If it's ext3/ext4, it journals filesystem metadata by default, so the filesystem is safe after a power loss, however you need to run fsck to replay the journal to keep it consistent after power loss. (Ubuntu will do this on boot automatically for your root drive). Data writes are not consistent unless you use the optional data journaling with the mount option data=journal on ext4, which is not on by default as it causes 2x write amplification since it writes all changes twice. You can still end up with files that contain 0s in the data ranges themselves if were not fully flushed to the disk before the failure.
XFS and NTFS also journal. They do not offer data journaling, their expectation is that should be handled by the application if needed. They always journal their metadata structures. NTFS-3G also doesn't fully utilize the NTFS journal last I knew, however, the built in ntfs3 driver of the linux kernel does. You do not need to run fsck in any case with these filesystems to replay the journal after a power failure, they do it at mount time (even if you mount ro so keep that in mind if you're doing recovery on a drive!!). Do not ever use ntfsfix if you care about NTFS integrity, as it wipes the journal without replaying it.
Btrfs and ZFS perform copy on write for both data and metadata and are always consistent, if a crash happens before a commit, it's as if the change never happened. Btrfs does however cache writes to data ranges longer than the commit interval by default (for performance reasons), so like ext4, you can still end up with files that contain 0s after a crash in some cases. It will often present CSUM errors if this happens, this isn't necessarily an indication of disk failure. You can avoid this with the mount option flushoncommit, which orders data writes first, but comes at at a performance cost (it doesn't result in write amplification though like with ext4 data journaling). NOCOW files are never consistent to power failures, especially in the case of RAID (which presents it's own separate set of risks).
None of the methods employed by any of these filesystems work if the disk itself does not respect write barriers or lies to the filesystem in any way (or more rarely but still possible, if there's some sort of filesystem driver bug). If you've got a flaky drive or controller, which can be common with USB attached drives in my experience, you're rolling a dice with your data in the event of a power loss.
And as always, if the data is of utmost importance, ensure you keep regular backups, never rely on a single drive or even RAID redundancy alone to protect you in all cases.