So now it comes time to "restore" your inventory from that backup. What does the system do?

1. Do they replace your current inventory with the backup copy?
This is a bad idea, because you'd lose all items you'd gained since the backup.

2. Do they add the items from your backup to your inventory?
This is a bad idea, because it lets you duplicate no-copy items in your inventory. It's not workable for the
system to just check and see if you already have a copy of the no-copy item you're looking to restore
because you could simply have rezzed the item in the past to get it out of your inventory.

3. Do they let you choose specific items from the backup and restore them?
Again, this will let you make duplicate copies of no-copy items.

The last two illustrate that there's no real easy/feasible way to make a user-based backup and restore concept for your inventory without introducing the possibility of allowing you to make copies of your no-copy items. I honestly can't think of any kind of external backup concept that would make sense for inventory, given the way permissions work.

The only reasonable thing I can think of is to allow you to package up a portion of your inventory and store it on your hard drive, while removing those items from your inventory. Think of it as using your own hard drive as a bank vault. That's workable, but I don't see much benefit from it. The only benefit I can see would be to replace the concept of emptying your trash with dumping your trash contents to a vault on your own hard drive. This could prevent a rare few kinds of content loss, I suppose.

Instead, LL needs to shore up the design flaws in the system that allow items to disappear forever. I've linked a few of those to this issue.

Now on restore. The system would check my inventory, do a comparison of what is there versus what is in the backup. New content should never be replaced! What should happen is that the system would check for missing items. Would check if those items now belong to someone else, if not copyable those items would be ignore and not restored. Any missing items would be restored to me.

I think this would need to be linked with another proposal of mine https://jira.secondlife.com/browse/VWR-354 for adding aliases in my inventory for dropped items. If my "active inworld inventory" knows i have dropped a non copyable item then that item would not be restored either. For dropped items that are copyable it would be restored.

Perhaps a feature for this backup system would be to be able to do an in world query of my dropped items with their locations. Thsi would not have to be a real time thing. Perhaps a system request that would be queued and have a 24-48 hour turn around or someting to discourage abuse of the system. Even if it required a small fee, it would be worth it for the peace of mind it would bring. Just knowing it was there might reassure people and make them more secure in spending money inworld.

If I pay REAL money for something I feel entitled to know that it will not simply disappear one day for no apparent reason and with no method for me to find it or get it back. It is inexcusable to me that the system allow for these kinds of losses! If this sort of backup is quite system intensive then perhps it could b esomething offered at the higher memberhsip tiers, an insurance policy of sorts. Just a thought.

Stephen's idea of backing up your own creations, though, is fantastic., and right now is the only thing that will work without people yelling at the Lindens about bugs and things like that.

If the system is not up to the load then the system needs to change, period. Get an Oracle back end in there Lindens and quit dinking around with freebie stuff. A proper transactioning system should be able to handle this!

Today I'm missing half my inventory including a lot of irrepaceable objects I created. So I'm searching through this ridiculous JIRA system trying to figure out which of the 5 million reports of inventory loss is the magical one that won't be waved off by the same people who just took all my inventory and who - if I don't leave - will also get the money for linden purchases so I can replace at least some of what was lost.

Today would be a bad day if I had to recover via a backup. But at least it wouldn't be a day that makes me want to throw up because I feel robbed.

Let us take the case of a no-copy which vanished due to a rezz failure. As far as I can see, there are three possibiliies:

i) the object vanishes completely from the databases as if it has never existed (in which case we need a backup)

ii) the object gets located in world at some random location. If this is the case, I wonder if this is actually at global co-ordinates <0,0,0>. I did go searching for a sim at global <0,0,0> but there doesn't appear to be one. If the LL had a LL owned sim at grid <0,0,0> with the parcel at <0,0,0> set to autoreturn would out objects return to lost and found? It may be useful if we could request a report of the locations of all in world objects owned by us. This could be via the website, could involve some nominal L$ cost, could be scheduled to run at a quiet time (so may be e-mailed within a few days after the request)?

iii) the object remains in the database, but at "no location" - could a job be run daily or weekly to return these to the lost and found of the owner?

There are people who make a living working in-world, which is great, while objects usually mean money - REAL MONEY.
So, who would accept a Bank to... mistake or lose their savings?

That said, regardless of effort required, the system MUST guarantee the ownership (or at least a money equivalent which may be easier), one way or another - i.e. things MUST be safe, or else the whole SL is in danger.

Of course, that won't be easy, but a minimum of backup should be already implemented (like full perms and own items, checked against their IDs maybe?).

However, the MOST VALUABLE items are those items that you create yourself. So how about (in support of Alombar) a facility for content creators to back up their work to HD - as perms will not matter.

I'm all for the ability to back up items I have full permissions on, though. I've linked to issue SVC-553, which I made after I lost several items I described to the dreaded and mysterious "missing from database" error. I'd love it if I could run a backup on all scripts in my inventory that I have full permissions on. I'd also love to be able to get LL's internal data file representation of object assets, by backing them up to my hard drive. This would open up interesting possibilities for generating a "backed up" asset on my computer from scratch, by writing a program. I could then import the object by "restoring" it into my inventory. This would open up interesting new realms of automated building through off-grid object generation.

So far I've been lucky and only lost things of sentimental value. But it still feels as if a piece of my life has gone missing. At the very least, the ability to back up locally the items on which I have full perms, and a record of all the items I have so that I can show what went missing, would be hugely helpful.

Our dreams and hopes are recorded in our inventories.

If you leave the backup to the users, I'm the first person who won't remember to backup the recent items and won't have it, even though it's really important to me.

• • • The solution is to have automatic rolling backups on the server side and have support people be able to retrieve backup for specific users. ***

P.S. I sure do hope that Lindens already have server-side backup of the asset server already.

There should be no charge for using this backup feature. It doesn't make sense to charge users for purchasing items (Linden Labs makes most of their money by skimming off some of the value when purchasing lindens, which are used to purchase items), fail to reliably store the items, then charge them a second time for trying to work around the faulty service.

For those concerned about people cracking the backups, and using that to pirate items, that is not possible if a strong encryption algorithm like Rijndael (AES) or Serpent is used, with a reasonable key length (4096 bit is military grade for even the weakest forms of modern encryption, if you wanted to really go tin-foil-hat). The method to crack these encryption methods is widely known. You simply try all possible keys. However, the sun will burn out long before you find the key if huge key lengths are used, even if you use massive clusters like Distributed.net. It is very fast to encrypt and decrypt things /with the right key/ even with huge keys, however.

Using backups to duplicate no-copy items is also impossible, and there is no reason to remove a no-copy item from inventory just because it is backed up (in fact, that defeats the purpose of backing it up). Each object has a unique ID in the database.

Altering backups to add permissions on no-modify or no-transfer objects is also impossible. Any attempt to alter the encrypted data will simply result in a backup that won't decrypt (i.e. restore) at all.

If you disagree with any of the above statements about encryption, prove it, and you will have a high paying job at any university or national security agency you desire. Of course there are lots of people employed to try to do this, and none of them have succeeded at breaking modern encryption algorithms, correctly implemented, at realistic key lengths, so I wouldn't hold your breath.

Note that it /is/ possible to incorrectly implement an encryption algorithm, or to implement a /protocol/ using a correctly implemented encryption algorithm, and still have security holes. We're talking about a file format here, so most protocol issues aren't a concern, and if you don't correctly implement something, it doesn't work, by definition. Several attacks of this nature have occurred. I had rather risk Linden Labs messing this up, and piracy /possibly/ occurring, than the /already occurring/ situation of paying customers losing data.

In response to:

"Get an Oracle back end in there Lindens and quit dinking around with freebie stuff."

MySQL is definitely /not/ what's causing inventory loss here. If you bother to read up on the issue, it appears to be caused by a combination of flaws in the garbage collection code (seems to primarily effect objects in inventory), and corner cases in the simulator code (seems to just effect rezzed objects). It's hard to tell if there is more to it than that, not being inside Linden Labs, but we do know at least those are involved. Many businesses use MySQL with good reliability.

Okay, to address those concerned about griefers abusing such a system. It will obviously take some time for the object lookup, encryption, and transfer, and if no charge is required something else must be done to prevent denial of service attacks. There's a lot of options here. One is to simply perform the backups at a leisurely pace, as the server has time to do it. This might result in fairly long waits. Another is to only allow each account a backup/restore every so often, say, 1 a day. The latter is the best solution I've thought of.

This is pseudocode for my proposed solution:

Backup:

1. Search the user's inventory, any land they own, and (optionally) a parcel they select for objects they own. That last clause is in there to allow renters to back up their lots, even though they don't own the land. We don't search the entire database, not only because that might open it to denial of service attacks, but it would also be slower than most users would desire.

2. Pass the objects through the encryption algorithm, using a unique key tied to the user's account (which is never communicated outside Linden Lab's server... i.e. no user has access to their, or anyone else's, key). Aside from the information necessary to produce the object again, this should include the object's unique identifier in the database, and the permissions ((no-)copy, (no-)modify, (no-)transfer, etc), and location/orientation in-world.

3. To reduce the chance of a bad backup (e.g. bad RAM on the server), the server should then attempt to decrypt the data.

4. If the restore check goes well, transfer the data to the user's client, to be written to a backup file. Be sure to allow them to select a location, and default to a easily visible one. Don't dump it some random place they're never likely to look.

Restore:

1. Read encrypted backup file from user's client.

2. Attempt decryption with the user's (again, secret, to everyone except Linden Labs) key.

3. Look up each of the unique IDs in the backup. If any exist in the database, but are /not/ owned by the user, don't allow restoration. This prevents selling a no-copy, but transfer-okay, item to someone else, then restoring from backup to duplicate it.

4. For items that exist in-world, and in the backup, that the user still owns in world, compare the objects. Any objects that differ should be used to populate the list in the next step.

5. Show the user a list of objects that have been altered since the backup, and a list of objects that do not exist in-world but exist in the backup (2 separate lists). I'd suggest calling them something like "Altered" and the other "Missing", correspondingly.

6. Allow easy restoration of all missing objects, or checking a checkbox by each object they want restored, with no confirmation, since this is not a potentially destructive operation.

7. Objects that differ should have to be individually checked, and confirmation should be asked before restoring (show a browsable list of what is about to be overwritten on this confirmation screen!), since this could potentially destroy modifications you intentionally made since the backup.

Note: If a object was placed on land the user no longer owns, it is obviously folly to place the object there upon restoration, thus those objects should be placed in "Lost and Found" as they would be if they had been auto-returned. They should /not/ be glommed together and misleadingly named as some sort of coalesced object (a 'feature' that should have been done away with ages ago).

It is /vital/ to be able to restore from old backups. Thus Linden Labs must be expected to continue to read old backup formats, not just the latest one, if they decide to change formats in the future.

Okay, finally, for those of you wanting unencrypted backups of full permission items. I'm sure someone can cobble together something with libSL, without Linden Lab's help. That's not saying it's a bad idea (I think it's a grand idea), only that you don't have to depend on Linden Labs to do this for you.

Extremist Stallmanism at work here. Information may want to be free. My purchased inventory and creations to which I have copyright or whose copyright I respect because I bought the creations is not available for your freeness.

Play the Sims II if you love the idea of backing up stuff at home on your hard drive. Sims II has avatars and 3-D building very similar to Second Life now. Lots of user-generated content available to put in your game, too.

Sosur Eel, $2000 is US $7.50. Think of it as two grande lattes. Now, $7.50 is a lot of money to lose on a game, and a lot of money for some people (minimum wage for an hour or more). But, think of the alternatives. If you can get these things backed up, that means that people can hack them more easily than they can now – FAR more easily – and make them all free. That sounds fun, eh? Getting your sexgen for free. Except...then the people who make all that nice stuff have no incentive to work. They go away. And you are left with a plywood box, a chicken avatar, and dominoes falling over. Is that what you want?

there should be a way to backup all FULL-PERM items at once, really easy, and not encrypted at all for the creator (encryption still needed i you're not the creator, as it won't let you claim creator status on freebies if you don't have it).

Aside from being a 100% fix for the creators, having the side-effect of making exporting to other programs perhaps much easier, it would solve at least half the problem.

...and then have a separate fix or backup system later, when all the complexities of backuping permission items is figured out.

Waiting for a full solve before fixing the half of the problem dealing with freebies is silly!

it's not the $7.50 lost, it is the hours of work invested.

Backing up inventory is only half the issue. we should also be able to backup everythign on a parcel. i know all the same issues apply, but if i have spent weeks building a corporate headqauteres then i wanna know i have it backed up. The LL advice to take a copy is crap (you have to remove every single no-copy item from the building, you can't select through land, and it seems to be unreliable anyway)

if Sims is a toy and SL is serious then the absense of backup is, to a corporate IT guy, just laughable. How much do u think businesses will invest with no backup and no insurance?

If I pay for some object in second life, it becomes mine, and I then have a "real ownership" of that object (real and virtual).

Linden labs have total control of my object. They hold it for me. No matter what I do to change the object, they still hold it for me. If they are going to hold my property, then they have total responsibility for the care of my object. They have given me no choice in who takes care of my object. They then also have "total responsibility" if something happens to it.

It seems to me that they are not taking responsibility for anything other than collecting my money. If they loose my object, they are totally responsible to replace it. I do not care about the problems they have. They created the program, they want to be the sole caretakers of my objects, then they have sole responsibility for their care.

If I purchase a CD in real life, I can take it anywhere and play it on any machine I choose to put it into. In second life, I can only play my CD on their machine. That is an infringement on my rights of ownership to start with.

Everyone is very concerned with the rights of the creator, but no one seems to be concerned with my rights as the purchaser and current owner of the object. (I am also a creator) When I buy something in real life, I can do with it as I wish. If I buy a home, I can move it if I wish to anywhere in the world I wish. Here, I can only have it in second life. If they have that much control over my belongings, then they have total responsibility for the care of it. I see LL as only taking care of themselves. It is not that hard for them to create a master file of my belongings, record all changes to that file as they occur, and use it to restore anything from my inventory that goes missing.

Just because it may be difficult for them to implement such a tracking program for all inventories in SL, does not relieve them from the responsibility to do so.