Linux don't care...

Say for example, Windows won't let you delete or back up an open file. Even if you wanted to easily create a snapshot of a volume and back up an open file in a consistent manner, it's not that easy.

Linux don't care...

In fact, a recent question I was asked in an interview pre-screening, was whether you can delete an in-use logfile and if that space is automatically marked free by the OS?

The answer to that is, no. On Linux, a file can be deleted when it's in-use. The file will disappear from the FS, but the handle to the file will remain open, and in fact, the application will continue to write to the file even when its hard link count is now exactly zero! That log file will actually appear in the /proc filesystem under that process' PID, in its list of open files. In order to actually delete the file you need to close the file handle. This is done in various ways depending on the application, but it can usually be triggered quite easily, and as a sysadmin, you should why and how you should do this.

UNIX expects you to be a competent and knowledgeable sysadmin, and this has the advantage of creating a very predictable environment with few exceptions to basic tenets laid out as a contract of sorts

I like that.

I like being treated like an adult.

rsnapshot - it's for pulling, obviously!

It's been a few months since I learned about rsnapshot, a neat little utility that uses hard linking to create multiple point-in-time snapshots of your data. It combines the neat features of rsync into a package that does more than just mirror data.

If you've ever had clients who suffer from "data decay", you'd know that just having the most recent version of a file can be useless. An Excel spreadsheet could have been corrupted weeks ago, and people will continue to write changes to it--despite warning messages--until it really fails hard, which is always too late.

Conceptually I was having a hard time understanding the topology of rsnapshot server and the clients it's supposed to back up. Are you supposed to have rsnapshot on every client machine, connecting to the server using only rsync? Actually, no.

Quite foolishly I was modifying the snapshot_root directive in /etc/rsnapshot.conf to point to a network location (CIFS share), even though the comments clearly state that it's supposed to be a local root. I guess this should have been a no-brainer, but in my skimming of the documentation it wasn't clear why I couldn't set the snapshot_root to be a network location!

Only when I tried to use rsnapshot in conjunction with a TeraStation Live did I learn the truth! Behold, rsnapshot sits on the server, manages it's own backup root, and communicates with clients using only rsync, or rsync over SSH. This makes sense because the rsnapshot server must scan its local repositories for changes, and it does folder rotation. For example:

daily.0/

daily.1/

daily.2/

daily.3/

daily.4/

Say you set retention to 5 days. This means that the next daily backup will cause a rearrangement. daily.2/ becomes daily.1/ and daily.1/ becomes daily.0/, and daily.0/ disappears. On a local filesystem, these reflect simple inode reference changes for moves and renames, but on a remote FS, all bets are off.

On a related note. I'll have a quick guide on how to get root access to a TeraStation LIVE, and how to install rsnapshot.

A second post will go over how to initiate a VSS snapshot of a Windows drive over SSH in preparation for a pull backup from a Windows client to a Linux server.