Dear Daniel, 

Thank you for your reply. Yes - you've described exactly what it is that
I'm trying to do. And you're right - I am probably over-thinking it!
Just want to be sure that what I think it happening actually is, if you
see what I mean. 

Anyway, thank you for your explanation. Between that and Colin's recent
mails, I think I understand things well enough now to go ahead.
Regards, 

John 

## 

On 21-03-2014 19:26, Daniel Staal wrote: 

> --As of March 21, 2014 3:13:58 PM +0000, John Gamble is alleged to have 
> said:
> 
>> Thanks again for your reply. Still slightly confused about this process 
>> though…. In the scenario I'm thinking about, 'backup-wednesday.part' and 
>> 'backup-thursday' wouldn't have any common files (or blocks of data). The 
>> complete archive would be the sum of 'backup-wednesday.part' and 
>> 'backup-thursday'. Therefore, how is it possible to delete 
>> 'backup-wednesday.part'? Is it, in fact, impossible to do so in this case? 
>> If so, is there any way to create a single complete backup/archive from two 
>> or more partial ones, that were formed by premature termination of a backup.
> 
> If there are truly no files in common, then deleting backup-wednsday.part 
> deletes all the files (or: data blocks containing files) in that backup. 
> But if that's the case, then the complete archive is *not* the sum of the 
> two: You have two separate archives.
> 
> What I think you want to do is back up a list of files, break up the 
> connection, then finish the backup of that list of files at another time. 
> Tarsnap can do this easily, as long as you don't overthink it. ;) In 
> particular, do *not* try to exclude the files that you have 'successfully' 
> backed up on Wednesday from the Thursday backup. Just let it back up 
> everything again; tarsnap will figure out what it has already sent and what 
> it hasn't, and handle things appropriately.
> 
> Tarsnap is designed to handle nicely the common backup situation where you 
> are backing up a large number of files on a regular basis, without caring 
> or knowing when they are changed. (Or created, or deleted.) You give it a 
> list of files and it backs up *what it hasn't backed up before* of that 
> list. Partials are just backups that didn't run to completion: They don't 
> have all the files they are supposed to, but other than that they are 
> normal archives. (There is no difference to *tarsnap* between a partial 
> and a full backup - it just names them as partials so that the *user* can 
> tell the difference.)
> 
> Another way to look at this (slightly inaccurate, but will probably help 
> understanding): The list of files in a backup is created at the start of 
> the backup process. Tarsnap turns that into a list of data blocks that it 
> has to save to the server. It then checks to see if it already has any of 
> those blocks on the server, and skips those, while sending the rest. A 
> partial backup is one where that didn't complete - but the blocks that it 
> has sent are still there. If you then create a new backup with the same 
> list of files, there will be more blocks tarsnap can skip sending. (But 
> note that the *list of files* is identical - tarsnap just didn't complete 
> sending them the first time.)
> 
>> I'm asking all this because given the speed of my upload connection, I know 
>> that I'll have to stop the initial backup before it completes. Just wanted 
>> to make sure that I'll ultimately be able to create a complete backup.
> 
> Yes, just keep creating the backup with the same list of files and let 
> tarsnap handle sending what data it needs to. (My initial upload of one of 
> my archives took over a month, and was broken up several times, but created 
> a complete archive in the end.)
> 
>> A couple of minor queries: 1). To terminate an ongoing backup, is the 
>> command ^Q?
> 
> That or ^C (SIGINT), or SIGQUIT will work, in my experience. ;)
> 
>> 2). While the backup is ongoing, is it OK to use the computer as normal?
> 
> Yes. Be aware that there will be a fair amount of IO going on, both disk 
> and network, but other than that you should have no problem.
> 
> If you are working with the files that you are backup, be aware that 
> tarsnap does not by default do a 'point in time' backup - it will backup 
> the file in the state it is in when it gets to it, even if it's been edited 
> since the backup started. (If it gets deleted, you'll get an error 
> message, but tarsnap will continue on.) If you need a point in time 
> backup, you'll have to look at filesystem snapshots. Most of the time you 
> don't, unless you are trying to back up an active database or something 
> like that.
> 
> Daniel T. Staal
> 
> ---------------------------------------------------------------
> This email copyright the author. Unless otherwise noted, you
> are expressly allowed to retransmit, quote, or otherwise use
> the contents for non-commercial purposes. This copyright will
> expire 5 years after the author's death, or in 30 years,
> whichever is longer, unless such a period is in excess of
> local copyright law.
> ---------------------------------------------------------------

 


-- 
 The Wellcome Trust Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE. 

Reply via email to