How to recover lost data on an ext3/4 partition

I recently had a late-night oopsie with tar, overwriting the file I wanted to package (source code I had worked on for a week). After a few seconds of creepy feelings, I remembered that I use a journaling filesystem and thus, there would be a good chance that there would be several copies of the data still physically lying around on the storage medium.

So, what to do when you lost a file? For your first action, you have two options.

First option: Power off the system without shutting it down, then boot from a live CD. The foolproof option.

Second option: If you can ensure that no new files will be created on the filesystem where the loss occured while you are trying to recover the data, you can work from the running system and avoid further potential data loss from uncleanly powering down the system.

Next, become root and grep the filesystem where the data loss took place.

grep -a -B300 -A300 "searchString" /dev/sdb1 > dumpfile

searchString is a piece of text that preferably only occurs in your lost file. Try to be as specific as possible so you ideally only get results from the file's contents. The -B and -A options specify the number of context lines to output before and after each match. Choose values large enough to include the entire lost file, if possible. Replace /dev/sdb1 with the device node of the filesystem where the lost data is. You can find out the node by just running mount without parameters. dumpfile is the target file containing the found text. Of course the dump file should not be saved on the partition where you lost the data! Save it on another filesystem or a tmpfs if you have one set up. Mounting a USB stick or something for the dump file may be risky because a device node will be created on the root partition, which stinks if your lost data sits exactly there.

After grep is done, examine the dump file with a text editor. If you are certain that it contains your entire lost file in a usable or recoverable state, you can start copying and pasting into empty files, restoring various versions of your file of which a few will probably be current.

Build a secure home network using SSH

This Howto explains how to build a local network where communication between machines takes place over the Secure Shell Protocol. This is not only more secure (especially over wireless) but also enables you to conveniently get a remote shell on every machine.

I'm assuming the machines are connected to each other via a dedicated hardware router, but network topology does not really matter as long as all machines can see each other. Also I'm assuming all machines are on the same network segment, i.e. you have a typical small-scale home network.

First, install the ssh metapackage on the machines you want to connect. On Debian based systems, this will get the OpenSSH client, the OpenSSH server and the blacklist of insecure keys. All are required for the setup to function properly.

Next, we will add some basic network security. On the machines you want to connect make sure that /etc/hosts.deny contains the line

ALL: ALL

This blocks all inetd controlled services (most stuff except HTTP and Samba) coming from all hosts by default. In /etc/hosts.allow add:

ALL: LOCAL

This allows all services running on your local network (i.e. all hosts whose names don't contain a dot) to access the local host.

If you are paranoid and only want to allow ssh, instead use

sshd: LOCAL

You will likely not be running a DNS server on your network, so you will have to set the hostnames on each machine. The top of each /etc/hosts file should contain something like

127.0.0.1 localhost
127.0.0.1 nameofthismachine

Where nameofthismachine is the desired hostname for the local computer. In the same file, add the IP addresses and hostnames of all other machines that machine should be able to connect to, for example

192.168.0.2 anothermachine
192.168.0.3 yetanothermachine

You can find out the network IP address of a box either by running ifconfig on that machine or logging into the router and looking at the logs.

Changes to the hosts* files should come into effect immediately, but the router may be slow to pick up hostname changes, so it is a good idea to power cycle it now to renew the DHCP leases and update the routing table.

Now, at one of the boxes, try

ssh username@someotherbox

and if ssh can connect to someotherbox, you are asked for username's login password. Now you can work with that shell like you were sitting in front of the other computer. You can also start GUI programs when adding the -X switch (which enables X11 forwarding). For better performance but less local security you can add -Y to enable trusted X11 forwarding.

ssh -X -Y username@someotherbox

Then you can start xeyes or some other graphical app for testing. Depending on the processing power of your router and link speed, even watching DVDs over the SSH connection may work well.

Ok, what about transferring files? You have several options here. When working on a shell with Midnight Commander, you can establish a shell connection via the Left/Right menus. In KDE, Dolphin/Konqueror and file dialogs understand the fish:// protocol (example: fish://username@someotherbox). Similarly, you can use ssh:// in many Gnome applications. You can also mount the remote computer's filesystem using sshfs.

If you have a network service running on one of the machines, like a streaming server, you may want to tunnel the data through SSH too. To tunnel port 6666, with the local machine at the receiving end, do

ssh -R 6666:localhost:6666 username@server

Hopefully, this article has helped you secure your network a bit.