21–30 of 126 posts
why would you try this out with "live" data? why not incrementally connect drives and do it that way? i'm basically asking what the impetus was for "just going for it" which is probably going to be a reason that other people share...
Incrementally?
Personally I prefer full backups - they feel more complete.
Getting backup right is extremely important, that is why you need proper tools. For the last 10 years I have been using ZFS snapshots and replication. I keep 180 days with snapshots on the remote backup and 30 days for the local. I use it to take backup of virtual machines, different databases including "running", sql servers. And of course important files, documents and photos. I've also configured a daily mail with…
Similar story but way shorter. Was working on the beginning of Typeform years ago and we had some issues in production, wanted to take a look at the logs. The logs were in a tar archive, so just needed to untar it. Mixed up the arguments in the tar command and instead overwrote the logs with a empty archive. Doh. In the end, lesson learned: be 100% sure arguments are correct if you're stupid enough to run terminal co…
There's now way he could have possible known simply booting the Ubuntu live disk would do this. He could have done that without any consideration to doing a backup. However regular tried and true backups are the way to go, preferably automated. My worst horror story wasn't really mine. I did desktop support in my first job. The library had their own system and their own support arrangements but I had a good relations…
Getting backup right is extremely important, that is why you need proper tools. For the last 10 years I have been using ZFS snapshots and replication. I keep 180 days with snapshots on the remote backup and 30 days for the local. I use it to take backup of virtual machines, different databases including "running", sql servers. And of course important files, documents and photos. I've also configured a daily mail with…
Do you use ZFS on the desktop too, or something different? I've used btrfs raid on a server before, and it worked apart one incident which took it two weeks (for 4TB of data) to recover from, so I'm probably going to move to ZFS on the next upgrade. On the desktop there seem to be many more tools for btrfs though, like timeshift [0] - effectively Time Machine for Linux. [0] https://github.com/teejee2008/timeshift
"The parity RAID code has multiple serious data-loss bugs in it. It should not be used for anything other than testing purposes" [1]
Similar story but way shorter. Was working on the beginning of Typeform years ago and we had some issues in production, wanted to take a look at the logs. The logs were in a tar archive, so just needed to untar it. Mixed up the arguments in the tar command and instead overwrote the logs with a empty archive. Doh. In the end, lesson learned: be 100% sure arguments are correct if you're stupid enough to run terminal co…
Linux commands: with great power comes great responsibility. We're all seduced by the power, but quickly learn the responsibility part!
That required some great caution.
For complete system backup on Windows use Acronis [0], on MacOS use Carbon Copy Cloner [1] and on Linux Clonezilla [2].
Also never forget the 3-2-1 rule of backups [3], 3 copies, 2 local copies on different mediums and 1 copy offsite (cloud, remote) :-)
[0] https://www.acronis.com/en-us/personal/computer-backup/
[3] https://www.backblaze.com/blog/the-3-2-1-backup-strategy/
There's now way he could have possible known simply booting the Ubuntu live disk would do this. He could have done that without any consideration to doing a backup. However regular tried and true backups are the way to go, preferably automated. My worst horror story wasn't really mine. I did desktop support in my first job. The library had their own system and their own support arrangements but I had a good relations…
Did it end up going to data recovery? Most of the time it should be possible to retrieve most of the data, at least.
- Your data is at most risk from yourself. Other risks such as hackers, burlgars, fire or hardware failures aren't nearly as dangerous to your data as you are.
- Backup is HARD. Have someone else do it.
- Mirroring is fine for one first copy. Whether that copy is raid or just another NAS or something, but there should always be a proper BACKUP too.
- To be a proper backup it should be 1) Write only/snapshotting, so even if you remove all your local files, the deltions aren't mirrored. 2) Have long retention. When you mess up a document you want to be able to notice 2 years later and just fetch that version 3) Be off site so theft and fire doesn't risk the primary copy and the backups.
I think the moral of the story is; always use software RAID. Hardware RAID (even fake ones like Intel) are time bombs, either you have fun configurations like this or the controller dies and no replacement exists. Unless you'd absolutely need a HW RAID, I'd go for a Software RAID that mounts and works natively in Linux. I can put the harddrives into a fully foreign computer and it would work.
Another identical (hardware-wise) cold spare was already in the rack right below the unlucky one, but it wouldn't accept the transplant license dongle because of service tag mismatch. First I had to install Windows 95 just to run the service tag changer tool and flash the firmware on the spare controller to match the original before it recognized the old disks as an existing array.
In around one week we were back up and running (this was a non-workplace environment so there were no concerned execs bugging us for status updates every fifteen minutes). Had we been using mdraid, we could just have inserted the disks in just about any commodity PC hardware. In hindsight, just restoring the week-old backups would have been easier.
Lesson learned: even if you are using hardware RAID and have an ostensibly identical hardware spare available, it won't necessarily save you.