@iroal said in Why It Is Not a Backup Unless It Is Decoupled:

It was a Hoax

http://www.infoworld.com/article/3057676/it-management/that-man-who-deleted-his-entire-company-with-a-line-of-code-it-was-a-hoax.html#tk.rss_all

Yup, that's what the thread has been discussing 🙂

In this case, it was a matter of the settings during the restore.

Under GENERAL you had to select your source and destination as normal. Destination was changed so that it was the new History file. Under FILES you updated the DB and LOG files to reflect the new DB, otherwise you would over write the originals.

This is where they borked it. They didn't mention FILES only going to OPTIONS, and there is where they mentioned updating the file names. The main discovery was that you need to uncheck LEAVE Source database in the restoring state.

When I emailed them about removing the 'borked' databases I had created the called me back. I mentioned it to the fellow and we had a short discussion on the matter where he took notes and agreed that the directions were incorrect. When I got to the part about unchecking LEAVE Source database in the restoring state he mentioned that he uncheck Take tail-log backup before restore

Hope this helps.

0_1460118217976_2016-04-08 08_22_29-NTG - SSI-SQL01 - Connected.png

@tonyshowoff Now that's just painful to think about.

To me.

A Backup is a read only copy that can not be alterted.. Otherwise it's living data, And you can not verify the data has not changed/added or removed since the backup was taken.

And it's currently only VMware but they are working on Hyper-V and KVM.

@Dashrender said:

Interesting - by that same token, good backup software should not allow you to delete and previous portions of a backup as long as any other backup references files contained in said backup.

i.e. FB - i1 - i2 - i3 - i4

A good backup package won't let you just delete FB and allow you to keep i4 because i4 would be worthless.

But in this case i4 isn't worthless. You could completely restore from it. Just not have the old data from FB. So for DR is really nice.

@FATeknollogee said:

@scottalanmiller said:

I'm watching the videos trying to figure out what it does. Looks like a decent product but haven't seen any single pane of glass stuff yet.

Did you at least find one compelling feature?

Not yet.

@travisdh1 Yup, that's basically how it works. The insulating material is water-based and converts to steam during a fire, resulting in an endothermic cooling action. Additionally, the steam is forced out of the events which prevents heat from entering the unit. As for waterproofing, the drives are simply in a sealed box that relies on finned walls to conduct heat away during normal operation.

Okay, makes sense then. I'd lean towards XenServer with local storage then. You can migrate to CEPH when it is ready. This would get a single node up "instantly" and let you move others as the opportunity arises.

@Dashrender said:

@JaredBusch said:

I am not happy with the amount of the increase. I never said a company should not or cannot raise their costs.

Considering my other theory, I'm not surprised with the hike. Happy, maybe not, but surprised, nah!

Another question - how often are you buying new licenses?

And when you compare prices, what beats it?

Nothing beats it yet on price for paid solutions that work with Hyper-V.

Unitrends free is a possibility for this particular client.

@Dashrender said:

What are/were the limitations of free version? I have forgotten.

1TB of storage. I think that's counting amount of protected storage, but it's been long enough I forget for sure.

Edit: Works real well for me here, adding servers and services as I set them up. We've been using crashplan for file level storage for a long time, so I don't have much being pulled in by Unitrends currently.

Veeam support is now from India 😞

@DustinB3403 said:

Did you not have somewhere to jump off of?

XS/XO/XOA is all great, but seriously the thread count is stupid. The knowledge is lost in all the noise.

So I tested the backup functionality within XOS and the appliance backs it's self up without issue.

Wow!

No additional tools required. Great design @olivier !

Exactly. Job manager is "generic": it allows you to build complex planned stuff (like shutdown those VM during the night, and create another job to start them in the morning).

It's very very generic.

Backup is a kind of specific planned job.

@Danp said:

@johnhooks said:

So I've waited about 30 minutes or so, much longer after the backup completed. I still have a snapshot called XO_DELTA_BASE_VDI_SNAPSHOT. Am I able to delete it and it not affect the backup or is the delta based off of the snapshot?

Did you every get clarification on this? I suspect this is needed for the delta backup.

Yes, it uses the snapshots to make the backups. That's what I figured it was doing, but since Dustin didn't see it I thought maybe something was wrong.

We resolved it in another thread, I can't remember which one at this point.

So upon further investigation I've realized I'm a complete moron. So I created the local storage through the web interface. I thought that meant it was local to XenServer, but it was local to XO. So the backups are being saved to the container and not on XenServer. Disregard everything above, I'm just stupid.

Has this one reached a conclusion? Should we close it out?