0

Is there any way to deal with incoming writes while a backup is in progress in linux. Example, you are writing to your sql database and lvm snapshotting at the same time. This will result in corrupted data because the snapshot will include only parts of that write. VSS gets past this problem with having all services get to a clean state before snapshotting. I don't see of any real solution in Linux.

user39457
  • 1
  • databases are designed to survive crashes, to what's on disk at any given point should be consistent (like they write a _clean_ flag on disk after a batch of data writes or any mechanism along those lines). – Stéphane Chazelas May 19 '13 at 21:19

1 Answers1

0

That is not (at least not primarily) a VSS feature but a feature of every program you run. If you are lucky. Of course, you cannot force a program to have such a feature. But such a "write back your data" feature would be nice even without snapshots. But I am sure that similar features exist in every serious database for Linux.

Hauke Laging
  • 88,146
  • 18
  • 125
  • 174
  • well yes. Windows has a unified way of telling all services to stop based on a common format. Linux on the other hand does not. Unfortunate. – user39457 May 18 '13 at 21:51
  • @JoelDavis Aborting a program (softly) is an extreme way of having it write back its data. Usually you don't want to interrupt your service. There is e.g. no need to cancel existing connections to the application just in order to write out data. Restarting the application takes ten times, maybe a hundred times as long as writing only the dirty data. – Hauke Laging May 19 '13 at 00:06
  • Yeah I think I misunderstood the OP's question, I deleted my comment before I saw that you had replied. – Bratchley May 19 '13 at 00:11
  • @HaukeLaging This has been bugging me since I last got into this last night. Since you seemed to have a handle on it, I'll ask you. I'm seeing where SIGHUP will signal MySQL to flush anything dirty to disk so I'm OK with that. Looking at Postgresql signals: http://www.postgresql.org/docs/6.4/static/signals.htm I'm seeing postgresql has "async transaction" (implying most transactions are sync'd) does this mean SIGUSR2 has a similar function in Postgresql? – Bratchley May 19 '13 at 14:45
  • @JoelDavis I don't know that. But I can comment on the first part. Such a SIGHUP does not solve the problem because it creates a race condition. You need a handshake with the application, a time window in which it is safe to create the snapshot. From the outside you cannot know until when the app writes out the dirty data and when afterwards it starts writing other data (as part of resumed normal operation). You need this: (a) The app gets signalled. (b) The app says "everything written out. (c) The snapshot code creates the snapshot and tells the app: "You may write again now." – Hauke Laging May 19 '13 at 19:03