You do do backups don’t you? Backups to
DVD is easy, but what software to use?
Do you want the DVD backup ‘mountable’?
If it is then you can see each file and selectively restore using the normal file management tools (cp, rsync etc)
If you use some sort of ‘dump’ format (tar, cpio, zip or proprietary) then you will need the corresponding tool to access the backup Why not simply
k3b?But if it some down to it, there’s a decision tree you can and should work though.
My choice, based upon both K.I.S.S. and bitter experience is to go with the mountable.
– How are you ‘snapshoting’ your files?
If you are backing up a live system then there is the risk that the backup is out of phase with itself as files get changed during the time it takes to make the backup.
My solution to this is to use the snapshot mechanism of
Logical Volume Management
– How are you managing the backup archives?
Do you need a specific dated version of a file or directory?
Would a VCS be more appropriate than a backup system?
Sometimes you need both. I maintain changes to config (mainly in /etc/) with a VCS – AND take periodic snapshots.
Ultimately its not about making backups, even if that seems to be the
most of the work, but the ability to restore.
A client found it easier to take whole image backups but once when having to restore a single file there was a finger-slip and he restored the complete machine state of three years previously, loosing all that days work plus the next day when the machine was out of service being restored to the last (previous) backup. The moral here is that your RESTORE strategy, as determined by your normal business functions and NOT by the convenience of the IT department, should determine your
– How “automated” do you want this backup to be?
Sometimes you’ll find the automation tail wags the normal operation dog.
My use of
K3B means I do disk-to-disk-to-DVD. (Using LVM’s snapshots)
It also means I structure my file systems so that they can be imaged onto a DVD. It means I can retrieve single files or mount the DVD and use it in place of the file system. It also means that I can create arbitrary backups, cherry-picking the files and folders to backup.
I realise this is going to be inappropriate for many sites and business functions.
This is why I STRONGLY suggest that instead of simply asking for suggestions you work through what are the key, the critical and the nice-to-have features of your
backup AND RESTORE functionality.
Any package you might choose is going to have constraints and assumptions about The Way Things Are. You need to be aware of those and need to consider if they fit in with The Way You Work. A backup system that works well for a data center of ISP might be totally inappropriate and troublesome for a
 Once upon a long time ago systems were shutdown or all jobs
suspended for the backup. This has disrupted projects for me a number
On one of the professional forums I subscribe to there was a request for “references” to justify the separation of development and production networks and facilities. It seems some managers “
don’t get it
” when it comes to things like
and undocumented and unplanned changes. Many guidelines discuss this, but its seems that some key ones like
do not explicitly mandate it, and some managers use this as a reason to not do it.
Some of us security droids find this frightening.
My colleague Miriam Britt managed to sum up the reasons why one should have separation quite sussinctly and forcefully. With her permission I have copied her
reasoning here and I hope many people will either reference this or copy it to their own blogs. This kind of straight forward statement needs a wide exposure.
Continue reading Network Segmentation is Common Sense