Linux Blog

Things I don’t want to do in 2009.

Filed under: General Linux — TheLinuxBlog.com at 8:59 am on Tuesday, February 3, 2009

Things I don't want to do in 2009
Since we are now in the second month of 2009 I figured it would be a good time to follow up on My Goals for 2009. I have not made much progress on my goals, but hey any progress is progress right? This post is my list of things that I do not want to repeat in 2009, either from 2008 or before. Only the first item is non-technical and this list is not quite as long as my list of things I want to achieve in 2009. I’m sure I’ll think of more as the year goes on. Again, its not an all-inclusive list and I hopefully won’t have to come and amend this document too quickly, if at all, oh who am I kidding I should probably add to this before I even post it.

We’ll start off what happened to me on new years eve 2008. To say the least I got very drunk, meaning that I was so hung over that I couldn’t function. Therefore I spent the rest of the day in bed, I’ll try not to make a repeat of this in 2009 on any account. New years eve or not, what a way to start the new year.

I’m pretty sure that I did this one in 2008, if not I’ve done it in the past and do not want to repeat it. It involves some personal data and a mistyped command, resulting in data loss. What about backups? Well it doesn’t help if the mistyped command was intended to make a backup of the data rather than destroy it.

Working on production machines. This is a touchy subject, sometimes there are times you HAVE to work with production machines, there is just no way around it. What I aim to do, is not work on them as often. For example, I can copy a portion of a live database to my development machine and work on it from there rather than just copy the database or table on a production machine. This way I will prevent locking up tables with a poorly written query and perhaps avoid a restore from backup or rather large oh $#@! moment.

I don’t want to run a certain distribution for my servers in 2009. I’ll keep the distribution anonymous in this one but those that know me will know one of my dirty little secrets. It’s not them, its me. It involves a bleeding edge distribution that gets updated every six months or so. In short it shouldn’t be used in a production environment. I wasn’t involved in the decision to run this distribution but I will be involved in solving this nightmare.

To end this list I give you the epic chmod 755 -R while in the root directory. I don’t think this one needs any more explanation.

An rsync primer

Filed under: General Linux,Linux Software — TheLinuxBlog.com at 12:55 am on Tuesday, January 13, 2009

An rsync Primer

rsync is a great tool used to copy or “sync” files locally or remotely. Having just lost a fair amount of important personal data its good to make the point that you can lose data if you use rsync, so make sure that you know what you are doing works before putting it into production.
“Whats so great about rsync?”
I hear you ask.

Well, there are many ways of copying data around, regular old cp, scp and rcp but what sets rsync apart is that it’s capable of syncing those files that have changed, or those that are missing. In other words, why do a full copy of all files, risking further corruption when only some have changed?
rsync also handles compression and verifies that the files were written correctly.
The syntax for rsync is fairly straightforward, those of you familiar with the rcp or scp should be easily able to relate to that of rsync.

The syntax for a local file copy is:

rsync [OPTION...] SRC... [DEST]

-avz is the option that I use most commonly.

-a for archive, -v for verbose and -z for compression. As lame as it may sound, I actually remember the syntax for this as “Alien Vs. Zeus.” Sounds stupid, but it actually works.

Since I do not normally sync directories locally, one of my hosts is usually remote. rsync is configured to use SSH by default, but rsh can be used if preferred. I stick with the default SSH for simplicity. The syntax is very similar to scp’s

To Pull: rsync [OPTION...] [USER@]HOST:SRC... [DEST]
 
To Push: rsync [OPTION...] SRC... [USER@]HOST:DEST

If you like to back up all files matching a pattern the same syntax applies but you specify a pattern. An example is you could backup all .conf files from /etc (provided you have read access) to another host by doing the following:

rsync /etc/*.conf [USER@]HOST:DEST

If you do the above, I am assuming that you would also want to backup other configuration files within the /etc/ directory. Instinct tells you if you have read the man page to just use -r however you may want to just do a full backup as rsync with a pattern by default does not traverse into directories.

Compression is really a nice feature for transferring large amounts of data. To demonstrate the speed increases that the -z option gives my full /etc/ directory which is 48M. It took 0m12.671s with compression and 0m35.657s without. This was over wireless from a dual core 2GHz laptop to a 1.8GHz wired desktop, so your results may vary. Either way compression or no compression rsync is a handy utility that should be able to make your life of copying files around a little easier.