How long will Raspbian 7 be supported - same as Debian Wheezy?

There were/are a number of domestic home routers that have easily comprised software enabling basic script-kiddies to bypass them. Typically these are "hidden" ports usable by ISPs to remotely manage the router they provide or other trivial remote access exploits.

It's less likely someone runnning a Linux box onto the net would have a weak home router, you'd expect them to understand why OpenWRT etc. make good choices. But the Pi is very popular with (no denigration intended) "newbs" who tinkering with Linux for the first time may not be so understanding of the risks.

YMMV

The biggest risk to anyone's security is the belief that there system is secure. it is potentially worse than ruining an insecure system that you at least know is insecure.

how exactly is upgrading to the latest version going to help that?

also probably they don't even change the default password of the RPi...

Bye Jack

A huge number still do, including most of the free crap your ISP gives you, and will never ever see a firmware update.

Don't get too worried about their obsession with invisible ports, closed is good enough for most purposes.

As this is a Raspberry Pi newsgroup, it's easy to run nmap from your Pi on your external address

---druck

That minds me of the situation of someone who gets hit by crypto malware, and thinks they're OK because they have backups, only to find that the backups have also been trashed.

But the risk to /that/ system is minimal because they've only just installed it from a downloaded image, and whole-system back-up is trivial. Even if they get totally pwned there's not much at stake. The risk to any other machines on the LAN, or on the WAN should the RPi be used to launch attacks, depends totally on the nature of /those/ systems.

Yes, it often takes a bad experience for people to realize that backups on an online volume are useless, and backups on an unmounted but still accessible volume are next-to-useless.

Yesterday I saw a colleague preparing a box of tapes (DLT, LTO etc) for destruction, we do not backup to tape anymore since we have that modern NETAPP filer with replication to a remote site. I think it is a disaster waiting to happen, but fortunately it is not my responsability.

It's what I'm doing at present, however I'm happier if I can run as 'standard' a system as possible.

They are of course totally useful if you have a a disk failure

To destroy a remotely rsynced backup you need to know the remote machine the device and the password.

You need to be root to do that if the remote backup script is correctly permissioned.

Do uyopu have any idea how pompous you sound to someone who has been doing all this for years?

I can and do run it against machines on my LAN, but I don't understand how to run it against the internet-facing interface of my ADSLmodem/ router since that is, hopefully, not the same as its LAN-facing interface. Thats why I periodically use Gibson Research, yashi, etc, because I know they are peering in from the outside.

For that, it is better to use RAID

In my opinion, no amount of snapshoting or mirroring is equivalent to backup to offline media. With our backup tapes we took a tape out of the normal rotation twice a year for archiving purposes. Such functionality is not present in the current system, as snapshots are removed when space considerations require it. Of course backup replication is done using the native tooling for that, and hopefully there is enough space on the backup destination to keep snapshots for quite some time, but I don't think we will ever have the capability to recover a file that has been deleted 2 years ago, which was not a problem with the old system (as long as the file had existed on the system for half a year, of course).

Apparently the decision has been made we no longer require that functionality. It was used a couple of times in the past, but not within the visibility of current management.

Apologies for telling yo something you already knew. I also like to remain a close to standard as possible, do the same trick in order to use the MicroEMACS editor - one I found out about when using OS/9 (pre-Linux) and have used ever since on a variety of machines, Unices and Linuxes.

It won't help the box you plugged it into - but if the rest of the boxes on the network are up to date and secure then at least it will only hit the box you plugged it into and not get everywhere.

To destroy a (single) remotely rsynced backup all you need to do is destroy the source data and it not to be noticed long enough for the rsync to do it for you.

Multiple offline and offsite backups are the only way of having true data security, if you really care about the data. It scares me that I know of businesses that rely purely on live replication to another datacentre as the sole means of backup, effectively wide- area RAID. Great for the DR scenario, but one careless "rm -rf", or c*ck-up with the storage management (Plusnet email...), and the data is gone. "RAID IS NOT BACKUP"

A big problem these days is that discs are too damn reliable, especially with RAID, so a proper backup strategy is seen as an unnecessary cost, until it's too late. And it might not be "my responsibility", but it will be "my problem" when the company crown-jewels are lost, along with the business.

(I still use tapes!)

hahah. a machine in daily if not hourly use and you don't notice its lost its data.

'All' ? Really!

I have found tapes less reliable than disks

There are plenty of USB drives if you want isolation and off site.

The trouble here is that if you are dealing with large amounts of data (and many these days are dealing with petabytes) then tapes are too slow to be useful (in many cases SLAs do not allow sufficient down time in a year to read a single tape), life DR is essential. Which is one reason why the modern approach is tiered with live, fallback, nearline and archive layers each of which uses snapshots or similar history preservation for protection against damage and redundancy for protection against failure.

For a good example of how to retain data safely under really extreme conditions look carefully into how Amazon's Dynamo system works.

Even for archive some kind of disc storage (spun down most of the time to save power) with regular read tests (weekly ZFS scrub would be my favoured approach) will be *far* more reliable than tapes when dealing with large amounts of data.

For any environment where you can accept the downtime to restore from tape then yes tapes are a good solution, probably the best, *provided* you have the discipline to use them correctly (offsite copies, readback tests, recovery tests ...).

RAID plus history is a lot safer than tapes in the hands of idiots, like the company I set up with boxes of labelled tapes many years ago only to find that after listening to the instructions they simply never bothered to change the tape so inevitably the disc crash happened in the middle of the backup and all the data was gone. Then there was the outfit that did everything right - they even automatically read checked their tapes - except verifying that the tapes actually held all the data they needed for recovery.

Not if the remote is an incremental backup, all that will happen is that the 'latest' backup (or those until you notice the source has been tampoered with) isn't what you want but all previous increments will be intact.

I'd never rely on what (I assume) you mean by a 'single' backup because almost invitably if I mess something up then the 'mess' will have been backed up up before I notice! :-)