Sponsored Content
Special Forums UNIX and Linux Applications Infrastructure Monitoring Monitoring file systems backup Post 302901048 by hicksd8 on Sunday 11th of May 2014 07:45:52 AM
Old 05-11-2014
You don't state what hardware platform you have, what the cluster software suite is, or what the backup software is.

Your post indicates that you have a good understanding of how a (generically speaking) cluster works and that any one filesystem can only be under the control of one node at a time. Having multiple nodes thinking they could write to the volume would be anarchy and a clear recipe for data corruption. It is definitely the job of the cluster software suite to ensure that that never happens. Having said that, different cluster suites can have starkly different functionality.

Similarly, backup software suites also vary in the manner of operation.

So discussing cluster backup in generic terms I would say that there are two options for implementing backups. Firstly, when node-A fails and node-B takes over (by checking orphaned filesystems and then mounting them, taking over and broadcasting the cluster name and ip address (node-C and ipaddr-C) some cluster software will also failover scheduled jobs (eg, backup). Of course, the backup device(s) need to be still available (or node-B needs to have its own tape drive, for example) for this to work. Alternatively, like all the user community who only know about node-C and ipaddr-C, the backup is run from a machine outside the cluster which "calls in" on node-C, accesses or NFS mounts the filesystem, and backs it up. Usually, this is the preferred method.

Now in this scenario the backup software has no knowledge that it is backing up a cluster volume and it should work exactly the same way as it would with a local volume, ie, if it loses communication with the volume, it will report a backup failure. Some backup software suites (eg, NetBackup) are of client/server architecture which are very intelligent and will report failures in exactly the same way they usually do.

So in summary, the fact that it is a cluster should be largely irrelevant to reporting errors in backup schedules. How the success of a backup is verified is the same as the non-cluster scenario.

Hope that helps. Feel free to continue your questions but please give us all a clue of the platform and software(s) involved.

Last edited by hicksd8; 05-11-2014 at 12:46 PM..
 

4 More Discussions You Might Find Interesting

1. Filesystems, Disks and Memory

Backup Linux file systems

Hi, I need to backup files on our Solaris machines onto a windows machine. I have Samba installed. Is it possible to backup these files on Solaris/Linux machines onto a Windows machine. Thanks Aravind (1 Reply)
Discussion started by: aravind_mg
1 Replies

2. UNIX for Dummies Questions & Answers

Backup Software for UNIX systems

Hi, which software is recommended for backup of UNIX systems ( e.g. SUN, Solaris ). Backup software and database e.g. Oracle. One possibility is Networker, but license is expensive and also service contract. Best regards Dieter (2 Replies)
Discussion started by: rhacodactylus
2 Replies

3. UNIX for Dummies Questions & Answers

Monitoring Unix systems

I am looking for a commercial tool that will give me -UNIX Monitoring performance solution+ reports on CCV format. (as perfmon on windows machines). The tool must have following counters per PROCESS: Page Faults/sec Virtual Bytes % Processor Time Handles count Threads count... (19 Replies)
Discussion started by: gen4ik
19 Replies

4. AIX

How to exclude directory from (File Systems) backup?

Hello AIX experts, I have a file system called /bossapp Its size = 77.5 GB I want to take a File Systems backup for this one using smitty, it is very easy, but the problem is I want to exclude one directory called (ORIGIN). How? The steps are very easy to take a File Systems backup,... (2 Replies)
Discussion started by: Mohannad
2 Replies
fstab(5)							File Formats Manual							  fstab(5)

Name
       fstab - file containing static information about known file systems

Description
       The  file  contains  descriptive information about the known file systems.  By convention, is created and maintained as a read-only file by
       the system administrator.  Each file system is described by its own line within The order of these lines and the file systems  they  repre-
       sent is important because and sequentially process in the performance of their tasks.

       The format of each file system description in is as follows:
       spec:file:type:freq:passno:name:options
       The meanings of these fields are:

       spec	 The block special file name of the device on which the file system is located.  It can also be a network name for such as or

       file	 The pathname of the directory on which the file system is mounted.

       type	 How the file system is mounted.  The ways in which a file system can be mounted are:
		 rw - mount the file system read-write
		 ro - mount the file system read only
		 rq - mount the file system read-write with quotas
		 sw - make the special file part of the swap space
		 xx - ignore the entry

       freq	 The frequency (in days) with which the command dumps the rw, ro, and rq file systems.

       passno	 The order in which the command checks the rw, ro, and rq file systems at reboot time.

       name	 The  name  of	the file system type.  File systems can have the following types: ufs -- ULTRIX file system and nfs -- SUN Network
		 file system.

       options	 The options field.  This field contains an arbitrary string meaningful only when mounting file systems with  the  specified  file
		 system type name, such as NFS.  The specific options are described in the reference pages.

       Special	actions  occur for file systems of type sw and rq at system boot time.	File systems of type sw are made part of the swap space by
       the command and disk quotas are automatically processed by the command and then enabled by the command for rq file systems.

Examples
       Here is a sample file:
       /dev/ra0a:/:rw:1:1:ufs::
       /dev/ra1g:/usr:rw:1:2:ufs::
       /@bigvax:/bigvax:rw:0:0:nfs::
       /usr/uws2.0@bigvax:/usr/uws2.0:rw:0:0:nfs:soft,bg,nosuid:
       /usr/dec@bigvax:/usr/dec:rw:0:0:nfs:bg,soft,nosuid:
       /usr/pro/xyz@vax:/usr/pro/xyz:rw:0:0:nfs:bg,soft,intr,nosuid:
       The last three entries in the sample shown use NFS options as described in the reference page.

Restrictions
       The passno field of the root file system should be specified as 1.  Other file systems should have larger values.  File systems on the same
       device  should  have  distinct  passno  fields.	File systems on different devices may have the identical passno fields to allow them to be
       simultaneously checked.

       All field delimiters (:) must exist within each file system description; only the options field may not	be  present.   However,  only  the
       fields spec and type are meaningful to sw file systems and only the type field is meaningful to xx file systems.

       The file system description within should be parsed only through use of the routines.

Files
       File system information file

See Also
       getfsent(3x), dump(8), fsck(8), mount(8), mount(8nfs), mount(8ufs) quotacheck(8), quotaon(8), swapon(8)

																	  fstab(5)
All times are GMT -4. The time now is 11:40 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy