I have a couple C5 systems I want to back up. My plan is to, one way or another, back them up to a C5 machine in my office. I have samba installed on the systems to back up, the machines are mounted on the system in my office, and a tape library hanging of the system in my office. I was hoping to perform a simple /sbin/dump of the remote systems. I put together a script for another successful backup I have going on a system with local filesystems. But for remote filesystems, I get errors of File Cannot Be Accessed (//remote_system/subdir) which does exist as an smb mounted filesystem. I'd use NFS, but I would like a bit more control and some level of encryption for the user authentication and data being transferred. If a direct dump of remote smb filesystems isn't possible, I may opt to have each system perform their own local dumps, then run a script locally on the tape-connected machine to dump those local dumps, or copy the dumps locally then dump them to tape. If nothing else works, I can always install Windows XP and use Windows backup program, but I'd really like to try and get this going under Linux before going that route. Thanks for insights. Scott
> I have a couple C5 systems I want to back up. My plan is to, one way > or another, back them up to a C5 machine in my office. I have samba > installed on the systems to back up, the machines are mounted on the > system in my office, and a tape library hanging of the system in my > office. > > I was hoping to perform a simple /sbin/dump of the remote systems. I > put together a script for another successful backup I have going on a > system with local filesystems. But for remote filesystems, I get > errors of File Cannot Be Accessed (//remote_system/subdir) which does > exist as an smb mounted filesystem. > > I'd use NFS, but I would like a bit more control and some level of > encryption for the user authentication and data being transferred. > > If a direct dump of remote smb filesystems isn't possible, I may opt > to have each system perform their own local dumps, then run a script > locally on the tape-connected machine to dump those local dumps, or > copy the dumps locally then dump them to tape. > > If nothing else works, I can always install Windows XP and use Windows > backup program, but I'd really like to try and get this going under > Linux before going that route.use amanda, www.amanda.org it rocks
Scott Ehrlich wrote:> I have a couple C5 systems I want to back up. My plan is to, one way > or another, back them up to a C5 machine in my office. I have samba > installed on the systems to back up, the machines are mounted on the > system in my office, and a tape library hanging of the system in my > office. > > I was hoping to perform a simple /sbin/dump of the remote systems. I > put together a script for another successful backup I have going on a > system with local filesystems. But for remote filesystems, I get > errors of File Cannot Be Accessed (//remote_system/subdir) which does > exist as an smb mounted filesystem. > > I'd use NFS, but I would like a bit more control and some level of > encryption for the user authentication and data being transferred. > > If a direct dump of remote smb filesystems isn't possible, I may opt > to have each system perform their own local dumps, then run a script > locally on the tape-connected machine to dump those local dumps, or > copy the dumps locally then dump them to tape. > > If nothing else works, I can always install Windows XP and use Windows > backup program, but I'd really like to try and get this going under > Linux before going that route. > > Thanks for insights. > > ScottWhat you could do is to dump from the remote machine to the main backup machine. For this to work I work with ssh keys (no password needed). The example assumes the backup is started from the remote host. But in principle it can also be initiated from the backup server using ssh. SRC_SERVER=this_hostname BAK_SERVER=backup_server DATE=$(date +%Y%m%d) dumplevel=0 export RSH=ssh ssh $BAK_SERVER mkdir -p /backup/${SRC_SERVER}/${DATE}_${dumplevel} # file needs to exist backup_file=/backup/somefile ssh $BAK_SERVER touch ${backup_file} dump -${dumplevel} -u -z -f $BAK_SERVER:${backup_file} /dev/VolGroup00/VolGroup00 Theo
dump works at the device level, dumping the raw block device by interpreting the ext2/3 structures there. If you pass it a directory, it converts it to the device mounted there and dumps the device. restore, on the other hand, operates at the filesystem level. You don't need to be root to dump. Your dump script can run as anyone in the "disk" group, the default group of disk block devices, which by default have group read access. You do need to be root to verify, though, because restore is going through the filesystem. I back my CentOS box up to a USB-attached hard drive on a Windows XP workstation mounted via cifs. This is effectively a "push" system. After the backup, I run "restore -C" to verify that the data got there successfully. During the verify pass, I remount the filesystem with the noatime option so that reading it to compare to the "tape" image on the USB drive does not change the atimes. I then re-enable atime when the verify is done. (I use atime to watch for dead email accounts and so that tmpwatch will work correctly.) dump has its own home page and mailing list, and the author is very helpful with support. http://dump.sf.net/