Hi Brandon, If you ran tarsnap-keygen when you switched machines, then the Tarsnap service thinks that you want an entirely separate computer. In Tarsnap terminology, the account is who pays for it, while every machine key associated with that account is completely independent. (Think of an office where the manager pays for tarsnap, but each employee has a separate "machine key" to store their own backups.)
The good news is that tarsnap-keygen won't overwrite an existing keyfile. So if you already copied the keyfile over, then it should still be where you put it. Maybe you gave it a slightly different filename than your new keyfile? I would double-check my /root/ and $HOME directories, in case the old key ended up somewhere you didn't expect it to. If you can find your old key, I recommend using that again. After you run --fsck with the old key, you should be able to resume using tarsnap the way you expected to. If the old key is truly lost, we can manually unauthorize the key and delete all data associated with it. If you definitely need this, we can take the discussion off the email list and proceed privately. Cheers, - Graham On Sun, Jul 05, 2020 at 05:29:30PM -0500, Brandon Woodford wrote: > Graham, > > The case is the latter. But I did upload an archive around July 2nd and my > account was charged for bandwidth and two days of storage. So it is possible > that I didn't copy the correct key file over. Though I was following the > simple getting started instructions...where I put my keyfile in the /root/ > directory. This was the key that I copied over. However, I did register the > new machine under a new name with the Tarsnap service. Is it possible that > this is creating the conflict? And is there a way to unauthorize the machine? > > Best, > Brandon > > On Sun, Jul 5, 2020, at 1:01 PM, Graham Percival wrote: > > Hi Brandon, > > > > When you say that --fsck has not yielded any results, what do you > > mean? You should see something like this: > > > > $ tarsnap --keyfile .test-tarsnap/tarsnap.keys --fsck > > Phase 1: Verifying metadata validity > > Phase 2: Verifying metadata/metaindex consistency > > Phase 3: Reading chunk list > > Phase 4: Verifying archive completeness > > Archive 1/32... > > Archive 2/32... > > --skip-- > > Archive 32/32... > > Phase 5: Identifying unreferenced chunks > > $ > > > > If I do the same with a key which has no archives, I get: > > > > $ tarsnap --keyfile src/tarsnap/build/empty.keys --fsck > > Phase 1: Verifying metadata validity > > Phase 2: Verifying metadata/metaindex consistency > > Phase 3: Reading chunk list > > Phase 4: Verifying archive completeness > > Phase 5: Identifying unreferenced chunks > > $ > > > > > > If the latter case, then there's two possibilities: > > > > 1) you didn't copy the correct keyfile over -- maybe you > > accidentally grabbed a "test" keyfile from your previous > > machine? > > > > 2) you might not have uploaded any archives. Were you using > > --dry-run on your previous machine, perhaps in a shell script? > > When you tried --list-archives and saw nothing, was that on > > the previous machine or the new one? > > > > Cheers, > > - Graham > > > > On Sat, Jul 04, 2020 at 04:57:34PM -0500, Brandon Woodford wrote: > > > I've created archives on a previous Unix machine and have them stored on > > > the Tarsnap servers. Now, I'm trying to get those previous archives down > > > to another Unix machine. The problem is...I don't have the previous Unix > > > machines Tarsnap cache directory. I do have the key, however. I've tried > > > to use the command: tarsnap --keyfile=/prev/key --fsck for creating a new > > > cache directory on the new Unix machine. This has not yielded any > > > results. When running tarnsap --list-archives I receive nothing. > > > > > > Any help is appreciated. > > > > > > Thanks, > > > Brandon > >
