Hmm… No. A partition is what you install a filesystem on, but the partition itself is only a range of blocks that has been delineated as being a single unit — and thus a block device — in the partition table.
That would be the next step, if the OP’s “btrfs check --repair” fails. But if the machine itself is damaged by an EMP, then it’s an even bigger problem.
Since OP confirmed his Fedora is still booting from the same SSD.
The EMP damage can’t be this terrible or not?
I already thought that i know all this things about HDD/SSD/NVMe>Partitions and Filesystem… but maybe im still to unexperienced in this direction.
Specially i understand not enough about BTRFS.
Im better silence 
Yes, Fedora is booting from the SSD that my Manjaro is, so the SSD is working, the problem is with the btrfs filesystem.
And that’s also why I’m (relatively) quiet.
“sudo btrfs check --repair – init-extent-tree /dev/sdb1” is still running in Fedora, about 30 minutes and so…
Let’s make a coffee 
Lucky that @servimo did his homework and has created a backup.
Hopefully there is not much to regret, at the end of the day
A bad day, it’s raining again, lots of lightning and thunder, my fedora hang up. Maybe a btrfs check over another will Not produce a good result. I will have to wait till the rain, lightning and thunder stops.
Well, that’s a good sign, of course. But only the OP knows whether the circuit breaker tripped, or whether the power outage was caused by — for instance — a damaged junction box in the street.
In the latter case, it was just a power outage, but in the former case, an EMP is very likely, and it may take time for such damage to manifest itself. Commonly it’ll be in the form of instability under load or during prolonged use.
In and of itself, a partition is only a range of blocks on the drive, and the information regarding the different partitions is kept in a partition table at the start of the drive.
It is then up to the installer of the operating system to format that partition with a filesystem, which will install data structures on the partition. In the event of btrfs for instance, these data structures include so-called balanced trees, redundant partition superblock copies, separate zones for metadata, et al.
People often say “partition” when they really mean “filesystem”, and that’s why it gets confusing. 
Yes, indeed. This is why having backups on a separate drive is crucial.
If your repair succeeds, then perhaps you should run a memcheck on your system. If it was indeed an EMP that hit you, then your memory modules are going to be affected too, and then the memcheck should be a good indicator that there is more damage to the machine than meets the eye.
Remember, memcheck never reports false positives. It can only report false negatives. So if memcheck does find errors, then you do have damaged memory modules, and then indeed your SSD may also be damaged.
Thank you so much for that explanation 
Not just separated, but also external and unplugged… specially for this dangerous EMP/Lightning strike or electrical overcharge situations.
btrfs repair is still running after four hours.
Let it finish. The manual does say that it can take a long time. 
The btrfs repair ended with a non possible to do a totally repair, but when I reboot I could enter into Manjaro. And looks like everything is ok.
Let’s do a memtest and try to move grub to another partition/filesystem, not btrfs.
If the memtest turns out fine, then I would recommend reinstalling the system, thereby reformatting the partition, and then putting back your most recent backup.
I will try to do this, install a new Manjaro in a ext4 filesystem and then do the recover backup.
Be sure to update the UUIDs in /etc/fstab and elsewhere after restoring the backup, or you’ll run into boot problems.
I was thinking, maybe the problem that appeared with btrfs it was that I did a btrfs balance 3 days ago, and then today, before the appearance of the problem I did a “grub install /dev/sdb” and this is what caused the non functional btrfs filesystem. I was alerted before to not install grub in a btrfs filesystem.
*Somewhere in the commands I executed appeared the word “overlaping” and this makes me think about.
*I just move the boot (grub) to another partition/filesystem. I will stay with Manjaro as it is, will not reinstall it.
Installing that way direct on the partition is not recommended, the usual expected result is grub to break at some point, but with btrfs i can imagine it could break the file system too. Remember - btrfs is for advanced users only. Pretty much every known trick of procedure there is different.
First of all, you need to understand the mechanics behind grub. A lot here depends on whether you boot up in legacy BIOS mode or legacy BIOS emulation mode (CSM) on the one hand, versus native UEFI mode on the other hand.
In the first case, the boot.img component of grub is installed into the master boot record, immediately followed by the core.img component.
This works well on — and was designed for — a drive partitoned with an MS-DOS-style MBR partition table, but if the drive was partitioned as GPT, then there isn’t enough space between the master boot record and the first partition.
Therefore, booting grub in legacy BIOS mode on a drive with a GPT partition table requires that one would create an empty, unformatted partition of type bios_grub, of about 2 MiB in size, and marked with the boot flag. It doesn’t matter where the partition is created, as long as it’s on the same drive and that it’s of the correct type, with the boot flag set.
This partition will then be reserved for the core.img component of grub, and if you have not created this partition, core.img will be written over the starting boundary of the first partition, thereby damaging the filesystem on the first partition — this has nothing to do with btrfs, because it would do the same if your partition was formatted with ext4 or any other filesystem type.
On machines that boot in native UEFI mode, a different version of grub is used — one that runs in the 64-bit long mode of the boot processor, as opposed to the legacy BIOS version, which runs in 16-bit “real mode”. The idea here is that one does not install grub into the MBR — which is exactly what you did — but into a designated EFI system partition, formatted with a FAT32 filesystem and about 300 MiB in size.
As if that’s not complicated enough, when using btrfs with the default layout — whereby /boot is not a separate volume but rather just part of the root filesystem — you need to use a special version of grub, namely grub-btrfs. This is because btrfs uses compression and sparse files, and with /boot on the btrfs root filesystem, your kernel images and initcpios are on btrfs as well, which the regular grub cannot handle because it does not support sparse files.
The proper command for (re-) installing grub in a system with a GPT partition table and booting in native UEFI mode is simply… 
sudo grub-install
… when doing so from within the installed system itself, in which case the command will pick up all of the correct defaults from the already installed system. If on the other hand you’re going to be explicit about where to install it, then you need to give it the EFI system partition as the target, not the MBR — /dev/sdb is the drive itself, starting with the MBR.
So, indeed, by running “sudo grub-install /dev/sdb”, you have damaged your btrfs filesystem, and then of course, that damage cannot be repaired, even if only because your partition boundary is gone as well. The partition would need to be recreated and reformatted in order to fix that.
The post above already explains everything, i will just drop in some bibliography in case the OP needs additional reading (which is where the OP had to have started at the first place anyway):
GRUB/Restore the GRUB Bootloader - Manjaro
GRUB - ArchWiki
One last thing you could try — and which I recommend — is…
sudo btrfs check -s 1 /dev/sdb1
This will use the first copy of the superblock as the information source on where the partition boundaries are, given that you’ve overwritten the primary superblock.
I’m not enough of an expert on btrfs yet to guarantee that this will magically fix everything, but you’ve already got a booting system, so this should make it a little more robust (and thus usable) again.