I don't think you'd find a general standard answer to this question. The truth is only you know the answer to it.
Some random points to take into consideration:
Avoid exotic distributions
There are solid distros around (debian
, centos
, opensuse
, ubuntu
, fedora
, ...) to chose from. No need to consider getting your own LFS or something like Gobolinux. Not only are mainstream distributions more field tested, but they're also easier to get help for.
What's on your server?
It may be easier to get the same distro (or a close relative debian-ubuntu, centos-fedora, ...) to your work stations. Can you imagine an incompatibility between developer's env and production server?
Ask your developers
No need to impose a distro that is "better" if none of your programmers know how to use it. Ask them for an opinion, it'd be far more accurate.
Consider paid support
Sometimes, even the most skilled linux guru doesn't have the time to support dozens of workstations. Canonical, Red Hat, and so many others, offer paid support. Even though it seems expensive, delegating support to 3rd party will allow you to focus on your core business, what you do best.
Avoid Rolling Releases
This is a small variation of the first point. There's nothing worse than supporting a version-less product. Arch Linux, Sabayon, Gentoo are great distributions, but since they lack proper versioning, it's very easy to get lost. Remember, if you're asking this question here, you're probably looking to unify the working environment of your developers. Versions are a must.
Read up on the specifics
Your business probably relies on some specific packages (like PHP, MySQL, git, memcached, ...). Browse the documentation of existing distro looking for common/known issues before adopting it.
The device name of a disk depends on what type of disk it is (more precisely, on what type of bus and controller the disk is connected to, and what driver handles them). /dev/sda
is the typical name for the first disk in a PC (other names can be used depending on the driver, e.g. for some older types of disk controllers or some hardware RAID controllers). In a VPS, the disk is normally a virtual one, and the device name depends on the virtualization technology, e.g. /dev/vda
or /dev/xvda
. You can find the block device names on your system with df
or lsblk
.
But do not use this to make a backup from a live system! You are very likely to end up with an unreadable backup. If the disk content changes while you're making the backup, which is unavoidable on a live system (e.g. a log gets written somewhere), then your image will be inconsistent — a bit of the old state, a bit of the new state — and may not be recoverable.
The preferred way to make a backup is to make a snapshot, i.e. a view of the filesystem that's frozen and doesn't change even as the real system keeps changing. How to do that, and whether it is at all possible, depends on how your system is set up. Some filesystem types such as btrfs and zfs have a built-in snapshot ability. LVM also can make snapshots of a volume.
If you can't make a snapshot (or even if you can) make a file-level backup. A file-level backup from a system that changes will be inconsistent, but if you don't make “important” changes then the backup will be usable. For example, if you move files around, they may be omitted from the backup if they happen to be moved from a directory that the backup program has not traversed yet to one that it has already traversed. On the other hand, if a log file keeps growing, you'll have some intermediate version of that file, but you won't have a damaged filesystem image. If a file is deleted and another file is created, you may have none of those files, or either one, or both, but you won't have the directory entry of the old file pointing at some data in the new file.
You can use GNU tar (as root!) to back up a Linux system complete with important metadata.
ssh root@vps 'tar -cJf - --acls --selinux --one-file-system /' >vps.tar.xz
Best Answer
You could mail-order a set of Debian DVDs, copy them to your hard disk and keep them up-to-date with
debmirror
.Another variation on the same idea is to use a USB drive with enough space and
debmirror
at a location with good, fast, cheap internet access to do the initial mirror and then keep it updated with debmirror at your slow internet. Or, get someone to do the initial mirror for you and mail it to you.You can probably do similar things with rpm/yum repos, but I'm not as familiar with the tools.
Note that with limited internet access, you're probably better off using
apt-cacher-ng
than mirroring Debian. Comment out thedeb-src
lines in your sources.list file(s) unless you actually need to download source packages.