Re: Tarsnap died
On Wed, Mar 6, 2024, at 9:58 AM, Scott Wheeler wrote: > >> On Mar 6, 2024, at 07:10, tars...@sehe.nl wrote: >> >> >> I will remind you that calling a missing feature "insane" is not usually >> part of "reasonable customer feedback", so I might have been a little more >> curt in my response just to balance things out. There you go, > > I called it inane, not insane. If you want to quote me, my word was > “redonkulous”. ;-) I totally misread that! Sorry. To be completely frank, I'm not sure "inane" is much friendlier, but it sure wasn't my intention to accuse you of using an even unfriendlier word.
Re: Tarsnap died
Seems like there's a simple solution to this: I have a calendar item that pops up every month and reminds me to check my balance. When it gets low, I recharge it with enough to last me for anywhere from 3-12 months at a whack because sometimes I'm busy when the reminder pops up. It's worked pretty well for a long time now...and when it didn't, I have a reasonably configured mail system and I get several messages from Colin reminding me that I forgot for several months in a row. Failing all that, I'm pretty sure tarsnap will start failing backups, and if I'm a competent geek, I'm monitoring cron output for failures...especially when it deals with the ability to recover data in a disaster. If there was a way to store a card and recharge based on settings (maybe "When my account balance drops below $x, automatically charge $y to the card") I would probably use it...but I couldn't care less if it got implemented or not. -A On Thu, Mar 7, 2024 at 9:09 AM Michael Sierchio wrote: > > On Thu, Mar 7, 2024 at 11:55 AM Jeffrey Goldberg > wrote: > > >> ... I am extremely sympathetic to focusing on the core service instead of >> having to build, maintain, and protect systems that store secrets needed >> for payment. >> > > There is no need to store payment information. A token corresponding to a > user is all that's required for payment systems (of which there is a > multitude). Even enrollment doesn't require a merchant to capture or even > see credit card information. > > This is what most merchants do – focus on their core business and > outsource payment processing. > > One could argue that autopay is less disruptive and intrusive than having > an account deleted. > > – M >
Re: Tarsnap died
On Wed, Mar 6, 2024, at 4:03 AM, Scott Wheeler wrote: > >> To me the audience for Tarsnap is the privacy minded part of the public. >> Having payment details on file sort of contradicts the mission. That's (I'm >> guessing) why tarsnap is 100% pre-paid. >> >> You're free not to use it, or create your own process for regularly topping >> up the balance. Heck, you could even put $50 there and probably have a >> lifetime of storage (it's been a while since I used tarsnap, but back when >> it was /dirt cheap/ and I imagine storage costs have not increased >> significantly over time. > > You’re free to think that, but my company has spent thousands (perhaps over > $10k at this point?) on Tarsnap, so I don’t have a bad feeling saying, “I > love the service, but this part I find kind of dumb” is out of the range of > reasonable customer feedback. It’s reasonable to keep in mind that there > are different kinds of customers on this list, and that for some of us $50 is > not what we’re talking about. I suspect what pays Collin’s rent are the > customers that pay that much every month. > > -Scott I don't suspect there is much of a profit margin, but let's not argue things we hardly can know¹. I agree this is valid feedback. I also took it seriously by providing what I think is reasonable explanation. I will remind you that calling a missing feature "insane" is not usually part of "reasonable customer feedback", so I might have been a little more curt in my response just to balance things out. There you go, Peace ¹ I half-remember Colin writing about this many years ago but (a) I'm not searching for it (b) things may have changed over time
Re: Tarsnap died
On Mon, Mar 4, 2024, at 9:28 PM, Scott Wheeler wrote: > Tarsnap is the only important service we use with a billing system this inane > … and people have been complaining about it for at least a decade. To me the audience for Tarsnap is the privacy minded part of the public. Having payment details on file sort of contradicts the mission. That's (I'm guessing) why tarsnap is 100% pre-paid. You're free not to use it, or create your own process for regularly topping up the balance. Heck, you could even put $50 there and probably have a lifetime of storage (it's been a while since I used tarsnap, but back when it was /dirt cheap/ and I imagine storage costs have not increased significantly over time. Just my $0.02
Re: Invalidate tarsnap key?
Should have also alluded to... if you believe an untrusted source has a copy of your key then you should also disconnect the account from a credit card or quit paying on it so any data under that account expires and is wiped from the system at tarsnap given expiration. If you have other machines connected to that account then you should just regenerate keys for them and proceed onwards! -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Mar 17, 2022, at 10:39, J. Hellenthal wrote: > > Just nuke the key. Whatever way you have locally to permanently destroy all > existing data should be plenty enough. > > -- > > J. Hellenthal > > The fact that there's a highway to Hell but only a stairway to Heaven says a > lot about anticipated traffic volume. > > > > > > >> On Mar 17, 2022, at 10:17, Arthur Chance wrote: >> >> Is it possible to invalidate an existing tarsnap key so it cannot be >> used in future. I have a key for a decommissioned machine so it's no >> longer needed and hypothetically it could be used for DoS attack (by >> creating bogus archives and draining the account funds). Obviously this >> is impossible unless the key leaks somehow, but operational paranoia >> would suggest invalidating it would be a good idea. >> >> -- >> All network cabling aspires to the condition of macramé. >
Re: Invalidate tarsnap key?
Just nuke the key. Whatever way you have locally to permanently destroy all existing data should be plenty enough. -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Mar 17, 2022, at 10:17, Arthur Chance wrote: > > Is it possible to invalidate an existing tarsnap key so it cannot be > used in future. I have a key for a decommissioned machine so it's no > longer needed and hypothetically it could be used for DoS attack (by > creating bogus archives and draining the account funds). Obviously this > is impossible unless the key leaks somehow, but operational paranoia > would suggest invalidating it would be a good idea. > > -- > All network cabling aspires to the condition of macramé.
Re: Error message: Cannot store file: File already exists
Definitely related to the problem that seems to be a miscommunication or calculation on the cache directory itself. Personally I make it a habit to run an fsck before a backup just to be sure things like this don't happen and then if it does you still have the cache to explore when it does. -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Aug 31, 2021, at 11:48, Matthias Güdemann wrote: > > >> >> Have you attempted to --fsck ? > > I have now and it worked. Thanks for the hint! > Is this specific to this problem or generally a good idea to try first > in case of a problem? > > Best regards > Matthias
Re: Error message: Cannot store file: File already exists
Have you attempted to --fsck ? If not please do. -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Aug 31, 2021, at 07:49, matthias.guedem...@googlemail.com wrote: > > Hi tarsnap-users, > > since today I get the following error message when trying to add an > archive. > > tarsnap: Cannot store file: File already exists > tarsnap: Error storing chunk > 95245a29d9ca63d2f0d125dcaadd8f872f0352dc0c8c7dc27b37b43e490e42e7 > tarsnap: Error in chunk storage layer > tarsnap: Error writing archive > > I found an old thread with a similar sounding message here > > https://marc.info/?l=tarsnap-users=130997770031105 > > I am not aware that there was any corruption in the cache directory. > > Is there anything I can do to recover from this? > > Best regards > Matthias
Re: Speeding up slooooowwww extractions
Hi there!
Can you do the recovery in a VPS next to tarsnap location and then copy the
file to the final destination?
On Wed, May 26, 2021 at 10:39 AM hvjunk wrote:
>
>
> > On 26 May 2021, at 11:32 , hvjunk wrote:
> >
> > Good day,
> >
> > Is there any equivalent “aggressive-networking” settings for extractions?
> >
> > From OVH.com in FRance datacentre, it’s is excruciatingly slow to
> extract a 100GB file ;(
> >
> > Hendrik
>
> So as I’ve been watching this paint dry, I see the biggest culprit is the
> latency ;(
>
> Looking at a snippet of a strace on the tarsnap process (Linux Container),
> the time difference between the sendto and recvfrom is the “expected”
> ~200ms, which begs the question(s) about pipelining and bigger batch
> requests, as this test basically makes me seriously consider dropping the
> use of tarsnap for my European and South African servers as the recoveries
> are just hamstrung by the latency ;(
>
> So before I do other drastic options, (And yes, I’m reluctant as tarsnap
> does a great job and I’m impressed by it from a backup/etc. perspective)
> what other options is possible as I couldn’t find anything for restoring a
> 100GB file from a backups that will restore before next week Friday?
>
> 13:28:22.030563 recvfrom(3,
> "PA\30_e\224Y\317\177\205Ml|\343E\210\234\21F\22\253\374\244\206:4L\221\24]B\\"...,
> 49629, 0, NULL, NULL) = 49629
> 13:28:22.033582 select(4, [], [], NULL, {tv_sec=0, tv_usec=0}) = 0
> (Timeout)
> 13:28:22.035132 setsockopt(3, SOL_TCP, TCP_NODELAY, [0], 4) = 0
> 13:28:22.035360 setsockopt(3, SOL_TCP, TCP_CORK, [1], 4) = 0
> 13:28:22.035517 select(4, [], [3], NULL, {tv_sec=299, tv_usec=99}) = 1
> (out [3], left {tv_sec=299, tv_usec=97})
> 13:28:22.035727 sendto(3,
> "\222\7U\3520\31\211V\365\275\243\247<\343\262\362J*\234\364iE\222\342\326\351\267\236\207/__"...,
> 146, MSG_NOSIGNAL, NULL, 0) = 146
> 13:28:22.035950 setsockopt(3, SOL_TCP, TCP_CORK, [0], 4) = 0
> 13:28:22.036123 setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> 13:28:22.036174 select(4, [3], [], NULL, {tv_sec=0, tv_usec=0}) = 0
> (Timeout)
> 13:28:22.036220 select(4, [3], [], NULL, {tv_sec=59, tv_usec=52}) = 1
> (in [3], left {tv_sec=59, tv_usec=836643})
> 13:28:22.199620 recvfrom(3,
> "\313KW\231:\235\250\214\204\270\0\5\360fA33\f\212\242\210^\332\37\200\270c\264\306\25\330\256"...,
> 69, 0, NULL, NULL) = 69
> 13:28:22.199735 select(4, [3], [], NULL, {tv_sec=0, tv_usec=0}) = 1 (in
> [3], left {tv_sec=0, tv_usec=0})
> 13:28:22.199791 recvfrom(3,
> "mF\342\236\356\250\251\7<\312G\277\271\t=\3\267,z\355\264O\230\256u\265\37L^+\244n"...,
> 25936, 0, NULL, NULL) = 24547
> 13:28:22.199839 select(4, [3], [], NULL, {tv_sec=0, tv_usec=0}) = 0
> (Timeout)
> 13:28:22.199869 select(4, [3], [], NULL, {tv_sec=59, tv_usec=69}) = 1
> (in [3], left {tv_sec=59, tv_usec=916402})
> 13:28:22.283654 recvfrom(3,
> "0\374\17!\347\263U\377\16\376\2\200I5O\245\374\364\341|\270\367\277\"\374\257\270\25\341\205\3179"...,
> 1389, 0, NULL, NULL) = 1389
> 13:28:22.284533 select(4, [], [], NULL, {tv_sec=0, tv_usec=0}) = 0
> (Timeout)
> 13:28:22.284916 setsockopt(3, SOL_TCP, TCP_NODELAY, [0], 4) = 0
> 13:28:22.285129 setsockopt(3, SOL_TCP, TCP_CORK, [1], 4) = 0
> 13:28:22.285319 select(4, [], [3], NULL, {tv_sec=299, tv_usec=99}) = 1
> (out [3], left {tv_sec=299, tv_usec=97})
> 13:28:22.285378 sendto(3,
> "\226/\366\247Xk^\222U\375\t\364\27\275 146, MSG_NOSIGNAL, NULL, 0) = 146
> 13:28:22.285425 setsockopt(3, SOL_TCP, TCP_CORK, [0], 4) = 0
> 13:28:22.285520 setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> 13:28:22.285598 select(4, [3], [], NULL, {tv_sec=0, tv_usec=0}) = 0
> (Timeout)
> 13:28:22.285637 select(4, [3], [], NULL, {tv_sec=59, tv_usec=60}) = 1
> (in [3], left {tv_sec=59, tv_usec=846082})
> 13:28:22.450937 recvfrom(3,
> "\336}d\266P\357\210W\374?\334n\2175?\2522\260\354\33L\363\266\262r\324\323\332#\353T\315"...,
> 69, 0, NULL, NULL) = 69
> 13:28:22.451124 select(4, [3], [], NULL, {tv_sec=0, tv_usec=0}) = 1 (in
> [3], left {tv_sec=0, tv_usec=0})
> 13:28:22.451313 recvfrom(3,
> "tcEH\315\351L\346\207}\261\226\2(Z\300\330nr\212'\262\250\316\274\305\243\225\211\232x\25"...,
> 135563, 0, NULL, NULL) = 75227
> 13:28:22.451427 select(4, [3], [], NULL, {tv_sec=0, tv_usec=0}) = 0
> (Timeout)
> 13:28:22.451596 select(4, [3], [], NULL, {tv_sec=59, tv_usec=999832}) = 1
> (in [3], left {tv_sec=59, tv_usec=916654})
> 13:28:22.534931 recvfrom(3,
> "\30\10.\325\0372\23\6\250\325\251\366\272)\245a\317\243Xz;\213\305\26Y\326U\306g\367\\\16"...,
> 60336, 0, NULL, NULL) = 37648
> 13:28:22.535034 select(4,
Re: What all do I need to migrate tarsnap-gui setup to new MacBook?
Thank you for the detailed write up ! -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Apr 10, 2021, at 22:58, Amar via tarsnap-users > wrote: > > Hey all, > > I was able to do that. > > I decided to go the basic route as my data set isn’t huge and I had also lost > tarsnap.db by then (I copied it and then must have “misplaced" it - it was > 4am!). > > So what I did was that many of you suggested exactly: > > 1. Launched setup wizard, skipped it. > > 2. Then set everything one by one in each section of “Settings" tab: >Account: Added my Tarsnap a/c email, added a name for the new laptop, and > pointed to where I have put my old key (I keep it in Cryptomator Dropbox > folder) >Backup: This was pretty much filled up already just checked to ignore OS > garbage >Application: set client directory (/usr/local/bin - this is where brew > puts tarsnap on Mac), cache directory (I changed it to .cache/tarsnap as I > was going to recreate it anyway), left Download as it was, set App data dir > as ~/.config/tarsnap. > > 3. In applications tab clicked "Repair cache”. It took some time but all was > good in the end. Added cache, checked all the archives and ended successfully. > > 4. Went to “Jobs” tab and added the missing Job (I guess if I had preserved > tarsnap.db it would have been populated automatically). Anyway I took this > opportunity to combine two of my previous jobs into one. I save the same set > of data via other methods as well so I knew what to select for backup. This > time I selected ~/.config/tarsnap/tarsnap.db as well (maybe I will add cache > files “directory” and “cache” as well later or in some other backup). (I will > also consider pruning old archives - in a way all the files ever backed are > preserved i.e. out of e.g. 200 archives if I can have last 7 + min number of > archives post that that has all my data ever backed up) > > 5. Then enabled scheduling. Moved the generated .plist file to a folder in > Dropbox where I keep all my launch agents and then symlinked it. I also > changed the time of it (I guess later I will change it to run multiple times > a day). It'd be a nice tarsnap-gui feature though. > > 6. Hit backup and it was done. 170kB new data was added. > > Thank you all :) > >> On 10-Apr-2021, at 11:04 PM, Graham Percival wrote: >> >> Hi Amar, >> >> Yes, it's correct that the gui does not need the password if you already have >> a keyfile. >> >> Behind the scenes, the "verifying archive integrity" step is running >> `tarsnap --fsck` to download archive metadata. That's approximately 0.1% of >> the total archive size: >> https://www.tarsnap.com/multiple-machines.html >> You can avoid this if you copy the cache directory from your old laptop to >> your new one. (as mentioned on that link) >> >> Alternatively, you could skip over the setup wizard. You have two options >> here: >> 1) launch the setup wizard, then click on "skip wizard", then set up options >> in the Settings tab. >> 2) copy your old tarsnap.db to the same location on the new laptop. Then >> when >> you launch tarsnap-gui, it should have the same options as you had on the old >> machine. >> >> The gui will probably prompt you to repair the cache; if it doesn't, then go >> to Settings->Application->"Repair cache". This will run the same `tarsnap >> --fsck` operation, but this time you can see some progress messages clicking >> on the bottom-left triangle. For example, I get: >> >> [2021-04-10 10:20 A.M.] Cache repair initiated. >> [2021-04-10 10:20 A.M.] Cache repair succeeded. >> [2021-04-10 10:20 A.M.] Updating archives list from remote... >> [2021-04-10 10:20 A.M.] Updating archives list from remote... done. >> [2021-04-10 10:20 A.M.] Fetching stats for archive xyz... >> >> (Or, if you want to see the full information, use the "console log" option.) >> >> In your case, I suspect that you have many archives so it's spending a lot of >> time on this step. >> >> I've added two issues: showing progress in the setupwizard, and adding an >> import / export functionality: >> https://github.com/Tarsnap/tarsnap-gui/issues/550 >> https://github.com/Tarsnap/tarsnap-gui/issues/549 >> >> Cheers, >> - Graham >> >>> On Sat, Apr 10, 2021 at 10:51:36AM +0530, Amar via tarsnap-users wrote: >>> I thought it’d be straightforward but I am stuck. I am sure I am doing
Re: What all do I need to migrate tarsnap-gui setup to new MacBook?
Hey all, I was able to do that. I decided to go the basic route as my data set isn’t huge and I had also lost tarsnap.db by then (I copied it and then must have “misplaced" it - it was 4am!). So what I did was that many of you suggested exactly: 1. Launched setup wizard, skipped it. 2. Then set everything one by one in each section of “Settings" tab: Account: Added my Tarsnap a/c email, added a name for the new laptop, and pointed to where I have put my old key (I keep it in Cryptomator Dropbox folder) Backup: This was pretty much filled up already just checked to ignore OS garbage Application: set client directory (/usr/local/bin - this is where brew puts tarsnap on Mac), cache directory (I changed it to .cache/tarsnap as I was going to recreate it anyway), left Download as it was, set App data dir as ~/.config/tarsnap. 3. In applications tab clicked "Repair cache”. It took some time but all was good in the end. Added cache, checked all the archives and ended successfully. 4. Went to “Jobs” tab and added the missing Job (I guess if I had preserved tarsnap.db it would have been populated automatically). Anyway I took this opportunity to combine two of my previous jobs into one. I save the same set of data via other methods as well so I knew what to select for backup. This time I selected ~/.config/tarsnap/tarsnap.db as well (maybe I will add cache files “directory” and “cache” as well later or in some other backup). (I will also consider pruning old archives - in a way all the files ever backed are preserved i.e. out of e.g. 200 archives if I can have last 7 + min number of archives post that that has all my data ever backed up) 5. Then enabled scheduling. Moved the generated .plist file to a folder in Dropbox where I keep all my launch agents and then symlinked it. I also changed the time of it (I guess later I will change it to run multiple times a day). It'd be a nice tarsnap-gui feature though. 6. Hit backup and it was done. 170kB new data was added. Thank you all :) > On 10-Apr-2021, at 11:04 PM, Graham Percival wrote: > > Hi Amar, > > Yes, it's correct that the gui does not need the password if you already have > a keyfile. > > Behind the scenes, the "verifying archive integrity" step is running > `tarsnap --fsck` to download archive metadata. That's approximately 0.1% of > the total archive size: > https://www.tarsnap.com/multiple-machines.html > You can avoid this if you copy the cache directory from your old laptop to > your new one. (as mentioned on that link) > > Alternatively, you could skip over the setup wizard. You have two options > here: > 1) launch the setup wizard, then click on "skip wizard", then set up options > in the Settings tab. > 2) copy your old tarsnap.db to the same location on the new laptop. Then when > you launch tarsnap-gui, it should have the same options as you had on the old > machine. > > The gui will probably prompt you to repair the cache; if it doesn't, then go > to Settings->Application->"Repair cache". This will run the same `tarsnap > --fsck` operation, but this time you can see some progress messages clicking > on the bottom-left triangle. For example, I get: > > [2021-04-10 10:20 A.M.] Cache repair initiated. > [2021-04-10 10:20 A.M.] Cache repair succeeded. > [2021-04-10 10:20 A.M.] Updating archives list from remote... > [2021-04-10 10:20 A.M.] Updating archives list from remote... done. > [2021-04-10 10:20 A.M.] Fetching stats for archive xyz... > > (Or, if you want to see the full information, use the "console log" option.) > > In your case, I suspect that you have many archives so it's spending a lot of > time on this step. > > I've added two issues: showing progress in the setupwizard, and adding an > import / export functionality: > https://github.com/Tarsnap/tarsnap-gui/issues/550 > https://github.com/Tarsnap/tarsnap-gui/issues/549 > > Cheers, > - Graham > > On Sat, Apr 10, 2021 at 10:51:36AM +0530, Amar via tarsnap-users wrote: >> I thought it’d be straightforward but I am stuck. I am sure I am doing >> something wrong I just don’t know what. >> >> I have to return my work laptop today and that’s where I had setup >> Tarsnap-GUI and have been using. >> >> I have saved the key file, I also have the tarsnap.db file. I of course have >> the tarsnap.com <http://tarsnap.com/> a/c password. >> I will have same sets of data on my new laptop as well (I have already >> migrated local/laptop data to new one). >> >> I want to just start backing up to the same remote with deduplication (from >> previously backed up data from previous laptop and all that) and all that. >> >> I
Re: What all do I need to migrate tarsnap-gui setup to new MacBook?
With everything in place on the new machine as was on the old one be sure the cachedir exists and your config file is being read, then run tarsnap —fsck. Once that completes you should be able to —list-archives Lmk -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Apr 10, 2021, at 00:22, Amar via tarsnap-users > wrote: > > I thought it’d be straightforward but I am stuck. I am sure I am doing > something wrong I just don’t know what. > > I have to return my work laptop today and that’s where I had setup > Tarsnap-GUI and have been using. > > I have saved the key file, I also have the tarsnap.db file. I of course have > the tarsnap.com a/c password. > I will have same sets of data on my new laptop as well (I have already > migrated local/laptop data to new one). > > I want to just start backing up to the same remote with deduplication (from > previously backed up data from previous laptop and all that) and all that. > > I had installed via “brew install tarsnap-gui” and it installed tarsnap > 1.0.39_1 (I didn’t install tarsnap separately) > > When I run setup wizard it tries to verify archive integrity just based on > the key, without even asking for my password. So I guess that should be fine > as my key was generated > with my email and a/c password. But can I just use it on new machine? There’s > nothing there yet - not even my jobs, or config yet? > > So on 3rd step of setup wizard it’s perpetually stuck on “Verifying archive > integrity”. > The Config directory (from step 2) is empty which makes sense as I have not > imported or added any jobs etc. Should I copy paste tarsnap.db from previous > machine (in App Data Directory). > > Is there something I am missing?
Re: What all do I need to migrate tarsnap-gui setup to new MacBook?
With everything in place on the new machine as was on the old one be sure the cachedir exists and your config file is being read, then run tarsnap —fsck. Once that completes you should be able to —list-archives Lmk -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Apr 10, 2021, at 00:22, Amar via tarsnap-users > wrote: > > I thought it’d be straightforward but I am stuck. I am sure I am doing > something wrong I just don’t know what. > > I have to return my work laptop today and that’s where I had setup > Tarsnap-GUI and have been using. > > I have saved the key file, I also have the tarsnap.db file. I of course have > the tarsnap.com a/c password. > I will have same sets of data on my new laptop as well (I have already > migrated local/laptop data to new one). > > I want to just start backing up to the same remote with deduplication (from > previously backed up data from previous laptop and all that) and all that. > > I had installed via “brew install tarsnap-gui” and it installed tarsnap > 1.0.39_1 (I didn’t install tarsnap separately) > > When I run setup wizard it tries to verify archive integrity just based on > the key, without even asking for my password. So I guess that should be fine > as my key was generated > with my email and a/c password. But can I just use it on new machine? There’s > nothing there yet - not even my jobs, or config yet? > > So on 3rd step of setup wizard it’s perpetually stuck on “Verifying archive > integrity”. > The Config directory (from step 2) is empty which makes sense as I have not > imported or added any jobs etc. Should I copy paste tarsnap.db from previous > machine (in App Data Directory). > > Is there something I am missing?
What all do I need to migrate tarsnap-gui setup to new MacBook?
I thought it’d be straightforward but I am stuck. I am sure I am doing something wrong I just don’t know what. I have to return my work laptop today and that’s where I had setup Tarsnap-GUI and have been using. I have saved the key file, I also have the tarsnap.db file. I of course have the tarsnap.com <http://tarsnap.com/> a/c password. I will have same sets of data on my new laptop as well (I have already migrated local/laptop data to new one). I want to just start backing up to the same remote with deduplication (from previously backed up data from previous laptop and all that) and all that. I had installed via “brew install tarsnap-gui” and it installed tarsnap 1.0.39_1 (I didn’t install tarsnap separately) When I run setup wizard it tries to verify archive integrity just based on the key, without even asking for my password. So I guess that should be fine as my key was generated with my email and a/c password. But can I just use it on new machine? There’s nothing there yet - not even my jobs, or config yet? So on 3rd step of setup wizard it’s perpetually stuck on “Verifying archive integrity”. The Config directory (from step 2) is empty which makes sense as I have not imported or added any jobs etc. Should I copy paste tarsnap.db from previous machine (in App Data Directory). Is there something I am missing?
Re: Planning for Emergency restore
> Depends on the factos etc. a safe at a bank isn’t a bad option to consider. Safe deposit boxes aren't safe. https://www.nytimes.com/2019/07/19/business/safe-deposit-box-theft.html On Sun, Apr 4, 2021, at 12:43, hvjunk wrote: > Storing the keys in your password store like BitWarden > > > On 04 Apr 2021, at 19:37 , jerry wrote: > > > > With a complete tarsnap backup, I could restore everything... but the big > > bad trojan might have encrypted the filesystem with my tarsnap key! > > What about you password manager as a storage? (Ie. Bitwarden is what I > use, and I share those keys with the needed people that needs to get > access in my absence) > > > Even though it's not a Samba share, and the directory is only readable by > > root, and the file is only readable/writable by root. Actually, why > > should it be writable at all? I'd never change it. "sudo chmod u-w > > tarsnap.key”. > > you could try the immutable flag too, but the assumption here is the > ransomware got the needed root privileges to clear that flag too. > > > Anyway, in that situation, the tarsnap key becomes VERY valuable. I > > suppose I could stick it on some encrypted media and keep it somewhere > > else. Friend's house? What if my house burns down? A disk in the fire > > safe would probably get fried, but what about a piece of paper? > > Depends on the factos etc. a safe at a bank isn’t a bad option to consider. > > >
Re: Getting logged out of tarsnap website when paying with credit card
Try any other browser ? -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Mar 14, 2021, at 17:21, Daniel Staal wrote: > > On 3/14/21 10:20 AM, hvjunk wrote: >> Had the same this week when I made a USD50 payment. I*think* I first tried >> with an Amex, had this problem and then I just retried with a MasterCard… >> suspecting the Amex to be the problem. > > Just to say I did *not* have this issue with an Amex payment just over a week > ago. So if it's Amex, it's not just Amex. > > Browser was Firefox for Mac. > > 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. > ---
Re: EU / "custom" AWS zones? (POPI (ZA) and GDPR requirements related)
On Sun, Mar 14, 2021 at 9:50 AM Colin Percival wrote: > The short answer here is "Tarsnap is a technical solution to a technical > problem". Political problems are out of scope. (And in many countries, > "local government decides to outlaw crypto" is a much bigger danger than > "USA decides to partition the internet".) > Time to get AWS to create a "Principality of Sealand" region then? ;) -A
Re: Tarsnap de-dup - one machine or all?
If you are using the same key from the previous machine then they may be de-duped as the commmand you are running has access to the previous archives. Each key is unique in a way that it should never have access to another machines data. Make sense ? On Thu, Sep 17, 2020 at 08:50:13AM +0100, Arthur Chance wrote: > Does tarsnap's de-dup work on one machine at a time or across all > machines in an account? > > The reason I ask is because I've moved a largish mail archive from one > machine to another and am unsure whether the backup on the new machine > will reuse the blocks from the old one, or whether I'll end up using > double the space. > > -- > The number of people predicting the demise of Moore's Law doubles > every 18 months. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. signature.asc Description: PGP signature
Re: Pass password via environment variable
Hi Graham! Thanks for that! Any idea when the next Tarsnap client will be released? Thanks. On Mon, Aug 31, 2020 at 2:05 PM Graham Percival wrote: > Hi Mauro, > > Not in the latest official tarball, 1.0.39. The NEWS.md file in > the git repository does list a new --passphrase-stdin option [1], > which could be used with an environment var [2]. > > It might be worth mentioning that scrypt 1.3.1 (released last week > [3]) added a host of new password entry methods, including > --passphrase env:VARNAME > > [1] https://github.com/Tarsnap/tarsnap/blob/master/NEWS.md > [2] something like `echo $VARNAME | tarsnap ...` > [3] http://mail.tarsnap.com/scrypt/msg00268.html > > Cheers, > - Graham > > On Mon, Aug 31, 2020 at 11:04:25AM -0300, Mauro Ciancio via tarsnap-users > wrote: > > Hi there! > > I couldn't find any hints by looking into the manual. > > Is there any way to pass a key password via an environment variable? > > Thanks! >
Pass password via environment variable
Hi there! I couldn't find any hints by looking into the manual. Is there any way to pass a key password via an environment variable? Thanks!
Re: https://www.tarsnap.com/faq.html#out-of-money
Hi Graham, Does that monthly report also has the information — how many days worth of balance is left? And yes, I would want to receive that. What should I do for that? Shall I wait for FAQ update, or you could share the steps here please? Amar > On 4 Aug 20, at 10:32 PM, Graham Percival wrote: > > Hi Amar, > > I can't comment about any change to finances, but if it would > help, you can ask to receive a monthly summary of your account > (charges and balance). We are required to send these to Canadians > for tax reasons, and non-Canadians can get them too. > > This info should have been in our FAQ, so I'm adding it now. > > Cheers, > - Graham Percival > > On Tue, Aug 04, 2020 at 11:34:59AM +0530, Amar via tarsnap-users wrote: >> Can we add (maybe) a 30 days and another 15 days warning along with the >> existing 7 days warning? >> Before the "possible deletion" timer starts which is again. >> >> Or at least one 30/15 days warning other than the existing 7 days? >> >> Right now there’s just one 7 days advance warning (I am not counting the >> starting of “possible deletion” countdown as advance warning). I can imagine >> many scenarios in which I could miss both and very low chances of missing a >> 15/30 days warning (this can be different for others though) >> >> Or giving users an option to be warned by two or one emails when the balance >> falls below X days worth of cost instead of fixing that warning at 7 days. >> >> Or some kind of option for the data not get deleted within/around 7 days. >> Maybe keep some money in buffer (optional maybe)?
https://www.tarsnap.com/faq.html#out-of-money
Can we add (maybe) a 30 days and another 15 days warning along with the existing 7 days warning? Before the "possible deletion" timer starts which is again. Or at least one 30/15 days warning other than the existing 7 days? Right now there’s just one 7 days advance warning (I am not counting the starting of “possible deletion” countdown as advance warning). I can imagine many scenarios in which I could miss both and very low chances of missing a 15/30 days warning (this can be different for others though) Or giving users an option to be warned by two or one emails when the balance falls below X days worth of cost instead of fixing that warning at 7 days. Or some kind of option for the data not get deleted within/around 7 days. Maybe keep some money in buffer (optional maybe)?
Re: A caution for macOS users
Good thing for a dry run option |egrep for your include and exclude patterns -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Jul 11, 2020, at 18:30, Brian L. Matthews wrote: > smime.p7s Description: S/MIME cryptographic signature
temp files
Hi, I am curious about the implementation details moving data though tarsnap. I realize that I can dig through the source code but it was a bit obtuse when I looked. I didn't see an answer to my question in the tips, faq, technical details, etc. Does tarsnap write data to disk as it creates and encrypts chunks? If so, where? If not, does it stream the chunks directly to the backup servers? In this scenario I'd guess that data moves from disk through ram then across the network. thank you, JT
Re: Turn Tarsnap key into mnemonic phrase
> The tarsnap.key would not be a *short* mnemonic phrase Ah I didn't think of that. It looks like Bitcoin's BIP39 requires 12 words to store a 128-bit key, so 192 words for Tarsnap's key would make it a bit pointless. > IMO, it is easier to (securely) backup the actual tarsnap.key file. > Use multiple media types per best practice for any important backup. I'll stick to doing this. Thanks again for the advice, Matthew.
Turn Tarsnap key into mnemonic phrase
Hi, Many Bitcoin wallets support encoding your wallet's private key into a short mnemonic phrase that can be written down on paper. Does anyone know of a tool that I can use to encode my Tarsnap private key so that it too can be easily written down on paper? Thanks, Matthew.
Re: Changina my account e-mail
"Should I just contact Colin Percival for such a thing?" I think you just did. Quoting Andrea Biscuola : Hi list! I have a problem and, maybe, you can point me to the right direction. I was migratig a bunch of account to a new e-mail address, but I forgot to migrate my tarsnap account before deleting the old e-mail and now, it's gone. Of course the tarsnap account itself still work, so, no immediate problems, but I didn't found, on the tarsnap documentation, a way for changing the account's e-mail. Should I just contact Colin Percival for such a thing? Regards and thanks in advance. -- Andrea
Re: tarsnap-keygen: Error registering with server (too many network failures)
On Thu, 14 Apr 2016 21:23:06 +0100 John <j...@commonpeople.uk> wrote: > On 04/14/2016 03:43 PM, John Noll wrote: > > Greetings: > > I am having difficulty generating a key using tarsnap-keygen: > > > A google search came up with one suggestion that port 9279 needs to > > be opened for outgoing traffic, so I tried using ufw to achieve > > this: > > 1. You could test whether your firewall is the issue by disabling it > entirely, That is a bad advise in general, and a very bad advise for a 'truly paranoid' who is using tarsnap for a good reason. I most seriously advise against doing this as it could set you back to the safety level of Dropbox and the likes. My advise would be to read the firewall rules and check that way whether or not the tarsnap servers are blocked or not. joe > trying tarsnap-keygen again, and then enabling once you > know the answer. > > sudo ufw disable > sudo ./tarsnap-keygen [etc...] > sudo ufw enable > > 2. Is there another firewall between your computer and the world? > Even on my home network there's a firewall on my router. > > John Harris > Information Processing Officer > The Common People
resume after network interruption
Hi all, I repeatedly run into the following problem when my network seems to fail: [user@important_documents]$ sudo tarsnap -cvf important_document.doc important_document.doc Please enter passphrase for keyfile /usr/local/tarsnap/videos.key: tarsnap: Creating checkpoint... done. tarsnap: Creating checkpoint... done. tarsnap: Creating checkpoint... done. tarsnap: Creating checkpoint... done. tarsnap: Creating checkpoint...tarsnap: Too many network failures [user@important_documents]$ sudo tarsnap -cvf important_document.doc important_document.doc tarsnap: An archive already exists with the name important_document.part tarsnap: Error creating new archive [user@important_documents]$ To solve this problem I have to give the following commands: sudo tarsnap -cvf important_document.doc2 important_document.doc Assuming this completed successfully I have then to remove the .part sudo tarsnap -dvf important_document.doc.part Then re-archive the original document with the intended file name sudo tarsnap -cvf important_document.doc important_document.doc and remove the old archive with the adapted name. sudo tarsnap -dvf important_document.doc2 This is a lot of work for me as this occurs quite often with my network. Isn't there some way to either make tarsnap really persistently (I already got a patch that removed a lot of the network failures) trying to complete archiving the file, or to have tarsnap recognise that if there is already some incomplete part, that it would be wise and nice to start with that one and complete the upload? Thanks
Re: splitting key across machines
On Tue, 6 May 2014 17:35:00 -0700 The Farmer are.you.the.far...@gmail.com wrote: If I use tarsnap-keymgmt to create a key that can only create new archives, and another key that can list and delete old ones, and want to use them from different machines, what's the best way to do that? I don't want an attacker who gains access to the machine I'm backing up to be able to delete old backups, but I don't want to keep old backups indefinitely, so my plan is to delete old backups from a different machine. I'm guessing the best plan is to use rsync to keep the cache folders in sync on the two machines, but do they need to be synced in both directions, or is it enough to copy from the machine which creates archives to the one which deletes them? If it needs to go both ways then I guess I also need to put some kind of semaphore in place to make sure only one machine is using tarsnap at a time. Wouldn't it be easier to store those keys on a USB stick and point tarsnap to it when needed?
tarsnap.conf ^Q
I have 2 issues remaining that keep puzzling me, maybe someone can point out what I'm doing wrong? 1. If I make a backup ( sudo tarsnap -cpf archive-name file-to-backup ) it doesn't find the file /usr/local/etc/tarsnap.conf without being directed to it through the --configfile option. 2. Terminating a running backup through ^Q, seeing it finish cleanly, and then repeating the same backup command later, gives me a quote An archive already exists with the name archive-name.part tarsnap: Error creating new archive /quote Which surprises me, because it's documented as being supposed not to do this. Any hints? Thanks
Re: tarsnap.conf ^Q
On Sun, 06 Apr 2014 17:29:19 -0700 Colin Percival cperc...@tarsnap.com wrote: On 04/06/14 09:42, tarsnap wrote: I have 2 issues remaining that keep puzzling me, maybe someone can point out what I'm doing wrong? 1. If I make a backup ( sudo tarsnap -cpf archive-name file-to-backup ) it doesn't find the file /usr/local/etc/tarsnap.conf without being directed to it through the --configfile option. That's odd. What OS are you running and how did you install Tarsnap? It may be that tarsnap is looking in a different directory. Tarsnap is installed in a template VM of Qubes-OS. Now after a reply by 'Tim Bishop', I found that the tarsnap.conf.sample was located in /usr/etc/, so I will try to see what happens when I put the .conf in there. 2. Terminating a running backup through ^Q, seeing it finish cleanly, and then repeating the same backup command later, gives me a quote An archive already exists with the name archive-name.part tarsnap: Error creating new archive /quote Which surprises me, because it's documented as being supposed not to do this. This looks correct to me. The first archive was truncated thanks to you hitting ^Q, so it had .part added to its name. Yes, but wasn't it supposed to continue with building the archive upon re-issuing the backup command? As a side-note (see also another added post here) I must add that it does not seem to exit totally cleanly, as the exit messages are: tarsnap: Archive truncated tarsnap: Error exit delayed from previous errors. Could it be that the second message gives some indication that re-issuing the same backup command won't work? thanks
feature request
As my internet connection is far from optimal -- to put it mildly -- and power outages also frequently occur with a duration that even a UPS equipped with a 12V, 65Ah car battery can't cope with, some kind of 'continue where left off' for the -x option for single large file recoveries would be *extremely* attractive in this kind of situation. thanks P.S. My humble apologies if (again) I didn't read the manual carefully enough... :)
recent price reductions
Looking with a bit of anticipation at: http://www.windowsazure.com/en-us/pricing/details/storage/ :)
additional security (II)
If I understand tarsnap from previous posts correctly, there seem to be various keys, e.g. for sending data, for deleting data, for listing data. Coming back to my previous suggestion to bring the security level more in accordance with the philosophy adhered to by the Qubes-OS designers at qubes-os.org, i.e.: 'do not leave your secret passphrases/-words on a net-connected computer of VM', I would suggest to look into the possibility of a command line option which would allow users to paste the required part of the key file in the terminal when needed. If that would be possible, I could store my keyfile (or -files, as I think them keys would preferably be stored in separate files) on a 'Vault-VM' which has no physical connection to the internet as it is 'perfectly isolated' using Intel's VT-d and VT-x processor features and thanks to Qubes-OS's design (and hopefully implementation). Then, when invoking tarsnap with the --paste-keys (or whatever) option, I could be queried for the appropriate key (for writing, reading, deleting) whenever needed and copy/paste it from the Vault-VM into the VM's terminal running tarsnap at that moment. The (part of the) keyfile would then only reside in RAM during the time that tarsnap is running (and does it really need to stay there all the time?), making it more difficult for hackers to catch it. Impossible? Or even nonsense talk? I'm not such a 'code reader' that I can easily find this myself in 'the source code', and maybe someone has enough knowledge of the inner workings to find it easy to answer this question. And please, after Snowden's publications, don't call me 'truly paranoid' anymore. 'Truly realistic' would be more appropriate ;-) .
Re: additional security (II)
On Mon, 31 Mar 2014 10:32:28 +0200 Andreas Olsson andr...@arrakis.se wrote: mån 2014-03-31 klockan 08:05 + skrev tarsnap: ... The (part of the) keyfile would then only reside in RAM during the time that tarsnap is running (and does it really need to stay there all the time?), making it more difficult for hackers to catch it. Couldn't you just as easily solve that part yourself by at the backup moment copy your tarsnap key to a tmpfs mount? To be on the safe side it probably wouldn't hurt to disable swap, or go with an encrypted swap. // Andreas Yes I could even copy it to tarsnap's regular keyfile directory on the VM of which I'm managing the backup and remove it afterwards, but what I was aiming at was to not at all have it on any file system (or am I technically wrong in that RAM is a file system also?) that is part of a net-connected VM. You are right though that having it temporarily on a net-connected file system will lower the exposure but I really would like to go that one step further, if possible. thanks
Re: additional security (II)
On Mon, 31 Mar 2014 12:08:45 +0200 Arnt Gulbrandsen a...@gulbrandsen.priv.no wrote: Why? Tarsnap makes it hard to store nothing, but easy to store just a key that allow only making backups. So if the NSA breaches your computer, they can learn enough to make backups in your name. They cannot read your existing backups (or even the backups they made). It leaves you open to a DoS, I suppose. An attacker can spend your money. Arnt This is new to me. Is the same keyfile not also used to restore (i.e. read) my backups? In that case I think 'our friends' (NSA and such) do have a way of reading my backups, or am I wrong? Or do you mean that I can separate the restore key from the keyfile and store it somewhere else for later use? That would be a solution too. But I've tried to read the keyfile, and all I saw was one sequence of ASCII characters, no separate sections. Or is that because I didn't do any restore yet? I must admit, I do not really know a lot of the inner workings of tarsnap, so please forgive me if I'm talking nonsense (again?). thanks
Re: About network failures while uploading
On Sat, 8 Mar 2014 16:06:15 +
Colin Percival cperc...@tarsnap.com wrote:
On 03/08/14 07:24, tarsnap wrote:
On Sat, 8 Mar 2014 14:41:50 +
Colin Percival cperc...@tarsnap.com wrote:
I'd recommend using the --checkpoint-bytes option with a fairly low
setting (e.g., --checkpoint-bytes 32M) so that you'll have lots of
checkpoints created. That way when an archive fails you'll still
have the first section of the archive stored -- and that data can
then be used for deduplication purposes when you create another
archive, which will make future archives use less bandwidth and
complete faster.
Thanks for your reply.
So I have to do 2 things:
1) add the checkpoints option
2) create another (NOT the same) archive?
You can try creating an archive with the same name as you used
before. If it fails, that means the previous archive got created
successfully.
Of course, finding an internet connection which doesn't break for 5
minutes at a time would be ideal. (5 minutes is how long tarsnap
will keep on trying to reconnect.)
The internet connection breaks down when the power goes out, which
happens quite frequently: 2 times a day for 2 hours each.
The laptop runs longer than 5 minutes on its own battery, which
means tarsnap will always 'give up'.
Which brings me to the following feature request:
A command line option to set the
'retry time' (from 5 min. to inf., and frequency--if not automatic
as function of 'retry time').
The attached patch adds a completely untested and undocumented
--retry-forever option. Let me know if it works and is useful. :-)
I'm afraid something went wrong, any idea what it is?
Beow follows:
1) tarsnap version
2) CLI
3) netpacket_op.c.rej
tnx
1)
$ tarsnap --version
tarsnap 1.0.35
2)
[user@fedora-18-x64-use netpacket]$ patch netpacket_op.c
tarsnap_retryforever.patch
patching file netpacket_op.c
patching file netpacket_op.c
Hunk #1 FAILED at 469.
Hunk #2 FAILED at 531.
Hunk #3 FAILED at 1466.
Hunk #4 FAILED at 1495.
4 out of 4 hunks FAILED -- saving rejects to file netpacket_op.c.rej
patching file netpacket_op.c
Hunk #1 FAILED at 105.
Hunk #2 FAILED at 199.
Hunk #3 FAILED at 214.
3 out of 3 hunks FAILED -- saving rejects to file netpacket_op.c.rej
patching file netpacket_op.c
Hunk #1 FAILED at 130.
Hunk #2 FAILED at 144.
2 out of 2 hunks FAILED -- saving rejects to file netpacket_op.c.rej
patching file netpacket_op.c
Hunk #1 FAILED at 4.
1 out of 1 hunk FAILED -- saving rejects to file netpacket_op.c.rej
[user@fedora-18-x64-use netpacket]$
3)
--- bsdtar.c2014-02-17 01:37:46.0 -0800
+++ bsdtar.c2014-03-08 07:58:45.0 -0800
@@ -469,6 +469,9 @@
case OPTION_NO_QUIET:
optq_push(bsdtar, no-quiet, NULL);
break;
+ case OPTION_NO_RETRY_FOREVER:
+ optq_push(bsdtar, no-retry-forever, NULL);
+ break;
case OPTION_NO_SAME_OWNER: /* GNU tar */
bsdtar-extract_flags =
~ARCHIVE_EXTRACT_OWNER; break;
@@ -531,6 +534,9 @@
case OPTION_RECOVER:
set_mode(bsdtar, opt, --recover);
break;
+ case OPTION_RETRY_FOREVER:
+ optq_push(bsdtar, retry-forever, NULL);
+ break;
case OPTION_SNAPTIME: /* multitar */
optq_push(bsdtar, snaptime, bsdtar-optarg);
break;
@@ -1466,6 +1472,11 @@
goto optset;
bsdtar-option_quiet_set = 1;
+ } else if (strcmp(conf_opt, no-retry-forever) == 0) {
+ if (bsdtar-option_retry_forever_set)
+ goto optset;
+
+ bsdtar-option_retry_forever_set = 1;
} else if (strcmp(conf_opt, no-snaptime) == 0) {
if (bsdtar-option_snaptime_set)
goto optset;
@@ -1495,6 +1506,12 @@
bsdtar-option_quiet = 1;
bsdtar-option_quiet_set = 1;
+ } else if (strcmp(conf_opt, retry-forever) == 0) {
+ if (bsdtar-option_retry_forever_set)
+ goto optset;
+
+ tarsnap_opt_retry_forever = 1;
+ bsdtar-option_retry_forever_set = 1;
} else if (strcmp(conf_opt, snaptime) == 0) {
if (bsdtar-mode != 'c')
goto badmode;
--- bsdtar.h2014-02-17 01:37:46.0 -0800
+++ bsdtar.h2014-03-08 07:54:57.0 -0800
@@ -105,6 +105,7 @@
int option_no_config_include_set;
int option_quiet;
int option_quiet_set;
+ int option_retry_forever_set;
int option_insane_filesystems;
int option_insane_filesystems_set;
const char **configfiles; /*
--configfile
(solved) Re: About network failures while uploading
On Sun, 9 Mar 2014 16:22:57 + Colin Percival cperc...@tarsnap.com wrote: On 03/09/14 09:21, tarsnap wrote: On Sun, 9 Mar 2014 15:36:28 + Colin Percival cperc...@tarsnap.com wrote: On 03/09/14 06:57, tarsnap wrote: I'm afraid something went wrong, any idea what it is? [user@fedora-18-x64-use netpacket]$ patch netpacket_op.c tarsnap_retryforever.patch ^^^ this command line should have been just $ patch tarsnap_retryforever.patch since the patch modifies several different files, not just netpacket_op.c Ok, and the directory from where I issued the command, was at least that one correct? Oh, I didn't notice that. No, you need to run the command from the main tarsnap source code directory. Ok, so I did, and it kept asking for file locations, so I just pointed to the respective files to be patched. It compiled ok and started running ok. I disconnected the network and let it sit for 10 minutes (more than the 5 minutes you indicated earlier that it would try), spewing out its complaints and after reconnecting the network it re-established connection. In short: it works. thanks, (Sorry for asking, this is my first patch work.)
Re: About network failures while uploading
On Sat, 8 Mar 2014 14:41:50 + Colin Percival cperc...@tarsnap.com wrote: On 03/08/14 06:29, tarsnap wrote: Continuing a thread from Jul 2011, I would like to know if in case of backing up 1 file (1 GB) and tarsnap quitting due to 'Too many network failures', parts of the file are retained on the server, and re-used when repeating the backup command in tarsnap. I got the uncomfortable feeling that the error message I got: Error closing archive, means 'NO'. Probably. There's a very slim chance that the final transaction commit request got through to the server but your connection died before the acknowledgement came back. Further I wonder why the backup fails already after 4 errors looking up betatest-server.tarsnap.com. It's the other way around -- when a connection is failing, tarsnap will retry several times before giving up; and as part of those retries it will perform new DNS lookups (and warn when those fail due to your internet connection being down). This way, with my quite unstable network connection, I'm afraid the uploading will never complete. I'd recommend using the --checkpoint-bytes option with a fairly low setting (e.g., --checkpoint-bytes 32M) so that you'll have lots of checkpoints created. That way when an archive fails you'll still have the first section of the archive stored -- and that data can then be used for deduplication purposes when you create another archive, which will make future archives use less bandwidth and complete faster. Thanks for your reply. So I have to do 2 things: 1) add the checkpoints option 2) create another (NOT the same) archive? Of course, finding an internet connection which doesn't break for 5 minutes at a time would be ideal. (5 minutes is how long tarsnap will keep on trying to reconnect.) The internet connection breaks down when the power goes out, which happens quite frequently: 2 times a day for 2 hours each. The laptop runs longer than 5 minutes on its own battery, which means tarsnap will always 'give up'. Which brings me to the following feature request: A command line option to set the 'retry time' (from 5 min. to inf., and frequency--if not automatic as function of 'retry time'). tnx
