0

I've been looking for a way to do a disk image backup of a running linux server.

There are several questions which answer this, like How to make a disk image, Mirror Live Linux (Debian) Server, Linux live hot backup snapshot and debian live server image.

Most of them seem to suggest dd, using a gui wrapper around partclone, using a proprietary tool (not an option for me) or do file-based backups instead (eg. rsync). While I'm versed with those tools, I'm not sure about using the first two on a remote live server for creating a hot image backup, because of data integrity issues.

So I'd like to know

  • Could using dd if=/dev/vda1 on a running server result in a broken image that is not in a valid state when trying to restore the server from it, or other data integrity issues?
  • Are filesystem-aware tools like partclone.ext4 able to work around / avoid potential filesystem errors when cloning from a live server or do they just save backup space? Or do they even give potential for more problems than just using dd?
  • Would mount -o remount,ro / before creating a disk image effectively prevent potential issues? Has the downside of creating service downtime.
  • Is there another solution to create a backup image of a running server I might have overlooked which does not result in service downtime?

The question is generic and not for a specific type of service; the solution should work on mailserver, webserver, fileserver, monitoring, buildserver, whatever. Also should work with ext4 for servers where I'm not able to use a different filesystem which offers snapshot functionality.

Unfortunately this isn't something I could just test once and then be sure it will work everytime if it worked the first time.

1gd_1bs37coua9dd
  • 31
  • 3

1 Answers1

2
  • Yes.
  • Able? Yes. Do they? NFI.
  • Yes.
  • Sort of, depending on your definition of "service downtime". Linux has the concept of "freezing" a filesystem, allowing the filesystem to be held in a consistent state -- a little bit like remounting read-only, but without causing writes to fail (they just hang until the filesystem is unfrozen).

The trick, of course, is that (typically) you don't want to leave your filesystems frozen for any length of time, because any process that is writing to that filesystem will be hung until you unfreeze again. The standard solution for that is to use a snapshotting mechanism underneath, such as LVM snapshots (thin or otherwise), so the backup process becomes:

  1. Freeze filesystem
  2. Take snapshot of underlying block device
  3. Unfreeze filesystem (system now continues on its merry way)
  4. Take consistent backup from the snapshot
  5. Delete the snapshot, to stop the preformance degradation of copy-on-write snapshots
womble
  • 96,255
  • 29
  • 175
  • 230
  • File system freeze is not needed for Linux LVM snapshots (it is on some platforms). Good practice to generic terms like this to free the conversation from specific tools, instead of `dd` discuss a "block image of a snapshot" which is a "consistent backup". – John Mahowald Jan 20 '19 at 17:10