Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Atlassian: We estimate the rebuilding effort to last for up to 2 more weeks

twitter.com

Post reply on HN
Print view View original

251–260 of 260 posts

Re: Atlassian: We estimate the rebuilding effort to last for up to 2 more weeks

#251

Post by mvkel »

planb wrote: post #68

As the person responsible for running Jira and Confluence on premises at my employer I‘m looking forward for the next time one of their sales droids contacts me to make us move to their cloud services (despite me stating that we are not interested multiple times)…

You never would have converted anyway though, right? Black swan events are pretty weak justifications for any decision.

In other words, this outage is not -because- it's cloud software. It's because someone, somewhere, broke something fundamental. That can (and does) happen in on prem at a much higher rate.

Re: Atlassian: We estimate the rebuilding effort to last for up to 2 more weeks

#252

Post by nix23 »

syshum wrote: post #248
nix23 wrote: post #245

Earlier quoted context omitted.

for me it was always 2 different formats (db-dump, vm-dump) because i trust (good) storage-media more then backup-software, for example old veeam-backups cannot be restored with new version, old veeam-software runs not on new esxi etc...

Veeam backup chains are backwards compatible with older version of veeam so I am not sure where you get that. As far as running veeam on esxi, you would need to elaborate more on that

>Veeam backup chains are backwards compatible

I had some backups that where not backwards compatible from versions that worked with ESX but NOT on ESXi. There's your "backwards compatible".

>As far as running veeam on esxi, you would need to elaborate more on that

Yeah you know exactly what i mean, no need to elaborate on that.

Re: Atlassian: We estimate the rebuilding effort to last for up to 2 more weeks

#253

Post by PyWoody »

Aachen wrote: post #126
uuyi wrote: post #92

Earlier quoted context omitted.

I would have just quit if I had that landed on me.

Honestly it doesn't sound too difficult and like a challenge to script something fun. To me. If you ever find yourself in that situation, email is in my profile and we'll work something out :)

Whoops, looks like I commented on the wrong chain.

Re: Atlassian: We estimate the rebuilding effort to last for up to 2 more weeks

#255

Post by thisisjasononhn »

nix23 wrote: post #234
thisisjasononhn wrote: post #181

Earlier quoted context omitted.

Normally it's 3-2-1, what does the 0 represent here? 3 copies 2 different formats (ex. HDD, cloud) 1 offsite 0 lost data? :D

>2 different formats (ex. HDD, cloud) That's not what "format" means, it's more like DB-Dump and DB-VM-Dump, or pure Files and VM-Dump, or something like restic-repo and rsync(pure files).

Yes seems I used the wrong word here. Indeed I meant media, rather than format, as personally for my backup setups it's different media I want to trust, rather than the actual backup file formats (which are easily interchangeable depending on what's used; read and write data to and from formats if needed).

Re: Atlassian: We estimate the rebuilding effort to last for up to 2 more weeks

#256

Post by thisisjasononhn »

syshum wrote: post #243
thisisjasononhn wrote: post #181

Earlier quoted context omitted.

Normally it's 3-2-1, what does the 0 represent here? 3 copies 2 different formats (ex. HDD, cloud) 1 offsite 0 lost data? :D

0 Errors. Technically alot of Backup Planning has moved to 3-2-1-1-0 3 Copies 2 Different Media 1 - Offsite 1 - Offline / Immutable 0 - Errors from Verification Tests

Interesting, thanks for clarifying.

My 3-2-1 comes from a personal non-professional standpoint, thus not having the extra 1-0. However I have been considering immutable offline backups, using burned DVDs or Blu-Ray discs. That's another project for another time though, for now I'm trusting paid cloud providers.

As for verification tests, hashsums are a simple solution in my opinion, but I've moved to ZFS and BTRFS to avoid having blips.

Re: Atlassian: We estimate the rebuilding effort to last for up to 2 more weeks

#257

Post by thisisjasononhn »

syshum wrote: post #244
nix23 wrote: post #234

Earlier quoted context omitted.

>2 different formats (ex. HDD, cloud) That's not what "format" means, it's more like DB-Dump and DB-VM-Dump, or pure Files and VM-Dump, or something like restic-repo and rsync(pure files).

2 Media, but the HDD / Cloud is correct The idea is to not have the backups stored on the same hardware or even same type of hardware. Same hardware is obvious but same type of hardware is listed because if a manufacturing defect or a known vulnerability is present it would make all of your backups at risk. So you want to have backups stored on 2 desperate types of storage media. HDD and Tape, or Cloud etc...

Exactly. If tape was easier for me to implement in my setup, I would do it, but I'd rather just use cloud with a fast fiber connection for now. Offsite I can send data on an external drive to another physical location if needed.

I made efforts to buy HDDs from different sellers even, to avoid sequential failures from singular bad batches. That's something else I'd want to add to a "3-2-1", with regards to HDD as a form of backup or storage media.

Re: Atlassian: We estimate the rebuilding effort to last for up to 2 more weeks

#258

Post by tatersolid »

joshuaissac wrote: post #163
bobnamob wrote: post #146

Earlier quoted context omitted.

They’re still offering on-prem for airgapped usecases afaik. It’s just become a “contact us” pricing plan

It is not a "contact us" pricing plan. The Data Center prices are publicly available on their website. It is more than twice as expensive as the Server offering, but still substantially cheaper than Cloud for the same number of users. And it is the exact same software as Server with some extras enabled like support for multiple nodes, so upgrading to it is as simple as pasting in a new product key.

> so upgrading to it is as simple as pasting in a new product key

You’ve never actually had to update an on-premise JIRA instance yourself, I presume?

Re: Atlassian: We estimate the rebuilding effort to last for up to 2 more weeks

#259

Post by syshum »

nix23 wrote: post #252
syshum wrote: post #248

Earlier quoted context omitted.

Veeam backup chains are backwards compatible with older version of veeam so I am not sure where you get that. As far as running veeam on esxi, you would need to elaborate more on that

>Veeam backup chains are backwards compatible I had some backups that where not backwards compatible from versions that worked with ESX but NOT on ESXi. There's your "backwards compatible". >As far as running veeam on esxi, you would need to elaborate more on that Yeah you know exactly what i mean, no need to elaborate on that.

>compatible from versions that worked with ESX but NOT on ESXi

wow, ESX, I have not seen anyone talk about that for a long time, you must really hold a grudge...

I never used Veeam with ESX so I can not comment on that.

>Yeah you know exactly what i mean, no need to elaborate on that.

No I really do not, you do not run Veeam on either ESX or ESXI, veeam connect to vmware with API calls, so .....

Re: Atlassian: We estimate the rebuilding effort to last for up to 2 more weeks

#260

Post by stonogo »

Zircom wrote: post #191
stonogo wrote: post #150

Earlier quoted context omitted.

In support of your point, 360MB/s is an extremely conservative estimate. I'd expect that from LTO-6, which is around ten years old, and I would certainly hope their backups are on more modern gear than that.

I work for a pretty huge well-known fortune 500 company with a global presence and personally handle the tape rotations for several of our data centers, and they're all still on LTO-6 tapes

I'm not sure that's relevant. I would expect Home Depot, Berkshire Hathaway, Alphabet, and Atlassian to have wildly different priorities. Two of them are Fortune 500 companies that I think would do fine with LTO-6. Atlassian is supposedly a cloud-first organization which arguably should be pretty aggressively tiered anyway, much less tiered onto outdated tech.
Post reply on HN