[nflug] backups on an nfs server

[Cyber Source]

Mark Musone wrote:
> FYI,
>
> Don't get me wrong, i'm a dump/restore lover myself, and until last week swore up and down that it's stil lthe best thing since sliced bread..
>
> HOWEVER..the following has gotten me seriously thinking otherwise..(you can google more info about it too..soem more recent)
>
>
>
> http://lwn.net/2001/0503/a/lt-dump.php3
>
> From:	 Linus Torvalds <torvalds at transmeta.com>
> To:	 Neil Conway <nconway.list at ukaea.org.uk>
> Subject: Re: [PATCH] SMP race in ext2 - metadata corruption.
> Date:	 Fri, 27 Apr 2001 09:59:46 -0700 (PDT)
> Cc:	 Kernel Mailing List <linux-kernel at vger.kernel.org>
>
>
> [ linux-kernel added back as a cc ]
>
> On Fri, 27 Apr 2001, Neil Conway wrote:
>   
>> I'm surprised that dump is deprecated (by you at least ;-)).  What to
>> use instead for backups on machines that can't umount disks regularly? 
>>     
>
> Note that dump simply won't work reliably at all even in 2.4.x: the buffer
> cache and the page cache (where all the actual data is) are not
> coherent. This is only going to get even worse in 2.5.x, when the
> directories are moved into the page cache as well.
>
> So anybody who depends on "dump" getting backups right is already playing
> russian rulette with their backups.  It's not at all guaranteed to get the
> right results - you may end up having stale data in the buffer cache that
> ends up being "backed up".
>
> Dump was a stupid program in the first place. Leave it behind.
>
>   
>> I've always thought "tar" was a bit undesirable (updates atimes or
>> ctimes for example).
>>     
>
> Right now, the cpio/tar/xxx solutions are definitely the best ones, and
> will work on multiple filesystems (another limitation of "dump"). Whatever
> problems they have, they are still better than the _guaranteed_(*)  data
> corruptions of "dump".
>
> However, it may be that in the long run it would be advantageous to have a
> "filesystem maintenance interface" for doing things like backups and
> defragmentation..
>
> 		Linus
>
> (*) Dump may work fine for you a thousand times. But it _will_ fail under
> the right circumstances. And there is nothing you can do about it.
>
>
>
>
> On Thu, Aug 03, 2006 at 06:47:19PM -0400, Cyber Source wrote:
>   
>> eric wrote:
>>     
>>> which would be better with a mounted nfs share from a nfs server.
>>>
>>> executing a tar and gzip command to package a home dir on the servers
>>> share from the client or
>>> executing a tar and gzip command to package a home dir on the client and
>>> then moving the package to the servers share?
>>>
>>>
>>> I will want to increment files once a full backup is created, so I'm not
>>> sure which would be better in the long run.
>>> What seems to be quicker is to execute the increment on the share across
>>> the network instead of always moving/coping a large package from client
>>> to server.
>>>
>>> Thank you for your input,
>>> Eric
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> nflug mailing list
>>> nflug at nflug.org
>>> http://www.nflug.org/mailman/listinfo/nflug
>>>
>>>  
>>>       
>> Gotta LOVE NFS!
>> Here is what we do, and it works very well for us. We have a backup 
>> server that has some drives lvm'd together so we have huge storage 
>> capability. Then we have our boxes in the shop mount the respective 
>> shares exported from the backup server, and inside those respective 
>> shares are daily folders, so each box in the shop mounts it's respective 
>> share from the backup server and they then all have say /backup/Monday, 
>> /backup/Tuesday etc..
>> I then run crons on the respective boxes to backup to that share nightly 
>> of what is important on that box and to each daily folder for it's 
>> respective day, as the days repeat, they get overwritten, so this gives 
>> me 7 days of redundancy. I like that alot better than worrying about 
>> incremental backups, etc., and hard drive space is cheap today. So on my 
>> servers per say, I backup /etc /home and /var and have full dumps 
>> elsewhere in case of emergency for the rest.
>> I use dump to backup to these shares. I LOVE dump and it's counterpart 
>> restore. Restore has an interactive flag (-i) that lets you cruise 
>> through the dumps and find the data you might need, in the same 
>> directory tree that it backed up. I also limit my dumps to 1gb each, 
>> then they make another dump001, dump002, and the restore command can 
>> parse them all with one command.
>> The only thing that might stop someone from doing it this way is if they 
>> actually use acl's, as dump does not do acl's. Other than that, it works 
>> beautifully.
>>
>> _______________________________________________
>> nflug mailing list
>> nflug at nflug.org
>> http://www.nflug.org/mailman/listinfo/nflug
>>     
> _______________________________________________
> nflug mailing list
> nflug at nflug.org
> http://www.nflug.org/mailman/listinfo/nflug
>
>   
Wow, and that coming from Linus himself. I myself have never seen it
bork and get email confirmations verbosely of the data that does get
dumped nightly (if that really means anything as far as backup
validity). I could just change the commands to tar but really love the
restore interaction command. I also imagine that Linus is a complete
stickler for having things perfect and in the case of backups, anyone
should be. I worked for years with an NT Veritas tape backup solution
that continually reported all the backups fine only to actually find
NOTHING on the tapes! What a complete abortion that Veritas thing was
especially in the manner of interaction between the software and tape
drive. Anywho, thanks for the info, I will pay closer attention to my
backups from now on (as anyone should) ;)

_______________________________________________
nflug mailing list
nflug at nflug.org
http://www.nflug.org/mailman/listinfo/nflug