Slashdot Mirror


Ask Slashdot: >2GB Backup Software for Linux?

Fer asks: "Are there backup program for Linux that do not have filesystem or volume size limits? I am trying to make a full backup of a 22 GB FTP server, using 4 GB TR-4 tapes. I have tried tar, dump, afio, taper, and afbackup, and every one of them either did not allow >2GB volumes or had weird problems with >4GB filesystems. Currently I am using dd to do the job, but I think there must be another option. Any suggestions on free programs which I may use?"

3 of 173 comments (clear)

  1. There are three good choices. by jerodd · · Score: 5
    I like to backup one of my filesystems which has huge files (a 6.4GB file and a 2.5GB file). I use GNU tar with it. Simply use the -M switch, and tar doesn't have any problems with the huge files. I'm not sure if SysV tar supports it (i.e. the tar in any non-GNU Unix system). Note that the filesystem I am using (JFS) supports big files and I had to use emx v0.9d to support 64-bit file lengths (I'm using OS/2).

    You can also use AMANDA backup, which I use on my GNU/Linux machines for backup. It seems to handle the large backup sizes acceptably.

    Finally, you can always just split up huge files using dd.

    Cheers,
    Joshua.

    --
    --jon. Postel is dead. May we all mourn his, and our, loss.
  2. DUMP solution to +2GB by Amoeba+Protozoa · · Score: 5
    For the ISP I run, we do a nightly cron-driven backup using dump. The key is that you must specify the total length of the tape. We have a 23GB tape drive, of which we conservitively say the tape is 20GB long.

    Here is our cron.daily/daily.dump file:

    #!/bin/sh
    ## Daily Full System Backup Givin with 20GB Tape Cap.
    mt rewind
    mt erase
    mt rewind
    /sbin/dump 0uBf 20000000 /dev/nst0 /dev/sdb1
    /sbin/dump 0uBf 20000000 /dev/nst0 /dev/sda1
    /sbin/dump 0uBf 20000000 /dev/nst0 /dev/sdc1
    mt rewind

    This dumps all three of our partitions out to a single tape. The 0 ("zero") option dumps the entire thing, as out tape drive is fast, vs. specifing a dump level > 0 (which is for doing various levels of incremental backups); The u, which updates a human-readable /etc/dumpdates file; B for the number of blocks ("kilobytes") the tape is long (this is your problem); and finally f: the device to dump to.

    One of the things that really gets people is how to pass arguments correctly to dump. A little diagram might serve as an aid:

    dump [arg name 1][arg name 2][arg name 3] [arg value 1][arg value 2][arg value 3]
    Hope that helps!

    We use the /dev/nst0 device to write to the tape three times without the thing rewinding. This is the key to putting more than one filesystem on per tape.

    If anybody has any questions about using dump, I would be happy to help.

    -AP
    jordanh@remotepoint.com

  3. Are you writing straight to tape? by -Surak- · · Score: 5

    Tar and others should work fine as long as you are writing directly to tape, instead of to a temp file. Linux has a 2GB (2^31-1) maximum file size, so if your backup software is trying to spool to disk before streaming to tape, it may fail.

    Amanda handles this by splitting the disk files into 2 GB chunks and reassembling them when it writes to tape. It also deals well with network backups. The filesystem side backend is dump or GNU TAR, so it's fairly standard in that regard. I've had no problems with 8+ GB filesystems using Amanda.

    I would not recomend using e2fsdump - AFAIK, it's still beta, and I had problems with the interactive restore and some other issues. Because it accesses the filesystem at a lower level than standard file access (I believe), I'd be careful with trusting important backups to it.
    TAR definately a safer choice.

    BTW, I have a question myself... does anyone know how to get TAR (or something else) to restore permissions on symlinks? Typically it doesn't matter, but Apache uses symlink permissions for the SymlinksIfOwnersMatch directive, and every time I restore or copy a web partition, I have to go through and fix all the links that are now root owned.