Re: [Bacula-users] Corrupted filesystem using iSCSI
Hello,
In my opinion, using network mounted disks for backup is a risky
business. Bacula is designed to work with direct attached disks and
tapes, so when you connect them instead by a network, you introduce more
errors (networks have more faults than direct attached devices), delays
(latency), and buffering problems. Latency problems are particularly
bad for a SCSI device because it is a very chatty protocol.
Bottom line: a lot of people use NFS/CIFS or iSCSI, but I wouldn't bet
my data on them.
NFS tends to be very unfriendly with Bacula for two reasons:
1. If the NFS connection drops, Bacula can wait forever (something dumb
in the implementation) hanging on a system call.
2. If the NFS partition fills, you may not know about it until the
device is closed (end of Job) and then it is too late to do much of
anything.
Best regards,
Kern
Best regards,
Kern
On 07/21/2014 07:20 PM, Fábio R. Medeiros wrote:
Hello folks!
I've running Bacula 5.2 in a FreeBSD box. We use an iSCSI NAS as the
storage device...
Today I tried to make a restore test and FreeBSD says me that the iSCSI
target's filesystem (UFS2+j) was corrupted and needed to be repaired. I
ran fsck and all gets fine. Is this normal? If so, are there any
workarounds (i.e. spool or run before/after job directives) in order
to minimize the need of these checks?
Does anyone have experience with Bacula and iSCSI devices?
Here is my Device resource config on bacula-sd.conf:
Device {
Name = STORAGE
Media Type = File
Archive Device = /mnt/bkp
LabelMedia = Yes
Random Access = Yes
AutomaticMount = Yes
RemovableMedia = No
AlwaysOpen = Yes
Minimum Block Size = 32768
Maximum Block Size = 32768
Block Checksum = Yes
}
Regards!!
Fábio
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
a
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] Fatal error: askdir.c:355 NULL Volume name. This shouldn't happen!!!
Sadly, this error is still present in v7.0.4. There is another error, too, where there is no writeable media in the tape drive. Fatal error: spool.c:263 Fatal append error on device LTO5-2 (/dev/tape-admin2): ERR=tape_dev.c:161 Unable to open device LTO5-2 (/dev/tape-admin2): ERR=No medium found Both of these are a result of race conditions occurring on tape libraries with multiple tape drives, one job per drive, and several backup jobs running nearly simultaneously. Frequently, the storage daemon requires a restart in order to release the tape drive affected by the error since the SD still sees a running job, however, the director has already indicated the error, sent the notification, and does not have a running job to cancel. On a busy system, restarting the SD can be problematic, and losing one or more tape drives is also a problem. My question, why isn't Bacula happy with a writeable volume from the same pool if one is mounted in the tape drive assigned to a job? Patti Clark Linux System Administrator RD Systems Support Oak Ridge National Laboratory -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] issue with setuid/gid on restored files
Sorry if I have not researched this enough before bringing it to the list, but what I'm seeing is very odd. Someone else must have run into this before me. If I restore a setuid or setgid file, the file is restored without the setuid/setgid bit set. However, the directory containing the file (which did not have it's setuid/setgid bit set during the backup) winds up with the setuid/setgid bit being set. If I restore both the directory and the file, the directory ends up with the proper non-setuid/setgid attributes, but the file once again ends up without the setuid/setgid bit set. I'm assuming the directory has the bit set during an interim stage of the restore, but is then properly set when it's attributes are set during the restore (which must happen after the files that it contains). I can't say authoritatively, but I don't believe this is the way bacula used to behave for me. And to say the least, this is far from acceptable. I discovered this during a bare metal restore, and have loads of issues from no setuid or setgid bits being set on the restored system. thanks, Stephen -- Stephen Thompson Berkeley Seismological Laboratory step...@seismo.berkeley.edu215 McCone Hall # 4760 510.214.6506 (phone) University of California, Berkeley 510.643.5811 (fax) Berkeley, CA 94720-4760 -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] issue with setuid/gid on restored files
I'm running 7.0.4. Here's an example... (before backup) # ls -ld /bin dr-xr-xr-x 2 root root 4096 Jul 22 09:56 /bin # ls -l /bin/ping -rwsr-xr-x 1 root root 40760 Sep 17 2013 /bin/ping (after restore selecting file /bin/ping) # ls -ld /bin drwsr-xr-x 2 root root 4096 Jul 22 14:38 bin # ls -l /bin/ping -rwxr-xr-x 1 root root 40760 Sep 17 2013 ping (after restore selecting file /bin/ping and directory /bin) # ls -ld /bin dr-xr-xr-x 2 root root 4096 Jul 22 14:38 bin # ls -l /bin/ping -rwxr-xr-x 1 root root 40760 Sep 17 2013 ping In the first restore case, looks like the dir has user-write permissions as well, which isn't right, but perhaps that comes from the umask of the restore since the directory wasn't part of the restore selection. However, the setuid bit certainly wouldn't be coming from the umask. I'm jumping to the conclusion that whatever's doing the setuid bit is messing up and doing it to the parent directory instead of to the file. Stephen On 7/22/14 2:58 PM, Stephen Thompson wrote: Sorry if I have not researched this enough before bringing it to the list, but what I'm seeing is very odd. Someone else must have run into this before me. If I restore a setuid or setgid file, the file is restored without the setuid/setgid bit set. However, the directory containing the file (which did not have it's setuid/setgid bit set during the backup) winds up with the setuid/setgid bit being set. If I restore both the directory and the file, the directory ends up with the proper non-setuid/setgid attributes, but the file once again ends up without the setuid/setgid bit set. I'm assuming the directory has the bit set during an interim stage of the restore, but is then properly set when it's attributes are set during the restore (which must happen after the files that it contains). I can't say authoritatively, but I don't believe this is the way bacula used to behave for me. And to say the least, this is far from acceptable. I discovered this during a bare metal restore, and have loads of issues from no setuid or setgid bits being set on the restored system. thanks, Stephen -- Stephen Thompson Berkeley Seismological Laboratory step...@seismo.berkeley.edu215 McCone Hall # 4760 510.214.6506 (phone) University of California, Berkeley 510.643.5811 (fax) Berkeley, CA 94720-4760 -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
