Backup Application of the Year
 

What's your preferred tool for backups?

--jeremy

Here I should give multiple answers :)
Anyway I say tar

tar over ssh to a remote linux box with a lot of storage

fsarchiver

luckybackup.

Dump because it's been saving my bacon for years, and I ain't seen anything that isn't Just Another Dump At Heart plus window dressing and/or helpers.

rsync is awesome! All my backups are done using scripts that use rsync! :)

Bacula works great.

I am missing burp! Great tool for private and office use..
http://burp.grke.org/

Burp has been added.

--jeremy

I use Clonezilla. It is great tool with many options, supports cloning using quad core processors (usuable when we want to compress image file). As a matter of fact, i use it for all my systems (Arch, Slackware, Ubuntu...and even Windows). Clonezilla is something that gives me great controll over backup process, also, there is terminal built in, command line available. I can record cd and start using it - i don't like backups apps that works with shadow clones (on running system) like Symantec backups apps.

You should include in this list Dropbox and SpiderOak, or create a new appropriate category.

Hi Jermy,dd can also be used as a backup tool.

luckybackup

cp

damn, forum doesn't allows to post message "cp" - too short

My backup solution is a custom bash script based around piping the results from find to cpio, so cpio it is.

I use shootsnap, with a restricted keyset and a large AOE array.

http://typinganimal.net/code/textify.php?f=shootsnap.sh

Filesize limitations with the bin, odc or newc file formats would make GNU cpio a poor choice for many. If you like cpio I would use bsdcpio (or heirloom cpio) with pax format or use afio.

You could also get GNU tar to use the pipe to read its file list, e.g. "tar --no-recursion -T- -cvf archive.tar", again with pax file format or even just gnutar file format. Neither have any serious limitations.

Pax is another option but make sure it is heirloom Pax as the pax util provided by most distros cannot actually make pax formatted archives, only ustar, which is really no better than newc.

MAS (To use Tim Minchen's suggestion of "mildly amused smirk" rather than LOL :) ).

Thanks for the technical advice, but for the situation I have, backups of recently acquired files on a suite of Windows machines, I like cpio for the ability to manipulate path names. It has been working fine for years. I do not want to use a packed archive format, as what is required is to be able to read files directly from the Windows machines. It is also easier to demonstrate the recovery process to the occasional external auditor when our quality system is being assessed. The disaster recovery plan for these Windows machines (basically dedicated instrument controllers) is to restore a known good disk image, then restore any needed recently acquired files from backup. The file size issue will not occur due to the way these Windows machines are used.

I think what I am really trying to say is just the truism that the best choice of backup system heavily depends on what taking backups is trying to achieve.

You can do the same with numerous other utils, including those I mentioned (e.g. GNU tar has the --xform switch).

Fair enough but as computing changes and common file sizes increase you may find a time where you hit the individual file size limitations of the old cpio formats (bin = 2GB, odc = 8GB, newc = 4GB). I know that I personally have multimedia files and Linux distro ISO images in these size ranges lying around on my disks. afio extends the odc format (only for entries that need it) past these limits and pax has no real, practical limits right from the get go (9 EB file sizes are possible).

I'm not sure what you mean by this but the pax file format is the POSIX.1-2001 standard file format and an extension of tar. There are numerous utilities available on Windows that will open its contents just fine. Additionally as afio works with odc by default and only extends the header on entries that exceed its limitations its archives should also be readable using common Windows archiving tools, particularly as you state no files currently do exceed the limits.

I fail to see how this would be different if you used pax or afio.

Fair enough, I did not know your specific use case until you just stated it, so it could well have been an issue. In any case you can just take the information (assuming you were not already aware) as something to keep in mind for the future.

Sure, I agree with that. It was just a warning that (IMHO at least) cpio (the GNU implementation in particular) has run out of steam as it is no longer being actively developed to handle the types of files that are ever more common in the modern world. So it was just a heads up, so that you don't get bitten in the future. Like all advice on the internet you are free to just ignore it! ;)

Should inclute tarsnap - defitely my choice.

Having a single backup isn't exactly the best idea for protecting your data. If one of your backup mediums gets damaged or destroyed, it's very difficult to restore from your backup.

I follow the 3-2-1 backup philosophy quite strongly: 3 copies, 2 mediums, 1 off-site.

I'm using CrashPlan for my off-site backup solution and Deja-Dup for my local backup. Having a local backup is immensely useful, since there are many times where you might need to restore your data from a backup but not have the time, patience, or bandwidth to restore from an online backup service; the online backup service comes in handy when something catastrophic occurs, such as a fire, theft, or natural disaster.

I also store most of my media files on a dedicated file server at my friend's house in another state (since he has a fast FiOS connection).

I agree about the value of a local backup. I was thinking about off-site backups when I mentiond tarsnap. I think it's good to have both.

I use rsnapshot as part of my automated plan. I also use grsync on regular basis for selective backups. FSArchiver is also quite useful.

tar

There are many good ones such as: Bacula, Amanda, rsync etc. but I will go for Legendary TAR

Git annex
http://git-annex.branchable.com/

CloneZilla

tar with bzip2

rsync

rsync

I think Bacula takes the win here. True enterprise grade, sports clients for both *nix and Winwoes so works in mixed environments. Then probably Amanda. Although admittedly I have not used either much as of late. Both would be massive overkill if you're just backing up a single workstation.

My $0.02

Peace-- :)

You're hard core! Most companies aren't even that diligent.

I didn't vote because none is best -- rather it is a question of "horses for courses", that is which best meets the requirements.

We used to use amanda, rdiff-backup and rsync. I personally use Bacula, rsync and SpiderOak (a cloud backup service).

We have now almost completed migrating away from amanda and rdiff-backup to rsync run by a script which adds retention. The motivation is that neither amanda nor rdiff-backup are robust when they are interrupted while they are running; that is a problem because some of our clients shut down their systems while backups are running and our Internet connections are not reliable.

Comparing the tools I know:

• amanda
  • Compresssed backup files: yes
  • Ease of configuration: yes
  • Graphical interface: no
  • Network loading: not known
  • Point in time restore: yes
  • Poor cousin to the commercial edition: yes
  • Retention: yes
  • Robust when interrupted: no
• bacula
  • Compresssed backup files: yes
  • Ease of configuration: no
  • Graphical interface: yes
  • Point in time restore: yes
  • Network loading: not known
  • Poor cousin to the commercial edition: no
  • Retention: yes
  • Robust when interrupted: not known
• rdiff-backup
  • Compresssed backup files: no
  • Ease of configuration: yes
  • Graphical interface: no
  • Network loading: minimal
  • Point in time restore: yes
  • Poor cousin to the commercial edition: not applicable
    [*[Retention: yes
  • Robust when interrupted: no
• rsync
  • Compresssed backup files: no
  • Ease of configuration: yes
  • Graphical interface: no
  • Network loading: minimal
  • Point in time restore: no
  • Poor cousin to the commercial edition: not applicable
  • Retention: no
  • Robust when interrupted: yes

Amanda's error handling seems less robust than bacula's and, being written in perl rather than compiled, it is at the mercy of changes in the perl interpreter. The last point is not academic; on ubuntu 12.04 a recent perl upgrade which includes stricter syntax checking has broken amanda.

Forgot G4U and dd.

Bacual may be a bit of a pain to set up - not really, you just really need to actually read the docs - but it excels at doing what it says it will do. Regarding the poor cousin consideration, this is why I never really got behind Amanda. Bacula is overkill for a home PC, but great for actual enterprise use.

Oh, yeah, it has a gui now? Ooh, la, la!!

Peace :cool:

Simple Backup
 

Simple Backup. Simple Backup is proving to be excellent now. When I first installed the program it seemed quite fickle (with external drives) but still seemed to be superior to the other programs. Simple Backup worked as expected with your main drive but was unreliable with external networked drives. Whether the bugs were fixed or I learned how to adapt - I don't know, but it has been working very well now. I am backing up (three computers) to one external USB Hard Drive that is attached to a router.

Based on my experience, Simple Backup appears to be more reliable when the following factors are taken into account:

1. When the USB drive is mounted through FSTAB.
2. When the USB drive is formated for Linux. My router does not recognize EXT4, so I had to format it with EXT3. Other routers with USB ports may recognize EXT4.