1 |
On 28/05/2014 11:58, Joost Roeleveld wrote: |
2 |
> On Tuesday 27 May 2014 23:35:26 Alan McKinnon wrote: |
3 |
>> On 27/05/2014 17:12, J. Roeleveld wrote: |
4 |
>>> I have a yearly (full), monthly, weekly and daily. Each incremental is |
5 |
>>> against the most recent one of itself or longer period. |
6 |
>>> That means having to keep multiple snapshots active, which I prefer to |
7 |
>>> avoid. |
8 |
>>> |
9 |
>>> But, it is a good idea for backing up desktops and laptops. |
10 |
>> |
11 |
>> I'm curious why you have yearly snapshots. I've yet to find any sane |
12 |
>> production system where a yearly backup had any worth at all. Even |
13 |
>> monthly is pushing it... |
14 |
>> |
15 |
>> Or do you do it to have a decent start point for incrementals? |
16 |
> |
17 |
> It's to have a decent start point for incrementals. |
18 |
> Below are the 2 biggest shares on the NAS: |
19 |
> |
20 |
> /dev/xvda17 7.1T 5.9T 1.2T 84% /data/unsorted |
21 |
> /dev/xvda16 3.0T 2.4T 517G 83% /data/software |
22 |
> |
23 |
> It is impossible to do a full backup on a daily or even weekly basis. |
24 |
> |
25 |
> Previously, I had 1 full backup and then a daily incremental. This appears |
26 |
> like a good idea, untill you need to restore the filesystem from backups when |
27 |
> the crash occured 2 years later. |
28 |
> That is 1 full backup and over 700 incrementals.... |
29 |
> |
30 |
> Currently, I do the following: |
31 |
> Every year, a full backup |
32 |
> Then, every month, I have an incremental based on either the yearly or |
33 |
> previous monthly. |
34 |
> Ditto for the weekly (but then based on monthly or weekly) |
35 |
> And again for the daily. |
36 |
|
37 |
|
38 |
|
39 |
OK, that makes sense. |
40 |
|
41 |
It reminds me of an issue my wife had with the data warehouse when she |
42 |
worked at the bank. In a nutshell, they needed backups but backups were |
43 |
impossible to achieve because physics says so. They needed to get data |
44 |
off the disk 4 times faster than data comes off a disk - SCSI limits |
45 |
being rather hard limits :-) That opinion didn't go down well when I |
46 |
offered it |
47 |
|
48 |
The solution was to do it much like your plan above. |
49 |
With the benefit that the infrequent full backups would be done on a |
50 |
fixed schedule in a change window with X hours downtime that was known |
51 |
well in advance. |
52 |
|
53 |
|
54 |
-- |
55 |
Alan McKinnon |
56 |
alan.mckinnon@×××××.com |