If you’ve transferred your work to a new computer and don’t need the old computer’s backups in your S3 account anymore, you’ll need to delete them. Arq does not currently provide a mechanism for deleting those backups, but you can delete them through the AWS Management Console. Here’s how to do that:
First, open the AWS Management Console (https://console.aws.amazon.com/s3/home).
Next, select the bucket that Arq uses for its backups (named “.com.haystacksoftware.arq”).
Now you’ll have to determine the computer UUID that you want to delete. To do this, look at the computerinfo file within each one:
- double-click on a computer UUID
- control-click on the file
computerinfoand pick “Download” - open the downloaded file with TextEdit
- if the “computer name” matches the one you want to delete, you’ve found the right computer UUID.
Here’s an example “computerinfo” file:
<plist version="1.0">
<dict>
<key>userName</key>
<string>stefan</string>
<key>computerName</key>
<string>Stefan Reitshamer’s MacBook Pro</string>
</dict>
</plist>
In that example, the computer name is “Stefan Reitshamer’s MacBook Pro”.
Now that you’ve found the right computer UUID to delete, go back and select the bucket itself to see all the computer UUIDs again. Then control-click on the computer UUID you want to delete, and pick “Delete” from the pop-up menu. AWS Management Console will delete all the objects for that computer UUID.
WARNING: This delete cannot be undone! Please be careful when deleting.
Will deleting a UUID in this fashion orphan the files backed up from that computer or will they be cleaned up by a Arq Agent running on any machine?
Comment by Matt — October 27, 2010 @ 5:40 pm
If you delete the UUID in the AWS Management Console, the Console will delete all the objects with paths starting with that UUID — in other words, all the data for that computer. They won’t be orphaned; they’ll be gone.
Comment by Stefan Reitshamer — October 27, 2010 @ 6:30 pm
Thanks for the quick response. So, Arq clients using the same S3 account do not occupy the same region in the bucket? In other words, duplicate files on two clients will be duplicated in the Arq bucket?
Comment by Matt — October 27, 2010 @ 8:14 pm
Right. There’s no de-duplication across computers. This is because S3 doesn’t provide any atomic operations, so I can’t create a locking mechanism. Without a locking mechanism I can’t safely determine that an S3 object is unreferenced and delete it.
Comment by Stefan Reitshamer — October 27, 2010 @ 8:18 pm
I understand. Maybe Amazon will expand the capabilties in the future. Thanks!
Comment by Matt — October 27, 2010 @ 8:58 pm
What is the Arq UUID based on? I notice that it’s apparently not the Hardware UUID specified in System Profiler.
Comment by Matt — October 29, 2010 @ 1:10 pm
The UUID is randomly generated.
Comment by Stefan Reitshamer — October 29, 2010 @ 1:12 pm
Does the client store the UUID so that it knows which folder to use? Or does it attempt to match the values in computerinfo?
Comment by Matt — October 29, 2010 @ 1:22 pm
The client stores it in ~/Library/Arq/localcomputer.plist
Comment by Stefan Reitshamer — October 29, 2010 @ 1:25 pm
The reason for my inquiries is to figure out if I can successfully recover (in the future) from a situation I was just in. My internal hard drive went bad, but my external volumes were intact. I needed to start from scratch on the internal drive (reinstall OS, etc). Is there a way to re-associate my machine in that scenario with the Arq backup?
So, if I put localcomputer.plist back on the client, I would be able to continue using the same repository?
Comment by Matt — October 29, 2010 @ 1:32 pm
You need to restore your files from S3 BEFORE you start using the old computer’s UUID!
If you set your new computer to use your old computer’s UUID, Arq will start backing up the same folders it was backing up before. If those folders are empty on your new computer, it’ll replace the previous backup (your files) with a backup of empty folders!
Before you do that, please email me at support@haystacksoftware.com so we can be really clear on what you’re trying to do. I don’t want you (or anyone else reading this) to lose data!
Comment by Stefan Reitshamer — October 29, 2010 @ 1:59 pm
Makes sense. I would definitely restore folders to my internal drive before I tried to re-associate the Arq UUID.
A similar situation will occur when upgrading to Lion next year. I will probably wipe the drive and start fresh, but I wouldn’t want to re-upload my external volumes’ backups to S3 at that point. You may not have a good solution for this with the current version of Arq, but it’s a good puzzle to think about.
I wonder if mounted volumes having their own plist would help? If the volume.plist were user/computer agnostic, you could basically mount the volume on any machine with Arq Agent and have it maintain the backup. That would be so nice.
I use Dropbox to “backup” my internal drive. I am using Arq for my external volumes. My internal drive contains documents and projects. The externals contain multimedia and photo libraries.
Comment by Matt — October 29, 2010 @ 2:18 pm
Assuming my scenario isn’t an edge case and you decided to implement something like this, I go into it with the understanding that I’ll probably have to re-upload my externals again to seed the initial state.
Comment by Matt — October 29, 2010 @ 2:25 pm
It’s not an edge case. I get a lot of emails about it. Adding support for it is pretty high priority for me right now.
Comment by Stefan Reitshamer — October 30, 2010 @ 6:59 am