Re: [arch-general] archlinux ext4 recovery file versioning
>On 04/17/2017 11:12 PM, Maykel Franco via arch-general wrote: >> El 17 abr. 2017 10:09 p. m., "Alex Theotokatos via arch-general" < >> arch-general@archlinux.org> escribió: >> >> On 04/17/2017 09:31 PM, Maykel Franco via arch-general wrote: >> >>> Hi, I have a server in archlinux with samba. I have windows client in >>> my house with mapped folder but a Trojan has entered and encrypted >>> all files included server archlinux... >>> >>> Archlinux has formated with ext4. >>> >>> Would it be possible to recover unencrypted files? >>> >> Maybe testdisk with photorec might help. Good luck... >> >> >> >> With testisk os posible recovery original files without encrypt? >It will not unlock the encrypted files, but photorec will swap all the disk >and can recover some files that 'theoretically' was deleted or tmp files. >Maybe, during encryption the files moved on some parental folder and then >deleted. i think photorec might help here. >You can start with testdisk and see what is deleted and not. You can try this site https://www.nomoreransom.org/ It might help you decrypt the files. File recovery most likely won't help. (Unless you can 'recover' from a cloud based backup!)
Re: [arch-general] btrfs raid 10 fileserver with ata errors
> -Original Message-
> From: arch-general [mailto:arch-general-boun...@archlinux.org] On Behalf
> Of niya levi via arch-general
> Sent: Thursday, January 12, 2017 9:22 PM
> To: arch-general@archlinux.org
> Cc: niya levi
> Subject: [arch-general] btrfs raid 10 fileserver with ata errors
>
> hi everyone
> i have a fileserver with 6 1tb disks
> i get the following errors repeated constantly
>
> --
>
> ata17.00 exception Emask 0x0 Sact 0x0 SErr 0x0 action 0x6 frozen
> failed command: READ DMA
> cmd c8/00:30: tag 14 dma 65536 in
> res 40/00:ff:00 Emask 0x4 (timeout)
> status {DRDY}
>
> --
>
>
> after some googling it's been suggested that it's either a hard drive,
> the sata controller or the sata cables.
> how do i go about diagnosing and fixing the problem,
> any suggestions or guidance would be appreciated.
> shadrock
I've had this problem before. IIRC, you can match up the ata17.00 with what
drive it's talking about by looking at your kernel boot messages. The first
thing I would do is switch out the SATA cable and see if the problem persists.
If that doesn't work, run a scan of the drive using the manufacturers scan
program.
